Является ли внедрение 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 answers
Совсем наоборот. Магические кавычки устарели в PHP5 и будут полностью удалены в PHP 5.4, так как они внесли больше путаницы в мир программирования, чем принесли пользы. Проверка того, активны ли магические кавычки, и скрупулезное избегание любого ввода SQL, если это необходимо, по-прежнему очень и очень важно... Хотя нет причин чувствовать себя плохо, мы все были там, и моя неосведомленная задница была спасена волшебными цитатами бесчисленное количество раз:)
В Руководство по PHP на волшебных цитатах все объясняется.
Нет, это все еще очень актуально.
Как и XSS и CSRF. Никогда не стоит недооценивать важность правильной фильтрации входных данных.
Хех, в этом случае вы спасены тем, что у вас есть magic_quotes_gpc установите значение "включено".
Крупнейшая кража личных данных в истории была совершена в 2007 году с использованием уязвимости SQL-инъекции: см. " Атаки с использованием SQL-инъекций привели к нарушениям в Хартленде, Ханнафорд" (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"];
Что происходит, когда я отправляю запрос с параметром userid установить в строку 123 OR userid=456? Я бы сбросил свой собственный пароль (идентификатор пользователя 123), а также пароль пользователя 456. Даже хэширование пароля с помощью соли для каждого пользователя не защитит от этого. Теперь я могу войти в любую учетную запись.
Существует множество способов выполнения SQL-инъекции.
Магические кавычки не учитывают кодировку символов и, следовательно, уязвимы для атак, основанных на многобайтовых символах.
Что касается того, что сегодня это риск, поисковые запросы Google обнаруживают бесчисленное множество уязвимых сайтов. Около 10 сентября сообщалось об уязвимости SQL-инъекции для Bugzilla. Так что, да, сайты все еще находятся в зоне риска. Должны ли они быть такими? Инструменты существуют для предотвращения инъекций, так что нет.
Эта конкретная атака не работает, так как mysql_query выполнит только один оператор.
Я все еще могу злоупотреблять вашим кодом, хотя, например, если бы я установил идентификатор 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 с подготовленными инструкциями, либо что-либо еще, что параметризовано, подставляя текст в код, а затем интерпретируя его, это просто плохая практика, в первую очередь IMHO.
С другой стороны, волшебные кавычки PHP просто глупы и, к счастью, устарели. Это может принести только больше вреда, чем пользы. Если вы полагаетесь на волшебные цитаты, это означает, что ваше приложение будет принадлежит, когда волшебные кавычки отключены. Аналогично, это может привести к поломке других приложений, которые не ожидают экранированных строк во входных данных.
Это очень активный риск, magic quotes пытается дать вам решение, но я предпочитаю всегда развиваться с отключенными magic quotes. Таким образом, я должен убедиться, что сам действительно избегаю входов. Кто знает, будут ли волшебные кавычки включены или выключены на сервере, где фактически развернут скрипт.
Это все еще большая проблема. Вы не можете предполагать, что 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, если у вас есть такая возможность.
Я надеюсь, что это поможет вам.
Пример таблиц Бобби не будет работать с интерфейсом mysql, потому что он не выполняет несколько запросов за один вызов. Интерфейс mysqli уязвим для атаки несколькими запросами. Интерфейс mysql более уязвим для атаки с повышением привилегий:
В вашей форме я ввожу учетную запись: admin пароль: ' or 1=1 --, чтобы ваш обычный логин sql: select * from users where user_name = '$admin' and password = '$password'. Операция "или" заставляет это быть правдой, и давайте войдем в систему.
Не может PHP выполнять параметры запроса? Если это возможно (как я был бы удивлен, если бы это было не так), это единственное решение, которое смягчает ВСЕ атаки с использованием SQL-инъекций.
Как я уже несколько раз упоминал ранее в stackoverflow, я убежденный сторонник PDO, просто прекратите использовать старомодный mysql, сделайте себе и своим клиентам большое одолжение и изучите PDO (это действительно легко) и воспользуйтесь преимуществами подготовленных инструкций и связанных параметров. Даже если вам не нужны подготовленные отчеты с точки зрения производительности, вы все равно получаете преимущества в плане безопасности.
Кроме того, я рекомендую разбить все ваше приложение на глазах у клиентов, если для magic quotes установлено значение вкл. Это просто истощение ресурсов, предназначенных для защиты глупых и раздражения умных. (он использует больше процессора, чем экранирование вручную, потому что он кодирует все, даже если вам это не нужно)
Существует множество различных способов выполнения SQL-инъекции и довольно много способов обойти основные меры предосторожности.
Эти атаки входят в топ-10 уязвимостей веб-приложений (ранг №2) по версии OWASP.
Для получения дополнительной информации, пожалуйста, обратитесь к Топ-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);
}
Согласно Топ-10 OWASP 2017 , Инъекция по-прежнему является самой распространенной и опасной атакой.
"Внедрение SQL всегда является риском номер один. Это отражает количество инцидентов, а также другие факторы, которые поддерживают его на очень высоком уровне" Трой Хант - основатель сайта breach haveibeenpwned.com
Просто помните, что с помощью SQL-инъекции мы можем сбрасывать всю базу данных, управлять веб-сервером, загружая веб-оболочку и т. Д.