Подтвердить что ты не робот

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

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

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

пример кода:

<?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.

4b9b3361

ОТВЕТЫ

Ответ 1

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

руководство по PHP по магическим цитатам объясняет все.

Ответ 2

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

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

Ответ 4

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

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

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

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

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

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

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

Например:

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

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

Существует множество способов внедрения SQL-инъекций.

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

Чтобы узнать, включены ли магические кавычки и очистить беспорядок от магических цитат:

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

Затем немного очистите свои утверждения:

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

и др.

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

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

Для получения дополнительной информации см. Топ-10 недостатков 2007-инъекции.

Ответ 14

Нет, и чем меньше вы беспокоитесь о SQL Injection, тем больше вероятность того, что вы его поразите.

Ответ 15

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

SELECT content FROM sections WHERE section_id=$section;

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

Ответ 16

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

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

Ответ 18

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

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

Ответ 19

Мне нужно разработать для сервера, у которого нет возможности отключить 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);

}

Ответ 20

По OWASP 2017 10 лучших, все же Инъекция - самая распространенная и опасная атака.

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

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