Если из SQL-запроса я удаляю все символы, есть ли другой способ сделать атаку SQL-инъекций в базе данных?Есть ли способ ввести SQL, даже если символ будет удален?
Как это сделать? Может ли кто-нибудь дать мне примеры?
Да, есть. Отрывок из Wikipedia
"SELECT * FROM data WHERE id = " + a_variable + ";"
Это ясно из этого утверждения, что автор предполагаемого a_variable быть рядом соотнесения в поле «ID». Однако, если это фактически строка, конечный пользователь может манипулировать оператором по своему усмотрению, тем самым минуя необходимость в escape-символах. Например, установка a_variable в
1;DROP TABLE users
будет падать (удалить) "пользователи" таблицу из базы данных, поскольку SQL будет оказана следующим образом:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;
SQL инъекция не простая атака для борьбы. Я бы сделал очень тщательное исследование, если бы был вами.
Да, в зависимости от заявления, которое вы используете. Вам лучше защитить себя либо с помощью хранимых процедур, либо, по крайней мере, с параметризованными запросами.
См. WikiPedia для образцов профилактики.
Если бы я мог изменить вас на 1 квадриллион раз, я бы это сделал. Если вы не пишете драйвер/библиотеку, которая предоставляет параметризацию, я не могу придумать, почему _any_ причина даже рассматривать что-либо еще для защиты от SQL-инъекции. – 2008-09-16 12:42:25
. , , эм о 50000000 другие способы
может быть Somthing как 5; drop table employees; --
в результате SQL может быть что-то вроде: select * from somewhere where number = 5; drop table employees; -- and sadfsf
(-- начинает комментарий)
Это зависит от того, как вы собрали запрос, но по существу да.
Например, в Java, если вы должны были сделать это (намеренно вопиющий пример):
String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");
то есть хороший шанс, что вы открываете себя для нападения инъекции.
В Java есть некоторые полезные инструменты для защиты от них, такие как PreparedStatements (где вы передаете строку типа «SELECT name_» из Customer WHERE ID =? », А слой JDBC обрабатывает экраны при замене« токенов »для вас), но некоторые другие языки не так полезны для этого.
Да, абсолютно: в зависимости от вашего диалекта SQL и т. Д. Существует множество способов достижения инъекции, которые не используют апостроф.
Единственная надежная защита от атак SQL-инъекций - это поддержка параметризованной поддержки операторов SQL, предлагаемая вашим интерфейсом базы данных.
Вещь - возможно подлинный вход апострофа, и вам нужно избегать их, удваивая их, когда вы используете встроенный SQL в свой код. То, что вы ищете шаблон регулярного выражения, как:
\;.*--\
Полупроницаемой двоеточие используется для преждевременного завершения подлинного заявления, некоторые вводили SQL с последующим двойным дефисом закомментировать косую SQL из исходного подлинного заявления. Дефис может быть опущен в атаке.
Поэтому ответ: Нет, просто удаление апострофов не гарантирует вам безопасность от SQL Injection.
Скорее, пытаясь выяснить, какие символы отфильтровываются, вместо этого я буду придерживаться параметризованных запросов и полностью устранить проблему.
Да, это окончательно возможно.
Если у вас есть форма, где вы ожидаете целое, чтобы сделать ваш следующий ЗЕЬЕСТ, то вы можете ввести что-нибудь подобное:
SELECT * FROM thingy WHERE attributeID =
users; (плохой, плохой, плохой)Следующий сайт подробнее дальнейшая классическая технология инъекции SQL: SQL Injection cheat sheet.
Использование параметризованных запросов или хранимых процедур не лучше. Это только предварительно сделанные запросы с использованием переданных параметров, которые также могут быть источником инъекций. Он также описан на этой странице: Attacking Stored Procedures in SQL.
Теперь, если вы подавите простую цитату, вы предотвратите только определенный набор атак. Но не все из них.
Как всегда, не доверяйте данным, поступающим извне. Фильтр их на этих 3-х уровнях:
Удачи и не забудьте проверить WikiPedia ответы на вопросы.
/Вея
Просто обратите внимание, что домен, на котором размещена статья «Атакующие хранимые процедуры в SQL», теперь кажется несуществующей. – Funka 2010-05-20 04:06:56
Also- даже если вы просто посмотрите на апостроф, вы не хотите, чтобы удалить его. Вы хотите, чтобы побег это. Вы делаете это, заменяя каждый апостроф двумя апострофами.
Но параметризованные запросы/хранимые процедуры намного лучше.
Параметрированный встроенный SQL или параметризованные хранимые процедуры - лучший способ защитить себя.Как указывали другие, просто лишать/избегать символа одиночной кавычки недостаточно.
Вы заметите, что я конкретно говорю о «параметризованных» хранимых процедурах. Просто использование хранимой процедуры недостаточно, если вы вернетесь к объединению переданных параметров процедуры вместе. Другими словами, упаковка одной и той же уязвимой инструкции SQL в хранимой процедуре не делает ее более безопасной. Вам нужно использовать параметры в своей хранимой процедуре так же, как и с встроенным SQL.
Я могу только повторить то, что говорили другие. Параметризованный SQL - это путь. Конечно, это немного боль в кодировке, но если вы это сделали один раз, то нетрудно вырезать и вставить этот код и внести необходимые изменения. У нас есть много приложений .Net, которые позволяют посетителям веб-сайта указывать целый ряд критериев поиска, а код строит инструкцию SQL Select на лету - но все, что могло быть введено пользователем, переходит в параметр.
Предлагаю вам передать переменные в качестве параметров, а не строить собственный SQL. В противном случае всегда будет способ сделать SQL-инъекцию, в манерах, которые мы в настоящее время не знаем.
Код, который вы создаете, а затем что-то вроде:
' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));
Если у вас есть имя, как у меня с 'в нем. Очень раздражает то, что все «символы» удаляются или помечены как недействительные.
Вы также можете посмотреть на это Stackoverflow question about SQL Injections.
Это определенно лучшая практика – 2008-09-23 03:25:21
Когда вы ожидаете числовой параметр, вы всегда должны проверять ввод, чтобы убедиться, что он числовой. Помимо защиты от инъекций, шаг проверки сделает приложение более удобным для пользователя.
Если вы когда-либо получали id = «привет», когда вы ожидали id = 1044, всегда лучше возвращать пользователю полезную ошибку, а не позволять базе данных возвращать ошибку.
Поскольку это относительно старый вопрос, я не буду писать полный и всеобъемлющий ответ, так как большинство аспектов этого ответа были упомянуты здесь одним плакатом.
Однако я считаю нужным выявить еще одну проблему, которая не была затронута кем-либо здесь - SQL Smuggling. В некоторых ситуациях можно «перетащить» символ кавычки в ваш запрос , даже если вы попытались удалить его. Фактически это возможно, даже если вы использовали правильные команды, параметры, хранимые процедуры и т. Д.
Ознакомьтесь с полным исследовательским документом по адресу http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (раскрытие информации, я был основным исследователем по этому вопросу) или просто Google «Контрабанда SQL» ».
Следует отметить, что это происходит только в том случае, если ваша система позволяет выполнять сразу несколько SQL-запросов. В PHP mysql_query нет. – DisgruntledGoat 2009-07-22 15:05:49