Comments 15
На дворе точно 2015й год? Фигово вы пиарите свою контору, инфе миллион лет
+2
Уважаемый Scratch, мы «контору» не «пиарим» а делимся проблематикой.
На дворе может быть хоть 2050 год, а целая масса сайтов по прежнему узявимы, как с этим быть?
На дворе может быть хоть 2050 год, а целая масса сайтов по прежнему узявимы, как с этим быть?
+3
На самом деле в данной статье очень подробно и понятно описана проблема уязвимости SQL Injection. На мой взгляд для начинающих самое то. Хорошо было бы еще упомяннуть о подготавливаемых запросах, которые поддерживаются mysqli. А вот пиар в конце и правда лишний.
+1
Вы действительно считаете что экранировать кавычки это правильный совет? Сколько раз доводилось эксплуатировать инъекцию, где все параметры проходили через фильтры и все кавычки в них экранировались. Использование фреймворка спасает только при условии, что в механизме экранирования фреймворка нет уязвимостей и разработчик умеет пользоваться фреймворком, в противном же случае из одной проблемы в несколько строк можно сделать проблему в сотню тысяч строк. Тот же mysqli умеет prepared statement, но вы про них ни слова не сказали.
+1
Согласен и соглашаюсь ещё раз.
+1
Ну, мы рассматриваем как это работает в общем виде. Безусловно, prepared statement — хороший и правильный вариант при проектировании новой системы. Если же говорить о приведении в соответствие уже имеющейся, дырявой системы — придется много кода переписать. Экранирование работает нормально, если сами параметры обрамлены в кавычки, как миниум. Также мы сказали, что важно проверять на соответствие типа, и в те SQL-выражения, где значение возможно использовать без кавычек (числа), стринги проходить просто не должны — ну или как минимум abs(intval($val)) должен будет превратить их в ноль.
0
Заменить обычный запрос на prepared в готовом проекте настолько же затратно по времени, как и дописать функции escape_string к параметрам, но зато меньше возможностей для ошибки и лучшая читаемость кода для аудиторов. Недостаточно экранировать только кавычки, ведь внутри них бэкслеш продолжает выполнять свою функцию и в случае, если пользователю будет подконтрольно два параметра из запроса, инъекция пройдёт.
0
UFO just landed and posted this here
То то смотрю знакомый человек, недавно читал «Автоматическая генерация патчей для уязвимого исходного кода». В новостях помню проглядывалась информация на запрос создания такой системы в крупных масштабах за $, но затихло.
Интересовал вопрос пробива хранимых процедур после просмотра:
1) SQL-инъекция. Оборона и нападение (часть 1)
2) SQL инъекция Vladimir Mozhenkov
Спасибо.
Интересовал вопрос пробива хранимых процедур после просмотра:
1) SQL-инъекция. Оборона и нападение (часть 1)
2) SQL инъекция Vladimir Mozhenkov
Спасибо.
0
Рекомендация крайне проста – фильтровать входящие данные.… Иными словами, данные на входе нужно проверять на соответствие формату и выдать пользователю ошибку.
Ну все. Как говорится, «смешались в кучу кони, люди и залпы тычячи орудий».
Дорогие товарищи новички! Пожалуйста, не читайте эту статью — выкиньте советы из нее в корзину. Именно из-за таких вот неправильных «советов» потом и пишутся дырявые системы.
С проблемами безопасности НИКОГДА нельзя бороться высокоэнтропийными средствами. Единственный способ по-настоящему защиться — это использовать автоматические инструменты, которым для своей работы не требуется информация о контексте (т.е. низкнтропийные). В данном случае к таким инструментам относится только один: использование placeholder-ов в запросе и передача переметров запроса отдельно:
$result = query(«select * from tbl where id=?», $id);
Через prepared statement это реализуется или же путем строкового квотинга + вклеивания параметров непосредственно внутрь запроса вместо "?" самой функцией query() — не так важно.
Этого, конечно, недостаточно: нужно еще обеспечить, чтобы sql-запросы в коде перестали восприниматься внутри кода, как строковые литералы (по крайней мере, логически), и начали восприниматься, как литералы специального типа, не допускающие вклейку туда переменных методом «интерполяции». Как? Например, настроить code sniffer, который не позволил бы коммитить код, если в нем параметр query() поступает не в виде литерала в апострофах и без оператора конкатенации, а как-то еще. (Если уровень инженеров позволяет, то можно и на словах договориться, без code sniffer-а.)
Ну или использовать ORM, в котором проблемы sql injection может не быть по определению (в хороших ORM так и есть).
-1
… да, почему я написал «смешалось»: потому что вопрос валидации данных + вывода пользователю внятных сообщений об ошибках и вопрос безопасности — это два совершенно разных и не связанных между собой вопроса. Первый — вероятностный, вопрос юзабилити, удобства пользования, интерфейса. Второй — вопрос жизнестойкости системы. Даже если вы на каждую попытку вместо числа вставить строку будете реагировать 500-й ошибкой, это не уменьшит безопасность системы. А вот если вы хотите эти 500-е ошибки скрыть за красивыми сообщениями пользователю, вот тут уже и используйте валидацию.
Валидация не имеет никакого, я подчеркиваю, НИКАКОГО отношения к защите от инъекций (не важно, sql-инъекций, shell-инъекций, XSS и т.д. — это все едино). Поэтому статья, делающая из валидации и фильтрации инструмент защиты, вредна для новичков.
Валидация не имеет никакого, я подчеркиваю, НИКАКОГО отношения к защите от инъекций (не важно, sql-инъекций, shell-инъекций, XSS и т.д. — это все едино). Поэтому статья, делающая из валидации и фильтрации инструмент защиты, вредна для новичков.
-1
Sign up to leave a comment.
OWASP TOP-10: практический взгляд на безопасность веб-приложений: №1 — инъекции