Действительно ли Внедрение SQL является риском сегодня?

Параметры, передаваемые в sql-запросы с веб-страниц, часто являются числовыми идентификаторами. Например, предположим, что у вас есть URL-адрес http://foo.com/page.php?section=34 , из которого идентификатор раздела используется в таком запросе:

SELECT content FROM sections WHERE section_id=$section;

Никаких кавычек, например в вашем примере, и все, что вы укажете после числа в URL-адресе, будет передано в запрос ... Так что риск реален.

Простейшее практическое правило - предположить, что весь пользовательский ввод может быть испорчен. Убедитесь, что типы данных соответствуют вашим ожиданиям, переменные находятся в ожидаемых диапазонах длины / размера, файлы имеют размер и разрешенные типы и т. Д. Могут потребоваться другие проверки не внешних данных - прежде чем вы вызовете какого-либо важного администратора -уровневая функция, сделайте проверку - ($ userlevel! = ADMIN)? die (): important_function ();

Всегда найдется рыба побольше или кто-нибудь, кто толкнет сильнее вас. Избегайте предположений о данных, и вы получите фору.

Существует множество различных способов выполнения SQL-инъекции и довольно много способов обойти основные меры безопасности.

Эти атаки входят в 10 основных уязвимостей веб-приложений (рейтинг №2) согласно OWASP.

Для получения дополнительной информации, пожалуйста, обратитесь к Top 10 2007-Injection Flaws .

Нет, и чем меньше вы беспокоитесь о SQL-инъекции, тем больше вероятность, что она вас ударит.

PHP не может выполнять параметры запроса? Если это возможно (а я был бы удивлен, если бы этого не произошло), это единственное решение, которое смягчает ВСЕ атаки с использованием SQL-инъекций.

Как я уже несколько раз упоминал о stackoverflow ранее, я решительно поддерживаю PDO, просто прекратите использовать старомодный mysql, сделайте себе и своим клиентам большой отдавайте предпочтение и изучите PDO (это действительно просто) и воспользуйтесь преимуществами подготовленных операторов и связанных параметров. Даже если вам не нужны подготовленные операторы с точки зрения производительности, вы все равно получите преимущества безопасности.

Кроме того, я рекомендую сбой всего вашего приложения на лице клиента, если включены волшебные кавычки. Это просто утечка ресурсов, предназначенная для защиты глупых и раздражения умных. (он использует больше ЦП, чем экранирование вручную, потому что кодирует все, даже если оно вам не нужно)

Это все еще большая проблема. Вы не можете предположить, что magic_quotes включен в каждой установке PHP, которую вы можете использовать.

Чтобы проверить, включены ли magic qotes и убрать беспорядок с помощью волшебных кавычек:

if ( get_magic_quotes_gpc() !== 0 ) { $foo = stripslashes( $foo ); }

Затем немного очистите ваши операторы:

$foo = mysql_real_escape_string( $foo );
$sql = "select * from foo where bar='{$foo}'";

и т. д.

На самом деле, вам лучше просто строго отключить magic_quotes , если у вас есть такая возможность.

Надеюсь, это вам поможет.

Это очень активный риск, волшебные цитаты пытаются дать вам решение, но я предпочитаю всегда развиваться без волшебных кавычек. Таким образом, я должен убедиться, что сам действительно избегаю ввода. Кто знает, будут ли волшебные кавычки включаться или отключаться на сервере, на котором фактически развернут сценарий.

О боже ... SQL-инъекция - это не риск, это зияющая дыра в безопасности . В основном он существует на php, потому что API заставляет вас вставлять любые старые данные в ваши SQL-запросы.

Когда я вижу сайт, написанный на PHP или ASP, я просто чувствую запах векторов SQL-инъекций, которыми они пахнут. Люди пытаются защитить свои PHP-приложения с помощью mysql_real_escape_string () и intval () и делают то же самое на других языках. Это ошибка. Это похоже на кодирование на C вместо Java или Python, где в первом случае вы делаете одну ошибку и погибаете, но во втором могут существовать только семантические изъяны.

Я настоятельно призываю людей использовать либо mysqli с подготовленными заявления, или что-нибудь еще, что параметризовано , подстановка текста в код, а затем его интерпретация - это просто плохая практика в первую очередь IMHO.

С другой стороны, волшебные кавычки PHP просто глупы и, к счастью, устарели. Это может принести только больше вреда, чем пользы. Если вы полагаетесь на волшебные цитаты, это означает, что ваше приложение будет принадлежать, когда волшебные кавычки отключены. Точно так же это может нарушить работу других приложений, которые не ожидают экранированных строк во входных данных.

Эта конкретная атака не работает, так как mysql_query выполнит только один оператор.

Я все еще могу злоупотреблять вашим кодом, например, если я установил для id значение SELECT пароль ОТ пользователей WHERE Username = 'admin' У меня может быть шанс заставить вашу систему открывать некоторую внутреннюю информацию.

В принципе, если вы разрешите вводить нефильтрованные данные в свой SQL, будет очень много творческие способы как создания данных, которых вы не ожидали, так и раскрытия данных, которые вы не планировали!

Магические кавычки не принимают во внимание кодировку символов, и поэтому уязвимы для атак, основанных на многобайтовых символах.

Что касается сегодняшнего риска , Поисковые запросы Google обнаруживают бесчисленное количество уязвимых сайтов. Об уязвимости SQL-инъекции для Bugzilla было сообщено примерно 10 сентября. Так что да, сайты все еще находятся в опасности. Должны быть? Инструменты существуют для предотвращения инъекций, поэтому нет.

Хех, в этом случае вы спасены, установив для параметра magic_quotes_gpc значение «включено».

Скоро вы облажаетесь .

Пример таблиц bobby не будет работать с интерфейсом mysql, потому что он не выполняет несколько запросов за один вызов. Интерфейс mysqli уязвим для атак с несколькими запросами. Интерфейс mysql более уязвим для атаки повышения привилегий:

В вашей форме я ввожу учетную запись: admin пароль: 'или 1 = 1 - , чтобы ваш типичный логин sql : выберите * из пользователей, у которых user_name = '$ admin' и пароль = '$ password' . Или заставляет это быть правдой и позволяет вам войти в систему.

Всякий раз, когда создается SQL из строк, SQL-инъекция представляет собой реальную опасность.

Я также обнаружил, что попытки избежать создания SQL из строк - бессмысленное занятие. Рано или поздно полная форма вашего SQL (а не только вещи, которые могут быть параметрами) должна быть сгенерирована во время выполнения.

Еще нет сегодня , но сейчас только 20:34 UTC

Атака на базу данных вакансий Guardian демонстрирует трудности с безопасностью базы данных, 06 ноября 2009 г.

Взлом веб-сайта Guardian Jobs Возможно, это была SQL-инъекция, а не «сложная» атака, 27 октября 2009 г.

Самая крупная кража личных данных в истории была достигнута в 2007 году с использованием SQL-инъекции уязвимость: см. « Атаки с использованием SQL-инъекций привели к нарушениям в Heartland, Hannaford » (ComputerWorld, 18.08.2009).

OWASP сообщил в 2007 , что атаки с использованием инъекций (из которых SQL инъекция является одним из примеров) по-прежнему является одной из наиболее распространенных проблем безопасности программного обеспечения.

Вы также можете поискать последние Новости SQL-инъекций и найти множество случаев, о которых сообщается каждый месяц.

Однако пример в мультфильме XKCD не обязательно самый распространенный тип эксплойта. Удаление таблицы путем выполнения второго оператора SQL в одном запросе, вероятно, не принесет злоумышленнику большой выгоды в плане ценных данных, это будет просто вандализмом.

Кроме того, некоторые интерфейсы запросов в любом случае запрещают мультизапрос по умолчанию. То есть клиентский API базы данных выполняет только один оператор для данной строки SQL, независимо от точек с запятой. Это опровергает пример, показанный в карикатуре.

примечание: метод PDO query () , как известно, поддерживает мультизапрос по умолчанию. Таким образом, он подвержен атаке в стиле XKCD.

Как отмечали другие люди, более вероятный риск состоит в том, что SQL-инъекция изменит логику SQL-выражений и применит ваш запрос к дополнительным строки помимо тех, которые вы запланировали.

Например:

$sql = "UPDATE Users SET PASSWORD = MD5('" . $_POST["password"] . "'||salt) " . 
       "WHERE user_id = " . $_POST["userid"];

Что произойдет, если я отправлю запрос с параметром ИД пользователя , установленным в строку 123 ИЛИ ИД пользователя = 456 ? Я бы сбросил свой собственный пароль (идентификатор пользователя 123), а также пароль идентификатора пользователя 456. Даже хеширование пароля с солью для каждого пользователя не защитит от этого. Теперь я могу войти в любую учетную запись.

Есть много способов внедрения SQL-кода.

Нет, это все еще очень актуально.

Как и XSS и CSRF. Никогда не недооценивайте важность правильной фильтрации входного сигнала.