Сегодня SQL-инъекции риск?

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

Я создал PHP-файл и таблицу в базе данных, имел значение, прошедшее через $_GET и попытался удалить таблицу, выполнив bob'); drop table students; -- и это не сработало. PHP автоматически избегает \' и запрос имеет ошибку, никакого вреда. Же проблема, когда пытался повторить вход "атаки" как AND WHERE 1=1 etc.

пример кода:

<?php
$id = $_GET['id'];

$sql = "INSERT INTO Users (Username) VALUES ($id)";
echo $sql;
mysql_query($sql) or die(mysql_error());

и я sql.php?id=1); delete from Users; --

так это какая-то датированная вещь, которая применялась во времена PHP3 или что-то еще, и в настоящее время даже новички защищены от таких вещей, как волшебные цитаты?

Я использую PHP5 на Ubuntu.

20 ответов


совсем наоборот. магические кавычки устарели в PHP5 и будут полностью удалены в PHP 5.4, поскольку они принесли больше путаницы в мир программирования, чем пользы. Проверка того, активны ли магические кавычки, и избегание любого ввода SQL скрупулезно, если это необходимо, по-прежнему очень, очень важно... Нет причин чувствовать себя плохо, хотя, мы все были там, и моя неизвестная задница была спасена волшебными цитатами бесчисленное количество раз:)

на в PHP руководство на magic quotes объясняет все.


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

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


Хех, вы спасены в этом случае, имея magic_quotes_gpc установите значение "on".

ты скоро будешь в жопе.


крупнейшая кража личных данных в истории была достигнута в 2007 году путем использования уязвимости SQL-инъекции: см."SQL инъекции атаки привели к Heartland, Hannaford нарушения " (ComputerWorld, 8/18/2009).

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

вы также можете искать последние SQL-инъекции Новости и найти много случаев каждый месяц.

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

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

Примечание: ПДО по query() способ известен поддержка multi-query по умолчанию. Так это is восприимчив к атаке в стиле XKCD.

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

например:

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

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

существует множество способов SQL-инъекции.


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

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


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

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

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


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

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

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

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


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


Это все еще большая проблема. Вы не можете предположить, что 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}'";

etc.

на самом деле, вам лучше просто строго поворачивать magic_quotes Если у вас есть возможность сделать это.

Я надеюсь, что это поможет вам.


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

в вашей форме я набираю account:admin пароль: ' or 1=1 -- Так что ваш типичный логин sql:select * from users where user_name = '$admin' and password = '$password'. Or заставляет это быть правдой и позволяет вам войти в систему.


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


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

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


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

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

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


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


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

SELECT content FROM sections WHERE section_id=$section;

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


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



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

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


Я должен разработать для сервера, который не имеет возможности отключить magic_quotes! Я включаю это на каждой странице, чтобы отменить эффекты магических цитат, поэтому я могу сделать правильный побег без "двойного побега". Даже при том, что я чувствую вкус рвоты только от чтения этого, я не нашел лучшего решения.

if (get_magic_quotes_gpc()) {

    $process = array(&$_GET, &$_POST, &$_COOKIE, &$_REQUEST);

    while (list($key, $val) = each($process)) {

        foreach ($val as $k => $v) {

            unset($process[$key][$k]);

            if (is_array($v)) {

                $process[$key][stripslashes($k)] = $v;

                $process[] = &$process[$key][stripslashes($k)];

            } else {

                $process[$key][stripslashes($k)] = stripslashes($v);

            }

        }

    }

    unset($process);

}

по состоянию на OWASP 2017 Top 10, все еще впрыска самая случившаяся и опасная атака.

"SQL-инъекция всегда является риском номер один. Это отражение того, сколько инцидентов там, а также других факторов, которые держат его очень высоко " Трой Хант-основатель breach site haveibeenpwned.com

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