очистка данных перед внедрением MySQL и XSS - я делаю это правильно с pdo и htmlpurifier

Question

Я все еще работаю с защитой своего веб-приложения. Я решил использовать библиотеку PDO для предотвращения внедрения MySQL и очиститель HTML для предотвращения атак XSS. Поскольку все данные, поступающие с ввода, поступают в базу данных, я выполняю следующие шаги для работы с данными:

1. получить данные из поля ввода
2. Запустите pdo, подготовьте запрос
3. связать каждую переменную (переменную POST) с запросом, очистив ее с помощью html очистителя
4. выполнить запрос (сохранить в базе данных).

В коде это выглядит так:

// start htmlpurifier
require_once '/path/to/htmlpurifier/library/HTMLPurifier.auto.php';

$config = HTMLPurifier_Config::createDefault();
$purifier = new HTMLPurifier($config);

// start pdo
$pdo = new PDO('mysql:host=host;dbname=dbname', 'login', 'pass');
$pdo -> setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// prepare and bind
$stmt = $pdo -> prepare('INSERT INTO `table` (`field1`) VALUES ( :field1 )');
// purify data and bind it.
$stmt -> bindValue(':field1',   $purifier->purify($_POST['field1']), PDO::PARAM_INT); 
// execute (save to database)
$stmt -> execute();

Вот вопросы:

1. Это все, что мне нужно сделать, чтобы предотвратить инъекцию XSS и MySQL? Я знаю, что не могу быть уверен на 100%, но в большинстве случаев он должен работать нормально и этого достаточно?

2. Достаточно ли еще раз очистить данные, когда их извлекают из базы данных и помещают в браузер или фильтруют перед сохранением?

3. Я читал в вики, что умно поворачивать magic_quotes. Конечно, если магические кавычки ставят ненужные раны, это может раздражать, но если я не забочусь об этих ударах, разве это не превращает их в потерю еще одной линии защиты?

Ответ:

Обратите внимание, что код, который я написал в этом примере, является лишь примером. Входов много, а запрос к БД намного сложнее. К сожалению, я не могу согласиться с вами, что если переменная типа PDO должна быть int, мне не нужно фильтровать ее с помощью атак XSS. Поправь меня, если я ошибаюсь:

Если входные данные должны быть целыми числами, и тогда все в порядке - я могу поместить их в БД. Но помните, что любой вклад может быть изменен, и мы должны ожидать худшего. Так что, если все в порядке, чем в порядке, но если злоумышленник введет код XSS, у меня есть несколько линий защиты:

1. защита на стороне клиента - проверьте, является ли это числовым значением. Легко пойти на компромисс, но может остановить всех новичков.
2. на стороне сервера - тест с использованием xss-инъекций (с использованием htmlrify или ie htmlspecialchars)
3. db side - если кто-то каким-то образом разместит вредоносный код, который будет избегать xss-защиты, тогда база данных выдаст ошибку, потому что должно быть целое число, а не какой-либо другой тип переменной.

Полагаю, это не делает ничего плохого, и может принести много пользы. Конечно, мы теряем время на то, чтобы все просчитать, но я полагаю, что нам нужно прибавить в весовых показателях и безопасности и определить, что для вас важнее. Мое приложение будет использоваться 2-3 пользователями одновременно. Не много. И безопасность для меня гораздо важнее, чем производительность.

К счастью, весь мой сайт с UTF8, поэтому я не ожидаю никаких проблем с кодировкой.

При поиске в сети я встретил много мнений о addlashes (), stripslashes (), htmlspecialchars (), htmlentities () .. и я выбрал htmlpurity и pdo. Все говорят, что это лучшие решения перед угрозами инъекций xss и mysql. Если у вас есть другое мнение, пожалуйста, поделитесь.

Answer 1

1. Что касается внедрения SQL, да, вы можете быть на 100% уверены, что всегда используете подготовленные операторы.Что касается XSS, вы также должны убедиться, что все ваши страницы имеют UTF-8.HTML Purifier очищает данные, предполагая, что они закодированы в UTF-8, поэтому могут возникнуть непредвиденные проблемы, если вы поместите эти данные на страницу с другой кодировкой.На каждой странице должен быть тег <meta>, который определяет кодировку как UTF-8.

2. Нет, вам не нужно очищать данные после того, как вы извлечете их из БД, при условиичто вы уже продезинфицировали его и не добавляете к нему какие-либо пользовательские материалы.

3. Если вы всегда используете подготовленные операторы, магические кавычки - не что иное, как неприятность.Это не дает никаких дополнительных линий защиты, потому что подготовленные заявления являются пуленепробиваемыми.

Теперь вот вам вопрос.PDO::PARAM_INT превратит $field1 в целое число.Целое число нельзя использовать при атаке SQL-инъекцией.Почему вы пропускаете его через HTML Purifier, если это просто целое число?

HTML Purifier замедляет все, поэтому вы должны использовать его только в тех областях, где вы хотите разрешить HTML.Если это целое число, просто сделайте intval($var), чтобы уничтожить все, что не является числом.Если это строка, которая в любом случае не должна содержать HTML, просто сделайте htmlspecialchars($var, ENT_COMPAT, 'UTF-8'), чтобы уничтожить весь HTML.Оба они гораздо более эффективны и одинаково безопасны, если вам не нужно разрешать HTML.Каждое поле должно быть обработано, но каждое поле должно быть очищено в соответствии с тем, что оно должно содержать.

Ответ на ваши добавления:

Я не хотел подразумеватьчто если переменная должна содержать целое число, то ее не нужно очищать.Извините, если мой комментарий натолкнулся на это.Я пытался сказать, что , если переменная должна содержать целое число, ее не следует очищать с помощью HTML Purifier. Вместо этого ее следует проверять / очищать с помощью другой функции, такой как intval() илиctype_digit().В этом случае HTML Purifier не только использует ненужные ресурсы, но и не может гарантировать, что в дальнейшем эта переменная будет содержать целое число.intval() гарантирует, что результатом будет целое число, и результат будет в равной степени безопасным, поскольку никто не может использовать целое число для проведения атаки с использованием XSS или SQL-инъекций.

Аналогично, если переменная не должна содержать HTMLво-первых, как и заголовок вопроса, вы должны использовать htmlspecialchars() или htmlentities().HTML Purifier следует использовать только в том случае, если вы хотите, чтобы ваши пользователи вводили HTML (например, с помощью редактора WYSIWYG).Поэтому я не хотел утверждать, что некоторые виды входных данных не нуждаются в санитарной обработке.Я считаю, что входные данные следует очищать с использованием различных функций в зависимости от того, что вы хотите, чтобы они содержали.Не существует единого решения, которое работает на всех типах входов.Совершенно возможно создать безопасный веб-сайт без использования HTML-очистителя, если вы принимаете только текстовые комментарии.

«Защита на стороне клиента» - это не линия защиты, а просто удобство.

У меня также возникает неприятное ощущение, что вы смешиваете XSS и SQL-инъекции вместе, когда они представляют собой совершенно разные векторы атак."XSS инъекция"?Что это?

Вы, вероятно, также захотите добавить в свой код проверку в дополнение к sanitization .Санитарная обработка гарантирует, что данные в безопасности.Валидация гарантирует, что данные не только безопасны, но и правильны .