Влияют ли инъекции sql только на страницу с формой?

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

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

Спасибо!

ОТВЕТЫ

Ответ 1

Вам не нужно вводить пользователя, чтобы пострадать от атаки 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'";
}

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

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

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

Ответ 2

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

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

Ответ 3

Фрагменты SQL Injection также могут присутствовать в из QueryString (так называемые "URL-адреса" ), переданные с помощью метода GET.

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 7

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

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

Ответ 8

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

  • Содержимое POST/PUT
  • Параметры GET URL
  • Cookies

На более высоком уровне они отображаются как значения $_REQUEST или Page.Request, переменная сеанса, все зависит от мириады факторов. но, в конечном счете, не просто формы POST. Хотя, возможно, самый старший вектор представляет собой форму POST и GET URL-переменные.

Ответ 9

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

Ответ 10

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

ESCAPE INPUT, FILTER OUTPUT

Ответ 11

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

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

Ответ 12

В качестве общего правила всегда должны использоваться параметризованные запросы.

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

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

Ответ 13

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

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

Возьмем пример Neil N:

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