SQL-инъекция против цитаты ()? - PullRequest
0 голосов
/ 05 марта 2012

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

В настоящее время я работаю над проектом (в безопасной и контролируемой среде внутри ВМ), который включает в себя использование уязвимостейсайт.Одна часть включает использование оператора SQL.Цель состоит в том, чтобы иметь возможность просто ввести имя пользователя и неправильный пароль и все еще иметь возможность войти в систему. Я работал над этим в течение нескольких часов без такой удачи, и я провел немало исследованийпри обнаружении доступных уязвимостей.

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

$query = "SELECT Salt FROM Accounts WHERE Username = '$quoted'";

Где $quoted:

$quoted = $this->db->quote($user);

По сути, это добавляет дополнительную одинарную / двойную кавычку для каждой предоставленной одинарной / двойной кавычки.Несмотря на попытки использования других возможностей (например, ' OR 1=1' и т. Д.), Самое близкое, что я придумал, это:

SELECT Salt FROM Accounts WHERE Username = '\'' OR 1=1 -- '

С переменной $user, изначально равной \' OR 1=1 --.Первые и последние кавычки добавляются автоматически через функцию quote () вместе с дополнительной кавычкой после экранированной одинарной кавычки.Однако это не похоже на правильный синтаксис SQL, возможно потому, что он интерпретирует весь ввод $user как имя пользователя.

После этого есть еще один подготовленный оператор, но он использует хеш md5пароль, соединенный с солью, и я не думаю, что есть действительно какой-либо способ сделать что-нибудь вводимое в операторе, как только md5 вернет хеш.Для любопытства утверждение таково:

$query = "SELECT * FROM Accounts WHERE Username = '$user' AND Password = '$hash';

С $hash = md5($pass.$salt).

Кто-нибудь хочет пролить свет на какие-либо возможности?Может быть, я просто упускаю это из виду, но чувствую, что перепробовал все.

РЕДАКТИРОВАТЬ: Я решил это.Это было связано с обходом другой функции для использования инъекции.В конечном итоге он добавил имя пользователя с кодом инъекции (инъекция второго порядка), а затем произвел бы вход в систему.Процедура входа в систему указала имя пользователя для первого запроса, но второй запрос не сделал;таким образом, пользователь будет автоматически входить в систему.

1 Ответ

2 голосов
/ 05 марта 2012

Обратные косые черты в SQL - раздраженная тема, скорее зависящая от используемой СУБД.

Стандартный SQL не придает им значения.Чтобы избежать кавычки в строке, вы удваиваете кавычку.Метод quote, который вы используете, похоже, следует этому принципу:

  • Вход: \' OR 1=1 --
  • Выход: '\'' OR 1=1 --'

НекоторыеСУБД может фактически определять значение для обратной косой черты.Однако, чтобы еще больше усложнить ситуацию, у вас обычно есть неопределенное количество языков-посредников (PHP, ODBC и т. Д.), И они могут также изменять строки и применять значения к обратным слешам, которых нет в чистом SQL.

Если вынабрав X' OR 1=1 --, (с X вместо обратной косой черты), вы получите ту же самую отображенную строку с обратной косой чертой, замененной на X. Итак, если атака будет работать, вам нужно запутать метод quote()о том, что СУБД собирается делать с обратной косой чертой, но это может привести к ошибке в методе quote().

Вы можете получить больше преимуществ, если вам удастся внедрить escape-последовательность Unicode.Например, U + 0027 (десятичное 39) является одинарной кавычкой.Такая хитрость может заставить вас преодолеть quote(), но, вероятно, этого не произойдет.Идея, лежащая в основе quote() -подобных методов, заключается в том, что у вас не должно быть возможности извлекать текст за ними, что означает нечто иное, чем ожидалось.Не минимальные кодировки UTF-8 для символов могут вызывать проблемы из-за ошибки на сервере, но это не так уж и вероятно.Стандарт Unicode ясно, что недопустимые кодировки UTF-8 не должны приниматься - это вдвойне верно в отношении информации о безопасности.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...