Инъекция Php & Sql - UTF8 POC - PullRequest
Новая
       16

Инъекция Php & Sql - UTF8 POC

15 голосов
/ 28 февраля 2011

Существует много разговоров о том, что addlashes и функция mysql_real_escape небезопасны для предотвращения инъекций.Правда в том, что даже большие фреймворки или CMS, такие как Wordpress, используют эти функции, и они до сих пор делают отличную работу.

Я знаю, что есть некоторые конкретные сценарии использования кодировки GBK, или utf8_decode можно использовать для внедрения некоторыхSQL-код или несколько простых примеров, таких как 1' OR 1 --, которые можно использовать, когда есть простое, где задействовано.

Однако, после небольшого исследования кажется очень трудным внедрить что-то в простой запрос с помощью аддеш илиmysql_real_escape используется, если кодировка UTF-8, и давайте признаем, что это наиболее распространенный сценарий.

Итак, учитывая этот скрипт новичка, pls предоставляют POC для инъекции sql (помните кодировку UTF-8) 

$mysql['username'] = addslashes($_POST['username']);
$mysql['password'] = addslashes($_POST['password']);

$sql = "SELECT *
FROM users
WHERE username = '{$mysql['username']}'
AND password = '{$mysql['password']}'";

Обновление - мне просто нужен простой пример, а не полное раскрытие процесса.Даже ссылка из Google может работать.

1 Ответ

11 голосов
/ 28 февраля 2011

Обновление 2 :

После дальнейших исследований версии MySQL до 5.0.77 могут быть уязвимы для проблемы GBK в сочетании только с SET NAMES. Ранее считалось, что только 5.0.22 и более ранние были уязвимы.

Это означает, что если вы используете версии PHP до до 5.2, в которых были введены mysql_set_charset / mysqli_set_charset, ваш код может быть уязвим при определенных, хорошо продуманных условиях.

Если вы застряли на PHP 5.1, убедитесь, что вы используете MySQL 5.0.77 или более позднюю. 5.0.77 "всего" два года, но его поместили в репозитории для RHEL / CentOS 5.x, более популярного дистрибутива, использующего серии MySQL 5.0.x и серии PHP 5.1.x.

Получить обновления, люди!

Обновление 1 : Другой недавний вопрос раскрыл источник информации о GBK: Исправление в MySQL 5.0.22 . Версии, более ранние, чем это, сильно уязвимы при использовании чего-либо, кроме mysql_real_escape_string в сочетании с mysql_set_charset вместо просто SET NAMES , Эквивалент mysqli называется mysqli_set_charset.

Похоже, что в PDO нет эквивалента mysql_set_charset. Это может быть связано либо с тем, что он может использовать собственные подготовленные операторы MySQL, которые могут быть защищены от этой проблемы, либо с достаточностью SET NAMES для их базового механизма экранирования, чтобы работать должным образом.

Независимо от того, используете ли вы какую-либо версию MySQL до 5.0.22 5.0.77 и не принимаете крайних мер, чтобы гарантировать, что вы передаете только строки в известном символе установите , вы можете оказаться открытыми для атаки.

Я оставляю оставшуюся часть моего оригинального поста без изменений, но я обновил tldr.

Существует много разговоров о том, что addlashes и функция mysql_real_escape небезопасны для предотвращения инъекций

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

Если вы застряли в гетто доисторического комка дерьма, известного как расширение «mysql» (вместо использования PDO или mysqli), mysql_real_escape_string - это лучшая защита, которую вы получаете, когда вам нужно объединить вместе несколько SQL.

Я знаю, что есть некоторые конкретные сценарии использования кодировки GBK, или utf8_decode может использоваться для введения некоторого кода SQL

Вероятно, вы думаете о создании искаженных последовательностей UTF-8, однако я только когда-либо видел это как механизм XSS , а не механизм внедрения SQL. Пропуск строк через iconv с //IGNORE//TRANSLIT должен быть достаточно хорошей защитой (обычно путем обрезания строки в точке неправильной последовательности, что является приемлемым режимом сбоя при атаке - неправильно сформированные последовательности никогда не должны встречаться в законных запросах).

Кроме того, хотя в нелатинских языках существует множество символов «кавычек», MySQL вполне прилично выполняет только обратный тик и двойные кавычки для идентификаторов и одинарные кавычки для строковых значений.

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

mysql_real_escape_string, с другой стороны, разработан со знанием встроенного набора символов соединения, поэтому он не избежит последовательности, если увидит последовательность вместо кавычки.Однако, поскольку он распознает его как последовательность, а не как кавычку, опасности нет вообще.

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

tl; dr: Не беспокойтесь, если вы используете действительно старую версию MySQL и / или не делаетеуверен, что ваши данные находятся в заведомо хорошем наборе символов.Для обеспечения максимальной безопасности всегда используйте механизмы экранирования, специфичные для базы данных, и всегда предполагайте, что пользователь пытается вас найти.

...