Знаки, что SQL-оператор опасен
Я хочу разработать функцию в PHP, который проверяет, насколько опасный SQL-оператор. Когда я говорю опасный, я имею в виду, определенные символы, символы или строки, которые используются для получения данных из базы данных, которую не должен видеть пользователь.
Например:
ВЫБЕРИТЕ * ОТ пользователей ГДЕ идентификатор пользователя = '1'
может быть введен несколькими способами. Хотя я чищу параметрические усилители, я также хочу контролировать, как безопасный запрос состоит в том, чтобы работать.
Заранее спасибо
5 ответов
Вы пытаетесь найти решение проблемы, которой не должно быть . Вы должны использовать подготовленные (предварительно скомпилированные) запросы, тогда вам никогда не придется беспокоиться о SQL-инъекции и экранировании, поскольку сам запрос является фиксированным, и только аргументы являются переменными.
См. Здесь пример их использования в PHP: http://mattbango.com/notebook/web-development/prepared-statements-in-php-and-mysqli/
Еще одним преимуществом является то, что это тоже быстрее, по крайней мере, для MySQL, поскольку серверу не нужно каждый раз анализировать запрос.
Я согласен, что параметризованные запросы - лучший способ. Однако большинство php/mysql приложений используют mysql_query(), и большинство веб-приложений также уязвимы к той или иной форме sql-инъекции.
Suhosin Hardened PHP установлен по умолчанию на многих LAMP системах и имеет функцию под названием "экспериментальная эвристика SQL инъекций", но она не разрушает никаких эксплойтов, о которых я знаю. Лучшим решением является Web Application Firewalls (WAF), который ищет атаки типа sql injection в необработанном HTTP запросе. WAFs требуются PCI-DSS и широко используются в Интернете сегодня, потому что они работают.
Существует приложение под названием GreenSQL, которое делает ставку на то, что инжектированные запросы выглядят иначе. По большей части это безопасная ставка, но SQL - это свободно формируемый декларативный язык, и существует множество способов, которыми злоумышленник может переписать запрос для выполнения той же атаки. Короче говоря, этот тип защиты остановит некоторые атаки, но он несовершенен по сравнению с параметризованными запросами. WAF'ы страдают от той же проблемы, что и GreenSQL: можно закодировать или замаскировать атаку так, что она проскользнет мимо массивной библиотеки регулярных выражений, используемых для обнаружения атак. Ответ Бобинса на этот вопрос меня просто смешит, его мнение справедливо и для процесса эксплуатации.
Есть три области, на которых вы хотите сосредоточиться:
- Очистите ввод. Это не означает удаление символов, это означает определение приемлемого. белого списка и отклонения исключений
- Параметризованные пользователем операторы SQL вместо создания объединенная строка синтаксиса и значений .
- Защитите уровень данных, насколько можете , применив принцип наименьших прав и ограничив доступ общедоступных пользователей только к абсолютно важным функциям. т.е. запрещает доступ для записи ко многим таблицам.
Вы можете найти это полезным: OWASP Top 10 для разработчиков .NET, часть 1: Injection
Он написан для разработчиков .NET, но принципы в равной степени передаются и в PHP.
В этой статье есть несколько хороших примеров предотвращения sql-инъекций и хорошие объяснения проблем sql-инъекций.
Вы не «очищаете» параметры. Это нарушит ваши данные. Почему кому-то по имени «О'Рейли» не разрешается вводить свое имя в вашу базу данных?
Чтобы поместить любую строку в строковый литерал SQL, вам нужно экранировать его или, лучше использовать параметризованные операторы, чтобы вы этого не делали. нужно беспокоиться о SQL-инъекции. «Санитарная обработка» на входе - неправильный подход: он добавляет ненужные ограничения и не решает всей проблемы.
Если вы создаете оператор SQL, в котором есть любая переменная строка, которую вы не экранировали, это небезопасно, точка. Будь то простейший SELECT * или чрезвычайно сложная загрузка объединений и подзапросов, всего одна инъекция сделает вас уязвимым.