Я читал об атаках SQL-инъекций и о том, как их избежать, хотя я никогда не могу заставить «ужасные» примеры работать, например, видеть этот пост .
Я создал файл PHP и таблицу в базе данных, имел значение, прошедшее через $_GET и попытался удалить таблицу, выполнив bob'); drop table students; -- bob'); drop table students; -- bob'); drop table students; -- и это не сработало. PHP автоматически ускользает от \' и запрос имеет ошибку, никакого вреда. Такая же проблема при попытке реплицировать AND WHERE 1=1 «атаки» типа 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; -- sql.php?id=1); delete from Users; --
Так это некоторые устаревшие вещи, которые раньше применялись во времена PHP3 или что-то в этом роде, и теперь даже новички защищены от таких вещей, как волшебные кавычки?
Я использую PHP5 на Ubuntu.
Наоборот. Магические кавычки устарели в PHP5 и будут полностью удалены в PHP 5.4 , поскольку они принесли больше путаницы в мир программирования, чем они сделали хорошо. Проверка того, являются ли магические кавычки активными, и при необходимости избегать любого ввода SQL, по-прежнему очень важна … Нет причин чувствовать себя плохо, хотя мы все были там, и моя неосознанная задница была спасена магическими цитатами бесчисленными раз 🙂
Руководство PHP по магическим цитатам объясняет все.
Нет, это все еще очень актуально.
Как и XSS и CSRF. Никогда не недооценивайте важность правильной фильтрации входных данных.
Хе-хе, вы спасены в этом случае, если magic_quotes_gpc установлен на «on».
Скоро вы будете ввернуты .
Самая большая идентификационная кража в истории была достигнута в 2007 году благодаря использованию уязвимости SQL-инъекции: см. « Атаки SQL-инъекций привели к нарушениям Хартленда, Ханнафорда » (ComputerWorld, 8/18/2009).
OWASP сообщила в 2007 году, что инъекционные атаки (из которых SQL-инъекция является одним из примеров) продолжают оставаться одной из наиболее распространенных проблем безопасности программного обеспечения.
Вы также можете найти последние новости о введении SQL и найти много случаев, сообщаемых каждый месяц.
Однако пример в мультфильме XKCD не обязательно является наиболее распространенным типом эксплойта. Отбрасывание таблицы путем выполнения второго оператора SQL в одном запросе, вероятно, не принесло бы злоумышленнику значительного количества ценных данных, это было бы просто вандализмом.
Кроме того, некоторые интерфейсы запросов в любом случае не разрешают многопользовательский запрос . То есть API-интерфейс клиента базы данных выполняет только один оператор, заданный строкой SQL, независимо от точки с запятой. Это побеждает пример, показанный в мультфильме.
Примечание: метод query() PDO, как известно, поддерживает множественный запрос по умолчанию. Таким образом, он восприимчив к атаке типа 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 Injection была зарегистрирована для Bugzilla около 10 сентября. Итак, да, сайты все еще находятся под угрозой. Должны ли они быть? Инструменты там, чтобы предотвратить инъекцию, нет.
Эта конкретная атака не работает, поскольку mysql_query выполнит только один оператор.
Я все равно могу злоупотреблять вашим кодом, например, если я настроил идентификатор как SELECT password FROM Users WHERE Username='admin' меня может быть шанс на бой, чтобы заставить вашу систему выставить некоторую внутреннюю информацию.
В принципе, если вы разрешаете нефильтрованный ввод в свой SQL, будут некоторые очень творческие способы как для создания данных, которые вы не ожидали, так и для разоблачения данных, которые вы не намеревались!
О, мой .. SQL Injection – это не риск, это зияющая дыра в безопасности . Он в основном существует в php, потому что API заставляет вас хотеть интерполировать любые старые данные в ваши SQL-запросы.
Когда я вижу сайт, написанный на PHP или ASP, я просто чувствую запах инъекций SQL, на которые они падают. Люди пытаются обеспечить свои PHP-приложения с помощью mysql_real_escape_string() и intval() и аналогичным образом работают на других языках. Это ошибка. Это похоже на кодирование в C вместо Java или Python, где в первом вы делаете одну ошибку, и вы мертвы, но в последнем могут существовать только семантические изъяны.
Я настоятельно призываю людей использовать либо mysqli с подготовленными операторами, либо что-то еще, что параметризуется , заменяя текст на код, а затем интерпретировать его – это просто плохая практика, в первую очередь, IMHO.
С другой стороны, магические цитаты PHP просто глупы и, к счастью, устарели. Это может принести больше вреда, чем пользы. Если вы полагаетесь на магические кавычки, это означает, что ваше приложение будет принадлежать, когда магические кавычки будут отключены. Аналогично, он может разорвать другие приложения, которые не ожидают экранированных строк в входах.
Это очень активный риск, магические цитаты пытаются дать вам решение, но я предпочитаю всегда развиваться с магическими цитатами. Таким образом, я должен убедиться, что я действительно избегаю входных данных. Кто знает, будут ли включены или отключены магические кавычки на сервере, где фактически запущен скрипт.
Это все еще большая проблема. Вы не можете предположить, что 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 если у вас есть возможность сделать это.
Надеюсь, это вам поможет.
Пример таблицы bobby не будет работать с интерфейсом mysql, поскольку он не выполняет несколько запросов в одном вызове. Интерфейс mysqli уязвим для атаки нескольких запросов. Интерфейс mysql более уязвим для атаки повышения привилегий:
В вашей форме я ввожу учетную запись: admin password: ' or 1=1 -- так, чтобы ваш типичный login sql: select * from users where user_name = '$admin' and password = '$password' . Это или делает это истинным, и давайте войдем.
Не можете ли PHP выполнить параметры запроса? Если это возможно (как я был бы удивлен, если бы это не так), это единственное решение, которое смягчает ВСЕ атаки SQL-инъекций.
Как я уже говорил несколько раз о stackoverflow раньше, я являюсь сильным сторонником PDO, просто прекратите использовать старую модульную mysql, сделайте себе и своих клиентов большую пользу и изучите PDO (это очень просто) и воспользуйтесь подготовленными заявлениями и связанных параметров. Даже если вы не нуждаетесь в готовых отчетах, вы по-прежнему получаете преимущества безопасности.
Кроме того, я рекомендую сбой всего приложения на лице клиентов, если установлены магические кавычки. Это просто утечка ресурсов, предназначенных для защиты немых и раздражающих умных. (он использует больше CPU, чем экранирование вручную, потому что он кодирует все, даже если вам это не нужно)
Существует множество различных способов выполнения SQL Injection и довольно много способов обойти основные меры предосторожности.
Эти атаки попали в первую десятку уязвимостей веб-приложений (ранг № 2) в соответствии с OWASP.
Для получения дополнительной информации см. Top 10 2007-Injection Flaws .
Нет, и чем меньше вы беспокоитесь о SQL Injection, тем больше вероятность того, что вы попадете в нее.
Параметры, переданные sql-запросам с веб-страниц, как правило, являются числовыми идентификаторами. Например, предположим, что у вас есть URL-адрес http://foo.com/page.php?section=34, из которого идентификатор раздела используется в запросе типа:
SELECT content FROM sections WHERE section_id=$section;
Нет кавычек, чтобы убежать, как в вашем примере, и все, что вы ставите после того, как номер в URL-адресе будет передан в запрос … Таким образом, риск все-таки реальный.
Самое простое правило состоит в том, чтобы предположить, что все input пользователя могут быть испорчены. Убедитесь, что типы данных – это то, что вы ожидаете, переменные находятся в диапазонах длины и размера, которые вы ожидали, файлы имеют размер и типы, которые вы разрешаете, и т. Д. Другие проверки не внешних данных могут быть оправданы – прежде чем вы вызовете какой-нибудь важный администратор -level, выполните проверку – ($userlevel != ADMIN)?die():important_function();
Всегда есть большая рыба, или кто-то, кто сильнее, чем вы. Избегайте предположений о данных, и у вас есть начало.
Не сегодня , но это всего лишь 20:34 UTC
Атака базы данных заданий Guardian демонстрирует трудности безопасности базы данных, 06 ноября 2009 г.
Возможно, сайт Guardian Jobs взломал SQL-инъекцию, а не «сложную» атаку, 27 октября 2009 г.
Всякий раз, когда вы создаете 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); }с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); }с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); }
Согласно 10-му OWASP 2017 , все еще Инъекция – самая распространенная и опасная атака.
«SQL-инъекция всегда является риском номер один. Это отражает только то, сколько инцидентов там, а также другие факторы, которые держат его очень высоко». Трой Хант – основатель сайта нарушения сайта hasibeenpwned.com
Просто помните, используя SQL-инъекцию, мы можем сбрасывать всю базу данных, управлять веб-сервером, загружая веб-оболочку и т. Д.