SQL-инъекции - Итог
ОГЛАВЛЕНИЕ
Итог
На этом все. В этой стстье я старался максимально охватить варианты уязвимостей, которые допускают программисты при создании программ с использованием баз данных MySQL. Однако я более чем уверен, что это далеко
не полный перечень.
Gоэтому важно запомнить несколько правил:
Не доверяйте НИКАКИМ данным, которые приходят от пользователя.
Речь идет не только о данных, которые передаются массивами $_GET и $_POST. Не следует забывать про $_COOKIE и другие части HTTP-заголовков. Следует помнить про те, что их легко подменить.
Не стоит надеяться на опцию PHP "magic quotes"
Которые наверно больше мешают чем помогают. Все данные, которые передаются в базу данных должны быть сведены по типам с полями
базы данных. ( $id=(int)$_GET['id'] ) или защищены функциями mysql_escape_string или mysql_real_escape_string.
mysql_real_escape_string не экранирует % и _, поэтому не стоит ее использовать в паре с LIKE.
Не стоит также сильно надеяться на правильно написанный mod_rewrite. Это только способы для создания "удобных" УРЛ-ов, но уж никак не способ защиты от SQL-инъекций.
Отключите вывод информации об ошибках.
Не помагайте нехорошим посетителям. Даже если ошибка будет выявлена, отсутствие информации о ней серьезно затруднит ее применение. Помните про разницу между стадией разработки и рабочим проектом. Вывод ошибок и другой детальной информации - ваш союзник на стадии разработки, и союзник злоумышленника в рабочем варианте. Не стоит также прятать их, комментируя в HTML коде, на 1000-чу посетителей найдется 1, который таки найдет подобные вещи.
Обрабатывайте ошибки.
Напишите обработку SQL запросов таким образом, чтобы информация о них сохранялась в каких-нибудь логах или отсылалась по почте.
Не сохраняйте данные доступа к базе данных в файлах, которые не обрабатываются PHP как код.
Думаю никому не открыл Америки, но по собственному опыту могу сказать, что подобная практика достаточно распространена. Как правило это файл с расширением *.inc
Не создавайте "супер-пользователя" базы данных.
Предоставляйте только права, необходимые для выполнения конкретных задач.
В поиске стоит ограничить минимальное и максимальное количество символов, являющееся параметрами запроса.
Для честного пользователя вполне достаточно от 3-х до 60-70 символов, чтобы удовлетворить свои поисковые интересы, и одновременно вы предупреждаете ситуации, когда поисковым запросом станет том "Войны и мира".
Всегда проверяйте количество возвращенных записей после запроса
Почти на 90% сайтов, написанных на php встречается такая логическая ошибка, особенно это можно наблюдать, когдаделается запрос на основе полученного ID от пользователя, если руками дать скрипту несуществующий ID - мы увидим достаточно интересные результаты работы некоторых скриптов, вместо того чтобы вернуть 404 программа в лучшем случае ничего не сделает и выведет в браузер чистую страницу.
Безопасного вам SQL-я ;)
Все описанное в статье было выполнено в качестве эксперимента на тестовой базе, владельцем которой является автор статьи. Никакие данные других людей не были уничтожены или изменены.
Автор статьи не несет никакой ответственности за использование способов, описанных в данной статье, поскольку предполагалось, что она была написана с целью информирования о уязвимостях программ, написанных с использованием баз данных MySql.