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