Как сделать SQL инъекцию на Oracle

Question

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

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

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

Answer 1

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

Answer 2

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

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

2- Другой совет из книги «Код невинного» гласит: не массируйте неверный ввод, чтобы сделать его действительным (экранированием или удалением).Прочитайте соответствующий раздел книги для некоторых очень интересных примеров.Свод правил здесь .

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Для этого SQL

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

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

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

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

Answer 6

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

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

Интересно, как они справляются с датами ...

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