Являются ли атаки SQL-инъекций только угрозой на странице с формой?

Я знаю, что это простой вопрос, но во всем, что я читал, я никогда не видел, чтобы это было написано конкретно.

Если вы делаете запрос на странице, вам нужно беспокоиться об атаках SQL-инъекций? Или это только проблема, когда вы попросите пользователя для входа?

спасибо!

10
security sql sql-injection web-applications

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;

и БАМ, тебя только что поимели.

в дополнение ко всему, что может быть передано через пользователя, querystring, post, cookie, браузер переменная и т. д. Я думаю, что это просто хорошая практика, чтобы всегда использовать эти параметры, даже если у вас есть литералы в коде. Например:

if(SomeCondition)
{
    sql = "Select * from myTable where someCol = 'foo'";
}
else
{
    sql = "Select * from myTable where someCol = 'bar'";
}

это может быть безопасно для инъекций, но ваши СУБД будут кэшировать их как два разных запроса. если вы modiy это:

sql = "Select * from myTable where someCol = @myParam";
if(SomeCondition)
{
   myCommand.Parameters.Add("@myParam").value = "foo";
}
else
{
   myCommand.Parameters.Add("@myParam").value = "bar";
}

вы достигаете того же результата, но СУБД будет кэшировать его только как один запрос, подставляя параметр во время выполнения. Я использую его как эмпирическое правило, чтобы всегда использовать параметризованные запросы, просто чтобы сохранить вещи последовательный, не говоря уже о небольшом улучшении кэша.

15

SQL-инъекция вызвана незапланированными данными. Вы всегда всегда всегда должны санировать данных в базу данных. Не только для SQL-инъекции, но и для того, чтобы ваше приложение просто работало.

например, некоторые системы не будут использовать мое имя, потому что в нем есть символ, и их база данных не дезинфицируется. Я не ввел свое имя, мое имя было взято из другой базы данных. Не имеет значения-данные должны быть очищены.

4

фрагменты SQL-инъекций также могут входить в строке (Он же "аргументы URL") передается с помощью метода GET.

как намекнул Билли О'Нил [предназначена одна цитата; -)], любая часть данных, которая не является неотъемлемой частью программы (или ее очень надежной задней части), должна быть "санирована". The очистка термин, по-видимому, подразумевает сложный процесс, но на самом деле он обычно означает немногим больше, чем:
[может различаться с вашим конкретный SQL server make]

  • удалить (или escape) символы одинарных кавычек, встроенные в строку
  • часы из строк превышали длину базового столбца SQL (в частности, если такая длина легко длинная)

возможной причиной идеи о том, что HTTP-формы будут единственным источником фрагментов SQL-инъекций, является то, что a-valid-рекомендация заключается в том, чтобы обеспечить получение предоставленного пользователем отправленного текста из формы запроса исключительно. Несколько фреймворков веб-приложений предоставляют HTTP-запрос как объект, который по умолчанию предоставляет все пары ключ-значения из строки запроса, из формы или даже из файлов cookie, доступных как из одного хэша. Хотя это может быть практично для приложений, которые иногда получают информацию из формы иногда из строки запроса, это может облегчить работу потенциальных инжекторов, потому что легче создать URL-адрес, чем форму. (Но с правильным инструментом, можно также поддельный запрос POST, а также...)

3

нет, есть несколько других дел. Например, некоторые переменные могут быть переданы в качестве строки запроса на страницу php. "Пользователь" может изменить эту строку, чтобы включить некоторые хитрые сценарии.

http://en.wikipedia.org/wiki/SQL_injection включает в себя большой раздел о типах уязвимостей и как эффективно бороться с ними.

2

подводя итог - любой тип ввода от пользователя, который используется в SQL-запросах, является потенциальной целью SQL-инъекции

2

также рассмотрите возможность предотвращениямежсайтовые скрипты ("XSS").

1

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

очевидные и простые способы - это данные формы и данные querystring, но все, что приходит из браузера, может быть подделано.

1

все, что код принимает в качестве входных данных из HTTP-запроса, может быть вектором SQL-инъекции:

  • опубликовать / поместить контент
  • получить параметры URL
  • печенье

на более высоком уровне они отображаются как $_REQUEST или Page.Значения запроса, переменная сеанса, все зависит от множества факторов. но в конечном счете, это не просто отправьте формы. Хотя, вероятно, наиболее prvalent вектор формы контента и получить URL-адрес переменная.

1

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

0

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

ESCAPE ВХОД, ВЫХОД ФИЛЬТРА

0

поскольку я беспокоюсь, вы никогда не должны доверять этим переменным: $_POST, $_GET, $_REQUEST, $_COOKIE даже $_SERVER может содержать вредоносный код. Поэтому всегда убедитесь, что вставленные данные соответствуют вашим ожиданиям. Например, в качестве дополнительной параноидной меры при проверке адреса электронной почты вы можете зашифровать адрес электронной почты с помощью md5 следующим образом:

"SELECT username FROM users WHERE MD5(email)='" . md5($_POST['email']) . "' AND active=1"
0

Как правило, всегда следует использовать параметризованные запросы.

  1. это предотвращает вредоносный ввод пользователя от выполнения против вашей базы данных (SQL инъекции атак). [Вы также должны выполнить проверку ввода пользователем, чтобы убедиться, что вредоносный код не отображается на странице и что JavaScript может быть запущен на вашем сервере.]
  2. Это позволяет повторно использовать ваши запросы.
  3. вы можете публиковать ваши запросы.
  4. организует ваш вклад и делает его более читаемым. Можно использовать один и тот же параметр в нескольких местах.
  5. Он имеет улучшенную поддержку различных типов данных, таких как даты, строки и тому подобное. Вы не столкнетесь с проблемами со странными символами при использовании параметризованных запросов.

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

0

Я согласен, что параметризация-это лучший подход.

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

взять пример Нила Н:

sql = "Select * From Products Where ID = " + Request.Querystring["ID"];

оберните переменную в функцию, которая удваивает кавычки,и оберните переменную одинарными кавычками.

sql = "Select * From Products Where ID = " 
    + fnSQLSafeParam(Request.Querystring["ID"]);

функция будет чем-то вроде (VBscript пример):

Function fnSQLSafeParam(ByVal strStr)
  If IsNull(strStr) or IsEmpty(strStr) then strStr = ""
  fnSQLSafeParam = "'" & replace(Trim(CStr(strStr)), "'", "''") & "'"
End Function
0