Плохой код, почему это опасно? [дубликат]
Возможные Дубликаты:
могу ли я защитить от SQL-инъекции, избегая одинарной кавычки и окружающего пользовательского ввода с одинарными кавычками?
String badInput = rawInput.replace("'","''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE col1 = '"+badInput+"'";
есть ли способ сделать "Бобби Таблиц " - как атака на этот код?
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+"'");
...только с целыми числами это больше не кавычки, от которых вы хотите защитить себя! Здесь ясно видно, что все может пойти не так. Поэтому, хотя это проблема, которая требует, чтобы кто - то ее плохо реализовал, я думаю, что это самая большая проблема дизайна-она охватывает только узкий набор случаев.
всегда будет лучше иметь возможность просто сказать: "следующее переменная. что бы оно ни содержало, рассматривайте его как значение и не пытайтесь использовать его части как код и выполнять этот код."
в MySQL, если NO_BACKSLASH_ESCAPES опция не установлена Я считаю, что это можно сделать.
\'); DROP
или что-то подобное. Ваш код удвоит '. Первый ' будет экранирован обратной косой чертой, а вторая закроет строку, разрешающую SQL-инъекцию.
Я обычно предпочитаю придерживаться подготовленных заявлений, чтобы быть в безопасности.
недавно я познакомил своего брата с заявлением о подготовке. Реализовав его на своем текущем проекте, он нашел
- Он мог бы избавиться от всех грязных побегов
- он мог бы избавиться от всей грязной конкатенации строк
- его код выполнялся быстрее.
зачем кому-то не использовать prepare?
вы можете попробовать:
badInput = "\'; drop records; --";
в случае, если ваш escape-символ будет установлен в '\'.
может быть. Зависит от того, что это replace метод на самом деле делает, особенно когда он сталкивается с суррогатными парами unicode или комбинированием меток - и аналогично тому, как такие пары обрабатываются вашей технологией доступа к базе данных. Если replace работает на уровне символов, затем, если злоумышленник предоставляет вам действительный высокий суррогат, за которым следует символ одинарной кавычки, вы можете заменить эту одинарную кавычку парой одинарных кавычек, добавив одну кавычку после чего-то, что может- позже проходят через кодировку и интерпретируются как недопустимая суррогатная пара, оставляя голый символ одинарной кавычки.
может быть.
знаете ли вы достаточно о характеристиках unicode этого метода замены и каждой промежуточной библиотеки обработки строк между вашим кодом и механизмом выполнения SQL на другом конце соединения с БД?
вы чувствуете себя счастливым?
использовать параметризованный запрос.
Я не эксперт по безопасности, но не 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 инъекции
потому что должен быть только один хакер, который изобретает способ обойти замены на пути, о котором мы не можем думать сегодня. (А небольшая ошибка в одном из слоев для доступа к базе данных???)