Классическая защита внедрения SQL ASP
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
6 ответов
Хранимые процедуры и/или подготовленные операторы:
https://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks
Захватывающее Внедрение SQL и другие Злонамеренные Веб-запросы
С DB Доступа, можно все еще сделать это, но если Вы уже взволнованы по поводу Внедрения SQL, я думаю, что необходимо выйти из Доступа так или иначе.
Вот ссылка на технику в Доступе:
http://www.asp101.com/samples/storedqueries.asp
Примечание, которое, что обычно защищает от инжекции, не сама хранимая процедура, но что то, что это параметризовано и не динамичное. Помните, что даже SPS, которые создают динамический код, может быть уязвим для инжекции, если они используют параметры определенными способами создать динамический код. В целом, я предпочитаю SPS, потому что они формируют интерфейсный слой, который приложения получают к базе данных, таким образом, приложениям даже не позволяют выполнить произвольный код во-первых.
, Кроме того, точка выполнения хранимой процедуры может быть уязвимой, если Вы не используете команду и параметры, например, это все еще уязвимо, потому что это динамично создается и может быть инжекционной целью:
Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;
Помнят, что Ваша база данных должна защитить свой собственный периметр, и если различные логины имеют права на INSERT/UPDATE/DELETE в таблицах, любой код в тех приложениях (или поставивших под угрозу приложениях) может быть потенциальной проблемой. Если логины только имеют права выполнить хранимые процедуры, это формирует трубу, через которую можно намного более легко гарантировать корректное поведение. (Подобный понятиям OO, где объекты ответственны за свои интерфейсы и не представляют все свои внутренние работы.)
"Сильный способ защитить от внедрения SQL для классического приложения asp" состоит в том, чтобы безжалостно проверить весь вход. Период.
одни только Хранимые процедуры и/или различная система баз данных не обязательно равняются хорошей безопасности.
мс недавно производят инструмент SQL Injection Inspection, который ищет непроверенный вход, который используется в запросе. Именно это необходимо искать.
Используя параметрические запросы, необходимо создать объект команды, присвоить ему параметры с именем и значением, если бы Вы делаете так, Вы не должны были бы волноваться ни о чем больше (относящийся к внедрению SQL, конечно;))
http://prepared-statement.blogspot.com/2006/02/asp-prepared-statements.html
И не доверяет хранимым процедурам, они могут, стал вектором атаки также, если Вы не используете подготовленные операторы.
если хранимые процедуры не являются опцией - и даже если они - , проверяют все исходные данные полностью
Переключение на SQL Express по крайней мере является большой опцией. Это сделает вещи намного более безопасными. Даже при том, что использование параметров и Хранимых процедур может помочь значительно. Я также рекомендую проверить исходные данные тщательно, чтобы быть уверенными, что они соответствуют тому, что Вы ожидаете.
Для значений как числа довольно легко извлечь число, чтобы проверить, что это - действительно просто число. Выйдите из всех специальных символов для SQL. Выполнение этого будет препятствовать тому, чтобы предпринятое нападение работало.
Microsoft Source Code Analyzer for SQL Injection Tool является доступно для поиска уязвимостей SQL-инъекций в коде ASP