Плохой Код: Почему это опасно? [дубликат]
8 ответов
В зависимости от различных шагов на пути, которые все должны интерпретировать команду, может существовать некоторая возможность передать %27 (например) и заставить его действовать как одинарная кавычка, проходя незамеченным через вашу замену.
Но даже если бы все такие случаи можно было охватить, и это было бы действительно безопасно для данного отдельного вопроса, недостаток этого способа в том, что он не может быть единообразно реализован. Кто-то другой может прийти и захотеть добавить AND int1 = var1, и заметит, что вы подумали об SQL-инъекции, поэтому он просто изменит код точно так же, как вы
String badInput = rawInput.replace("'","''");
String badInteger = rawInteger.replace("'","''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE" +
"int1 = " + badInteger + " OR col1 = '"+badInput+"'");
... только с целыми числами это уже не кавычки, от которых вы хотите защититься! Здесь, как видно, все может пойти не так. Так что, хотя это проблема, требующая от кого-то плохой реализации, я думаю, что это самая большая проблема дизайна - он покрывает только узкий набор случаев.
Всегда будет лучше иметь возможность просто сказать: "следующее - переменная. что бы она ни содержала, рассматривайте ее как значение, и не пытайтесь использовать ее части как код и выполнять этот код."
.Недавно я познакомил своего брата с оператором prepare. Применив его в своем текущем проекте, он обнаружил, что
- он смог избавиться от беспорядочной экранировки
- он смог избавиться от беспорядочной конкатенации строк
- его код работает быстрее.
Почему бы кому-то не использовать prepare?
Я не специалист по безопасности, но не могу ли char () эффективно обойти ваши меры безопасности?
Например: Получение всего из таблицы записей
SELECT * FROM records WHERE col1 = char(39,97,39)
Пример 2: Запись информации в файлы без одинарных кавычек
SELECT * FROM records WHERE col1 = concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39)) into outfile concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39))
Источник здесь: Шпаргалка по внедрению SQL
Вы можете попробовать:
badInput = "\\'; drop records; --";
в случае, если ваш escape символ будет установлен на '\'.
В MySQL, если параметр NO_BACKSLASH_ESCAPES не установлен, я считаю, что это возможно.
\'); DROP
Или что-то подобное. Ваш код удвоит '. Первая ' будет экранирована обратной косой чертой, а вторая закроет строку, разрешающую SQL-инъекцию.
Я обычно предпочитаю придерживаться заранее подготовленных утверждений на всякий случай.
Возможно. Зависит от того, что этот метод replace на самом деле делает, особенно когда он сталкивается с суррогатными парами юникода или объединяющими знаками - и аналогично тому, как такие пары обрабатываются вашей технологией доступа к базе данных. Если replace работает на уровне символов, то если злоумышленник предоставляет вам допустимый суррогат высокого уровня, за которым следует символ одиночной кавычки, вы можете заменить эту одиночную кавычку парой одиночных кавычек - по сути, добавляя одиночную кавычку после чего-то, что - возможно - позже пройдет через кодировку и будет интерпретировано как недопустимая пара суррогатов, оставляя голый символ одиночной кавычки.
Возможно.
Достаточно ли вы знаете о юникодовых характеристиках метода replace и всех промежуточных библиотек обработки строк между вашим кодом и механизмом выполнения SQL на другом конце соединения с БД?
Вы чувствуете себя счастливчиком?
Используйте параметризованный запрос.
Потому что должен быть только один хакер, который изобретет способ обхода «замен» способом, о котором мы не можем думать сегодня. (Небольшая ошибка в одном из слоев для доступа к базе данных ???)