Действительно ли нападения внедрения SQL являются только угрозой на странице, которая имеет форму?
Обратите внимание, что в случае отражения, Вы добираетесь NoSuchMethodException, в то время как с неотражающим кодом, Вы добираетесь NoSuchMethodError. Я склонен идти, смотря в совсем других местах, когда столкнуто с одним по сравнению с другим.
13 ответов
Вам не нужно вводить данные пользователя, чтобы подвергнуться атаке с использованием SQL-инъекции.
Допустим, у вас есть страница продукта, которая вызывается с использованием такого URL-адреса, как этот:
product.aspx?ID=123
И в вашем коде у вас есть запрос, подобный этому:
string sql = "SELECT * FROM Products WHERE ID = " + Request.Querystring["ID"];
Кто-то может вызвать вашу страницу с этим URL:
product.aspx?ID=123;DROP Table Students;
И бац, вы только что получили.
В дополнение ко ВСЕМУ, что может быть передано через пользователь, строка запроса, сообщение, cookie, переменная браузера и т. д. Я думаю, что это просто хорошая практика - всегда использовать параметры, даже если у вас есть литералы в вашем коде. Например:
if(SomeCondition)
{
sql = "Select * from myTable where someCol = 'foo'";
}
else
{
sql = "Select * from myTable where someCol = 'bar'";
}
это может быть безопасным для инъекций, но ваша СУБД будет кэшировать их как два разных запроса. если вы измените его на следующее:
sql = "Select * from myTable where someCol = @myParam";
if(SomeCondition)
{
myCommand.Parameters.Add("@myParam").value = "foo";
}
else
{
myCommand.Parameters.Add("@myParam").value = "bar";
}
Вы получите тот же результат, но СУБД будет кэшировать его только как один запрос, заменяя параметр во время выполнения. Я использую это как практическое правило: ВСЕГДА использовать параметризованные запросы, просто для обеспечения единообразия, не говоря уже о небольшом улучшении кеширования.
I agree that parameterisation is the best approach.
As an alternative (which might be easier to retro fit into your code, at least initially) doubling the single quotes in a string will prevent SQL Injection.
To take Neil N's example:
sql = "Select * From Products Where ID = " + Request.Querystring["ID"];
wrap the variable in a function that doubles the quotes, and wrap the varible with single quotes too.
sql = "Select * From Products Where ID = "
+ fnSQLSafeParam(Request.Querystring["ID"]);
The function would be something like (VBscript example):
Function fnSQLSafeParam(ByVal strStr)
If IsNull(strStr) or IsEmpty(strStr) then strStr = ""
fnSQLSafeParam = "'" & replace(Trim(CStr(strStr)), "'", "''") & "'"
End Function
По общему правилу всегда следует использовать параметризованные запросы.
- Это предотвращает выполнение злонамеренного пользовательского ввода для вашей базы данных (атаки с использованием SQL-инъекций). [Вам также следует выполнить проверку вводимых пользователем данных, чтобы убедиться, что вредоносный код не отображается на странице и что JavaScript может быть запущен на вашем сервере.]
- Это позволяет вам повторно использовать ваши запросы.
- Вы можете предварительно скомпилировать ваши запросы.
- Он упорядочивает ваш ввод и делает его более читаемым. Возможно, вы захотите использовать один и тот же параметр в нескольких местах.
- Он лучше поддерживает разные типы данных, такие как даты, строки и тому подобное. При использовании параметризованных запросов вы не столкнетесь с проблемами со странными символами.
В моем случае использования я всегда генерирую запросы на основе параметров. У меня есть оболочка, которая всегда будет компилировать их, так что если второй запрос будет выполнен по тому же пути запроса, он будет работать намного быстрее в том же соединении. Это требует значительных усилий для настройки, но стоит увеличения производительности в любой системе среднего и корпоративного уровня.
Насколько я понимаю, вы никогда не должны доверять этим переменным: $ _POST, $ _GET, $ _REQUEST, $ _COOKIE, даже $ _SERVER может содержать вредоносный код. Поэтому ВСЕГДА убедитесь, что вставленные данные соответствуют вашим ожиданиям. Например, в качестве дополнительной параноидальной меры при проверке адреса электронной почты вы можете зашифровать адрес электронной почты с помощью md5 следующим образом:
"SELECT username FROM users WHERE MD5(email)='" . md5($_POST['email']) . "' AND active=1"
Вам нужно беспокоиться об атаках межсайтового скриптинга (XSS) в этом случае, если данные, которые вы показываете на странице, получены из данных, отправленных пользователем.
ESCAPE INPUT, FILTER OUTPUT
Все, что код принимает в качестве входных данных из HTTP-запроса, может быть вектором SQL-инъекции:
- POST / PUT content
- GET URL parameters
- Cookies
At a на более высоком уровне они отображаются как значения $ _REQUEST или Page.Request, переменная сеанса, все зависит от множества факторов. но, в конечном счете, не просто формы POST. Хотя, вероятно, наиболее распространенным вектором является содержимое POST-формы и переменные GET URL.
Когда пользователь может изменять значения параметров запроса, это может стать угрозой.
Также рассмотрите возможность предотвращения межсайтового скриптинга («XSS») .
Нет, есть еще несколько случаев. Например, некоторые переменные могут быть переданы на страницу php в виде строки запроса. «Пользователь» может изменить эту строку, включив в нее некоторые изворотливые сценарии.
http://en.wikipedia.org/wiki/SQL_injection включает большой раздел о типах уязвимостей и способах эффективной борьбы с ними. 1147401]
Подводя итог - любой тип ввода от пользователя, который используется в запросах SQL, является потенциальной целью внедрения sql
Фрагменты SQL-инъекции также могут поступать в из QueryString (также известного как «аргументы URL»), переданного с помощью метода GET.
Как намекнул Билли О ' Нил [подразумевается одинарная кавычка ;-)], любой фрагмент данных, который не является внутренним для программы (или ее очень доверенной серверной части), должен быть «очищен». Термин дезинфекция , кажется, подразумевает сложный процесс, но на самом деле он обычно означает немного больше, чем:
[может отличаться в зависимости от производителя вашего SQL-сервера]
- удаляет (или экранирует) символы одинарных кавычек, встроенные в строку
- смотреть из строк, превышающих длину базового столбца SQL (в частности, если такая длина является большой)
Возможная причина идеи, что HTTP-формы будут единственным источником фрагментов SQL-инъекций, состоит в том, что -valid- рекомендация заключается в том, чтобы гарантировать получение предоставленного пользователем текста исключительно из формы запроса. Несколько фреймворков веб-приложений предоставляют HTTP-запрос как объект, который по умолчанию предоставляет все пары «ключ-значение» из QueryString, из формы или даже из файлов cookie, доступных как из одного хеша. Хотя это может быть практично для приложений, которые иногда получают информацию из формы, а иногда из строки запроса, это может облегчить работу потенциальных инжекторов, потому что создать URL-адрес проще, чем форму. (Но с помощью подходящего инструмента можно также подделать запрос POST ...)
Внедрение SQL вызвано неанитизированными данными. Вы всегда должны всегда дезинфицировать данные, поступающие в базу данных. Не только для SQL-инъекций, но и для того, чтобы ваше приложение просто работало.
Например, некоторые системы не будут использовать мое имя, потому что в нем есть символ ', а их база данных не очищена. Я не ввел свое имя, мое имя взято из другой базы данных. Неважно - данные надо очистить.
SQL-инъекции возможны, если вы используете любые данные, которые поступают из браузера. Это могут быть данные формы, данные строки запроса, значения файлов cookie или даже данные из заголовка запроса.
Очевидными и простыми способами являются данные формы и данные строки запроса, но все, что приходит из браузера, может быть подделано.