Является ли инъекция 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.
20 ответов
Наоборот. Магические кавычки устарели в PHP5 и будут полностью удалены в PHP 5.4, так как они приносили больше путаницы в мир программирования, чем приносили пользу. Проверка, активны ли магические кавычки, и тщательный выход из любого ввода SQL, если это необходимо, все еще очень, очень важно... Хотя нет причин чувствовать себя плохо, мы все были там, и моя неосознаваемая задница была спасена бесчисленными магическими кавычками раз:)
Руководство PHP по магическим кавычкам объясняет все.
Нет, это все еще очень актуально.
Как и XSS и CSRF. Никогда не стоит недооценивать важность правильной фильтрации входных данных.
Хех, вы спасены в этом случае, имея magic_quotes_gpc установить на "вкл".
Крупнейшая кража личных данных в истории была достигнута в 2007 году с помощью уязвимости SQL-инъекций: см. " Атаки SQL-инъекций привели к нарушениям в Heartland и Hannaford " (ComputerWorld, 18.08.2009).
В 2007 году OWASP сообщила, что инъекционные атаки (примером которых является 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"];
Что происходит, когда я отправляю запрос с параметром userid установить на строку 123 OR userid=456? Я бы сбросил свой собственный пароль (идентификатор пользователя 123), а также пароль идентификатора пользователя 456. Даже хеширование пароля с солью для пользователя не защитит от этого. Теперь я могу войти в любой аккаунт.
Существует множество способов внедрения SQL-инъекций.
Магические кавычки не учитывают кодировку символов и поэтому уязвимы для атак, основанных на многобайтовых символах.
Что касается риска сегодня, поиски в Google приводят к появлению бесчисленных уязвимых сайтов. Около 10 сентября для Bugzilla была обнаружена уязвимость SQL-инъекций. Так что да, сайты все еще находятся в опасности. Должны ли они быть? Инструменты для предотвращения инъекций, поэтому нет.
Эта конкретная атака не работает, так как 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 просто глупы и, к счастью, устарели. Это может принести больше вреда, чем пользы. Если вы полагаетесь на магические кавычки, это означает, что ваше приложение будет принадлежать, когда магические кавычки отключены. Точно так же это может сломать другие приложения, которые не ожидают экранированных строк во входных данных.
Пример таблиц Бобби не будет работать с интерфейсом mysql, поскольку он не выполняет несколько запросов за один вызов. Интерфейс mysqli уязвим для атаки нескольких запросов. Интерфейс mysql более уязвим для атаки повышения привилегий:
В вашей форме я набираю аккаунт: admin пароль: ' or 1=1 -- так что ваш типичный логин sql: select * from users where user_name = '$admin' and password = '$password', Или заставляет это быть правдой и позволяет вам войти.
Это все еще большая проблема. Вы не можете предполагать, что 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 если у вас есть возможность сделать это.
Я надеюсь, что это поможет вам.
Не может ли PHP сделать параметры запроса? Если это возможно (как я бы удивился, если бы этого не произошло), это единственное решение, которое смягчает ВСЕ атаки SQL-инъекций.
Это очень активный риск, магические кавычки пытаются дать вам решение, но я предпочитаю всегда развиваться с отключенными магическими кавычками. Таким образом, я должен убедиться, что я на самом деле избегаю входов сам. Кто знает, будут ли магические кавычки включаться или выключаться на сервере, где фактически развернут скрипт.
Как я уже упоминал несколько раз о stackru, я решительный сторонник PDO, просто перестаньте использовать старомодный mysql, сделайте себе и своим клиентам большую услугу и изучите PDO (это действительно просто), а также воспользуйтесь подготовленными утверждениями и связанные параметры. Даже если вам не нужны подготовленные заявления с точки зрения производительности, вы все равно получаете преимущества безопасности.
Кроме того, я рекомендую разбить все ваше приложение на клиентском компьютере, если для него включены волшебные кавычки. Это просто трата ресурсов, предназначенных для защиты глупых и раздражающих умных. (он использует больше процессоров, чем вручную, потому что кодирует все, даже если вам это не нужно)
Существует много различных способов выполнения SQL-инъекций и довольно много способов обойти основные меры предосторожности.
Эти атаки были в числе 10 уязвимостей веб-приложений (ранг #2) в соответствии с OWASP.
Для получения дополнительной информации, пожалуйста, обратитесь к Топ 10 недостатков впрыска 2007 года.
Нет, и чем меньше вы беспокоитесь о внедрении SQL-кода, тем больше вероятность, что вы пострадаете от него.
Самое простое правило - предположить, что все пользователи input может быть испорчен. Убедитесь, что типы данных соответствуют вашим ожиданиям, переменные находятся в ожидаемых диапазонах длины / размера, файлы соответствуют размеру и типам, которые вы разрешаете, и т. Д. Можно провести другие проверки внешних данных, прежде чем вызывать какого-либо важного администратора. -уровневая функция, сделайте проверку - ($userlevel != ADMIN)?die():important_function();
Всегда есть более крупная рыба или кто-то, кто больше, чем ты. Избегайте предположений о данных, и у вас есть преимущество.
Параметры, передаваемые в sql-запросы с веб-страниц, обычно являются числовыми идентификаторами. Например, давайте предположим, что у вас есть URL http://foo.com/page.php?section=34 из которого идентификатор раздела используется в запросе, подобном следующему:
SELECT content FROM sections WHERE section_id=$section;
Нет кавычек, которые нужно экранировать, как в вашем примере, и все, что вы поместите после числа в URL, будет передано запросу... Таким образом, риск реален.
Я должен разработать сервер, у которого нет возможности отключить 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-инъекция - это всегда риск номер один. Это отражает только количество инцидентов, а также другие факторы, которые поддерживают его на высоком уровне", - считает Трой Хант, основатель сайта взлома haveibeenpwned.com.
Напомним, что с помощью SQL-инъекции мы можем выгружать всю базу данных, управлять веб-сервером, загружать веб-оболочку и т. Д.
Еще не сегодня, но только 20:34 UTC
Атака базы данных заданий Guardian демонстрирует трудности безопасности базы данных, 6 ноября 2009 г.
Взлом сайта Guardian Jobs, возможно, был инъекцией SQL, а не "сложной" атакой, 27 октября 2009 г.
Всякий раз, когда создается SQL из строк, внедрение SQL представляет собой реальную опасность.
Я также обнаружил, что пытаться избежать построения SQL из строк - бессмысленное усилие. Рано или поздно полная форма вашего SQL (а не только вещи, которые могут быть параметрами) должна быть сгенерирована во время выполнения.