Различия

Показаны различия между двумя версиями страницы.

--- sql_injection [2019/02/13 12:18]
+++ sql_injection [2020/06/13 13:47] (текущий)
@@ Строка 1: / Строка 1: @@
+====== Что такое SQL Injection защита ======
+{{htmlmetatags>
+metatag-description=(SQL инъекция — это один из самых доступных способов взлома сайта, через внедрение в данные произвольного SQL кода.)
+}}
+{{ ::sql-injection-01.jpg?nolink |}}
+Внедрение операторов [[SQL]] (SQL Injection). Эти атаки направлены на Web- серверы, создающие SQL запросы к серверам СУБД на основе данных, вводимых пользователем.
+Большинство серверов поддерживают язык SQL в вариантах, стандартизированных ISO и ANSI. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (PL/pgSQL в PostgreSQL, T-SQL в Microsoft SQL Server, PL SQL в Oracle и т.д.). Методы SQL Injection зависят от типа используемой СУБД. Например, SQL- инъекция на базе данных Oracle осуществляется в основном с помощью использования ключевого слово union, и она намного более трудна, чем на MS SQL- сервере, где можно выполнить множественные запросы, отделяя их символом точки с запятой. В заданной по умолчанию конфигурации MS SQL- сервер выполняется с привилегиями Local System и имеет расширенную процедуру «xp_shell», позволяющую выполнение команд операционной системы.
+Многие Web- приложения используют данные, переданные пользователем, для создания динамических Web- страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать запрос к SQL- серверу, отправляемый приложением. Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д). В результате злоумышленник может получить полный контроль на сервером СУБД и даже его операционной системой. С точки зрения эксплуатации SQL Injection очень походит на LDAP Injection.
+===== Пример SQL инъекция для веб формы =====
+Предположим, аутентификация в Web- приложение осуществляется с помощью Web- формы, обрабатываемой следующим кодом:
+<file>
+SQLQuery = "SELECT Username FROM Users WHERE
+Username = '" & strUsername & "' AND Password = '"
+& strPassword & "'" strAuthCheck =
+GetQueryResult(SQLQuery)
+</file>
+В этом случае разработчики непосредственно использует переданные пользователями значения strUsername и strPassword для создания SQL- запроса. Предположим, злоумышленник передаст следующие значения параметров:
+<file>
+Login: ' OR ''='
+Password: ' OR ''='
+</file>
+В результате серверу будет передан следующий SQL-запрос:<file>
+SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''=''
+</file>
+Вместо сравнения имени пользователя и пароля с записями в таблице Users, данный запрос сравнивает пустую строку с пустой строкой. Естественно, результат подобного запроса всегда будет равен True, и злоумышленник войдет в систему от имени первого пользователя в таблице.
+Обычно выделяют два метода эксплуатации внедрения операторов SQL: обычная атака, и атака вслепую (**Blind SQL Injection**). В первом случае злоумышленник подбирает параметры запроса, используя информацию об ошибках, генерируемую Web- приложением.
+  * Пример: Добавляя оператор union к запросу злоумышленник проверяет доступность базы данных: http://example/article.asp?ID=2+union+all+select+name+from+sysobjects
+Сервер генерирует сообщение, аналогичное следующему:
+<file>
+Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
+[Microsoft][ODBC SQL Server Driver][SQL Server]All
+queries in an SQL statement containing a UNION
+operator must have an equal number of expressions
+in their target lists.
+</file>
+Из этого следует, что оператор union был передан серверу, и теперь злоумышленнику необходимо подобрать используемое в исходном выражении select количество параметров. Внедрение SQL кода вслепую. В этом случае стандартные сообщения об ошибках модифицированы, и сервер возвращает понятную для пользователя информацию о неправильном вводе. Осуществление SQL Injection может быть осуществлено и в этой ситуации, однако обнаружение уязвимости затруднено.
+Наиболее распространенный метод проверки наличия проблемы – добавление выражений, возвращающих истинное и ложное значение.
+Выполнение подобного запроса к серверу: http://example/article.asp?ID=2+and+1=1 должно вернуть ту же страницу, что и запрос: http://example/article.asp?ID=2 поскольку выражение 'and 1=1' всегда истинно.
+Если в запрос добавляется выражение, возвращающее значение «ложь»: http://example/article.asp?ID=2+and+1=0 пользователю будет возвращено сообщение об ошибках или страница не будет сгенерирована. В случае если факт наличие уязвимости подтвержден, эксплуатация ничем не отличается от обычного варианта.
+====== Ссылки SQL Injection ======
+  * WASC: [[http://projects.webappsec.org/w/page/13246963/SQL%20Injection|SQL Injection]]
+  * [[http://www.securiteam.com/securityreviews/5DP0N1P76E.html|SQL Injection Walkthrough]]
+  * [[http://cwe.mitre.org/data/definitions/89.html|"CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')"]]
+  * [[http://capec.mitre.org/data/definitions/66.html|CAPEC: SQL Injection]]
+  * [[http://www.owasp.org/index.php/SQL_injection|OWASP: SQL Injection]]
+  * [[http://www.securitylab.ru/analytics/216396.php|Управление Microsoft SQL Server используя SQL инъекции]]
+  * [[http://www.securitylab.ru/analytics/216332.php|Внедрение SQL кода с завязанными глазами]]
+  * [[http://www.securitylab.ru/analytics/216253.php|SQL инъекция и ORACLE]]

АйТи бубен

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы