Классическая защита от SQL-инъекций ASP - PullRequest
34 голосов
/ 29 сентября 2008

Какой надежный способ защиты от SQL-инъекций для классического приложения asp?

К вашему сведению, я использую его с БД доступа. (Я не написал приложение)

Ответы [ 8 ]

26 голосов
/ 29 сентября 2008

Хранимые процедуры и / или подготовленные операторы:

https://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks

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

Перехват SQL-инъекций и других вредоносных веб-запросов

С Access DB вы все еще можете это сделать, но если вы уже беспокоитесь о SQL-инъекции, я думаю, вам все равно нужно отключиться от Access.

Вот ссылка на методику в Access:

http://www.asp101.com/samples/storedqueries.asp

Обратите внимание, что обычно защищает от внедрения не сама хранимая процедура, а тот факт, что она параметризована, а не динамична. Помните, что даже SP, которые создают динамический код, могут быть уязвимы для внедрения, если они используют параметры определенным образом для создания динамического кода. В целом, я предпочитаю SP, потому что они формируют интерфейсный слой, который приложения получают в базу данных, поэтому приложениям даже не разрешается выполнять произвольный код.

Кроме того, точка выполнения хранимой процедуры может быть уязвимой, если вы не используете команду и параметры, например это все еще уязвимо, потому что оно динамически построено и может быть целью инъекции:

Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;

Помните, что ваша база данных должна защищать свой собственный периметр, и если различные учетные записи имеют права на INSERT/UPDATE/DELETE в таблицах, любой код в этих приложениях (или скомпрометированных приложениях) может стать потенциальной проблемой. Если учетные записи имеют права только на выполнение хранимых процедур, это формирует воронку, с помощью которой вы можете намного проще обеспечить правильное поведение. (Аналогично концепциям ОО, когда объекты отвечают за свои интерфейсы и не раскрывают всю свою внутреннюю работу.)

7 голосов
/ 09 августа 2011

Вот пара сценариев sqlinject, которые я давно сделал простой и расширенной версией:

function SQLInject(strWords) 
dim badChars, newChars, i
badChars = array("select", "drop", ";", "--", "insert", "delete", "xp_") 
newChars = strWords 
for i = 0 to uBound(badChars) 
newChars = replace(newChars, badChars(i), "") 
next 
newChars = newChars 
newChars= replace(newChars, "'", "''")
newChars= replace(newChars, " ", "")
newChars= replace(newChars, "'", "|")
newChars= replace(newChars, "|", "''")
newChars= replace(newChars, "\""", "|")
newChars= replace(newChars, "|", "''")
SQLInject=newChars
end function 


function SQLInject2(strWords)
dim badChars, newChars, tmpChars, regEx, i
badChars = array( _
"select(.*)(from|with|by){1}", "insert(.*)(into|values){1}", "update(.*)set", "delete(.*)(from|with){1}", _
"drop(.*)(from|aggre|role|assem|key|cert|cont|credential|data|endpoint|event|f ulltext|function|index|login|type|schema|procedure|que|remote|role|route|sign| stat|syno|table|trigger|user|view|xml){1}", _
"alter(.*)(application|assem|key|author|cert|credential|data|endpoint|fulltext |function|index|login|type|schema|procedure|que|remote|role|route|serv|table|u ser|view|xml){1}", _
"xp_", "sp_", "restore\s", "grant\s", "revoke\s", _
"dbcc", "dump", "use\s", "set\s", "truncate\s", "backup\s", _
"load\s", "save\s", "shutdown", "cast(.*)\(", "convert(.*)\(", "execute\s", _
"updatetext", "writetext", "reconfigure", _
"/\*", "\*/", ";", "\-\-", "\[", "\]", "char(.*)\(", "nchar(.*)\(") 
newChars = strWords
for i = 0 to uBound(badChars)
Set regEx = New RegExp
regEx.Pattern = badChars(i)
regEx.IgnoreCase = True
regEx.Global = True
newChars = regEx.Replace(newChars, "")
Set regEx = nothing
next
newChars = replace(newChars, "'", "''")
SqlInject2 = newChars
end function
4 голосов
/ 04 октября 2008

«Сильный способ защиты от SQL-инъекций для классического приложения asp» - безжалостно проверять все вводимые данные. Период.

Хранимые процедуры в одиночку и / или в другой системе баз данных не обязательно обеспечивают хорошую безопасность.

MS недавно выпустила инструмент SQL Injection Inspection, который ищет неподтвержденные данные, которые используются в запросе. Это то, что вы должны искать.

Вот ссылка: Для поиска уязвимостей SQL-инъекций в коде ASP доступен инструмент анализа исходного кода Microsoft для SQL-инъекций

3 голосов
/ 29 сентября 2008

Используя параметризованные запросы, вам нужно создать объект команды, присвоить ему параметры с именем и значением, если вы сделаете это, вам не нужно будет беспокоиться ни о чем другом (ссылаясь на sql инъекцию, конечно;))

http://prepared -statement.blogspot.com / 2006/02 / осина подготовленный-statements.html

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

1 голос
/ 22 февраля 2011

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

Не более, но не менее.

Если вы хороший разработчик, вы можете создать сайт электронной коммерции, используя текстовые файлы в качестве базы данных. Да, он не будет таким же хорошим, как веб-сайт, управляемый Oracle, но он подойдет для малого бизнеса, например, для домашнего изготовления ювелирных изделий на заказ.

И если вы хороший разработчик, вы не будете использовать встроенные операторы SQL на своих страницах ASP. Даже в Access у вас есть возможность создавать и использовать запросы ..

Хранение процедур с проверкой данных вместе с HTML-кодированием - лучший способ предотвратить любые атаки SQL-инъекций.

1 голос
/ 29 сентября 2008

если хранимые процедуры не являются опцией - и даже если они есть - тщательно проверяют все входные данные

0 голосов
/ 21 июля 2009

Инструмент анализа исходного кода Microsoft для SQL-инъекций доступен для поиска уязвимостей SQL-инъекций в ASP-коде

0 голосов
/ 29 сентября 2008

Переключение на SQL Express по крайней мере является отличным вариантом. Это сделает вещи намного более безопасными. Хотя использование параметров и хранимых процедур может сильно помочь. Я также рекомендую тщательно проверить входные данные, чтобы убедиться, что они соответствуют ожидаемым.

Для таких значений, как числа, довольно легко извлечь число, чтобы убедиться, что оно действительно является числом. Сбросьте все специальные символы для SQL. Это предотвратит попытку предпринятой атаки.

...