Как выполнить SQL-инъекцию в Oracle

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

username = username.Replace("'", "");
var sql = "select * from user where username = '" + username + "'";

Это действительно безопасно? Есть ли другой способ вставить одну цитату, возможно, используя escape-символ? Используемая БД - Oracle 10g.

6 ответов

Взгляните на руководство по тестированию здесь: http://www.owasp.org/index.php/Main_Page Это должно дать вам более хитрые тестовые сценарии, возможно, достаточно, чтобы вызвать переоценку стратегии кодирования SQL: -)


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


Несколько советов: 1- Это не обязательно символ, который можно использовать в качестве цитаты. Попробуйте следующее:

select q'#Oracle quote operator#' from dual;

2 Еще один совет из книги "Невинный кодекс" гласит: "Не массируйте недействительный ввод, чтобы сделать его действительным (путем экранирования или удаления). Прочтите соответствующий раздел книги для некоторых очень интересных примеров. Резюме правил здесь.


Нет, это не безопасно. SQL-инъекция не требует успеха для символа с одной кавычкой. Вы можете использовать AND, OR, JOIN и т.д., Чтобы это произошло. Например, предположим, что веб-приложение имеет такой URL-адрес: http://www.example.com/news.php?id=100.

Вы можете сделать много вещей, если параметр ID не был правильно проверен. Например, если его тип не проверен, вы можете просто использовать это: ?id=100 AND INSERT INTO NEWS (id, ...) VALUES (...). То же самое справедливо для JOIN и т.д. Я не буду учить, как исследовать его, потому что не у всех читателей есть хорошие намерения, как кажется. Итак, для тех, кто планирует использовать простой ЗАМЕНИТЬ, имейте в виду, что это НЕ предотвратит атаку.


Что такое клиентский язык? То есть, мы должны быть уверены, что именно то, что тип данных имени пользователя и что делает метод Replace в отношении этого типа данных. Также как фактическая конкатенация работает для этого типа данных. Может быть некоторый перевод набора символов, который переводит некоторый котировочный символ в UTF-8 на "обычную" цитату.

Для очень простого примера, который вы показываете, он должен просто работать, но производительность будет ужасной (согласно комментарию Thilo). Вам нужно будет посмотреть параметры для cursor_sharing

Для этого SQL

select * from user where username = '[blah]'

Пока [blah] не содержит ни одной цитаты, его следует интерпретировать как одно значение CHAR. Если строка была больше 4000 байтов, это вызовет ошибку, и мне было бы интересно посмотреть, как это было обработано. Точно так же пустая строка или одна, состоящая исключительно из одинарных кавычек. Управляющие символы (например, конец файла) также могут дать некоторые проблемы, но это может зависеть от того, могут ли они вводиться в интерфейсе.

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

Таким образом, как общий подход, это плохая безопасность и негативно влияет на производительность. В отдельных случаях он может (возможно?) Не будет подвергать уязвимости. Но вы хотите сделать много испытаний, чтобы убедиться, что это не так.


Итак, никто не может иметь такое имя, как О'Брайан в своей системе?

Проверка одиночной кавычки не поможет, если параметр является числовым - тогда 1; DROP TABLE user;-- вызовет некоторую проблему =)

Интересно, как они обрабатывают даты...

Если механизм выполнения запросов стал таким же умным, как PHP, и ограниченным запросам для выполнения только одного запроса, тогда не должно быть проблем с атаками с инъекциями...

licensed under cc by-sa 3.0 with attribution.