Sql injection

Содержание

Введение в SQL

Для успешной инъекции необходимо знать основные операторы языка SQL. Есть набор операторов, которые чаще всего используются для изменения запросов. SELECT – возвращает выборку из базы данных удовлетворяющую описанным условиям. Оператор SELECT имеет следующую структуру: SELECT DISTINCT | DISTINCTROW | ALL] select_expression

, …] Пример использования:

SELECT * FROM users WHERE username = ‘Admin’;

OR – логическое ИЛИ. AND – логическое И. Пример использования:

SELECT * FROM users WHERE username = ‘Admin’ AND (password = ‘Admin’ OR password = ‘qwerty123’);

LIKE – оператор сравнения строк, Для оператора LIKE символ «%» соответствует любой строке. Пример использования:

SELECT * FROM users WHERE login LIKE 'Admin' AND password LIKE '123' OR password LIKE ‘%’;

UNION – объединяет две выборки в одну. Запрос будет выполнен правильно, только если выборки имеют одинаковое количество столбцов. Пример использования:

SELECT * FROM users WHERE login = 'Admin' UNION SELECT FROM books WHERE author = ’Stephen King’ AND title = ’It’	;

GROUP BY – группирует результаты выборки по выбранным столбцам. Пример использования:

SELECT * FROM books GROUP BY author;

ORDER BY – упорядочивает результаты выборки по выбранным столбцам. Пример использования:

SELECT * FROM books ORDER BY title;

GROUP_CONCAT() – представляет выборку в виде строки. CONCAT_WS(sep, param1, param2, …) – объединение подстрок в одну строку c разделителем «sep». Пример использования:

SELECT GROUP_CONCAT(CONCAT_WS(x3a, login, password)) FROM Users;

Обозначения комментариев:

  • #comment
  • — comment
  • /*comment*/
  • /*!int comment*/ – Все заключенное в данный комментарий будет интерпретироваться как SQL запрос если номер данной версии MySQL равен указанному числу int после восклицательного знака или больше.

Реализация атаки

Только ради исследования этой концепции давайте рассмотрим простейший пример атаки:


<code>
mysql> select HEX('index.php
    '> Content-Length: 0
    '> 
    '> HTTP/1.1 200 OK
    '> Content-Type: text/html
    '> Content-Length: 19
    '> 
    '> <html>Shazam</html>
    '> ');
</code>

Так это будет выглядеть в шестнадцатеричном коде:

Далее мы отсылаем отравленный запрос:

<code>
Host: www.mybank.com\r
Pragma: no-cache\r
Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, */*\r
\r
" |nc www.mybank.com 80

HTTP/1.1 302 Found
Date: Mon, 20 Sep 2004 22:58:21 GMT
Server: Apache PHP/4.3.8
X-Powered-By: PHP/4.3.8
Location: index.php
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19

<html>Shazam</html>

Content-Length: 0
Content-Type: text/html
</code>

Для понимания, как это может быть использовано, обратитесь к источнику .

Вот только достаточно ли этого?

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

С в значении за обработку подготовленных выражений отвечает сам PDO. В базу данных передаётся чистый запрос с уже подставленными и корректно экранированными данными (только в не забывайте правильно указывать).

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

Из не очевидных моментов:

  • для сложных запросов дико удобно использовать один и тот же именованный параметр несколько раз в запросе. Какой-нибудь и передать в списке параметров id только один раз. На самом деле зависит от реализации конкретного драйвера, например, в такой запрос при выключенной эмуляции завершится ошибкой , но он же будет корректно исполнен в . С включенной эмуляцией — соответственно можно использовать вне зависимости от СУБД.
  • специфика конкретных СУБД. Какие-то СУБД из тех, что умеет PDO могут не уметь подготовленные выражения. Например, очень популярный (пул коннектов для ) не умеет обрабатывать подготовленные выражения. С эмуляцией выражений можно в коде проекта пользоваться удобствами API с prepare
  • вопрос с тем, что подготовленный запрос разбирается и строит план один раз и затем только выполняется — на самом деле гораздо сложнее. Тот же сохраняет запрос только в рамках соединения. Поэтому в типичном сценарии использования «подготовил, выполнил, закрыл соединение» никаких плюсов реальное препарирование не даёт. А кэширование плана между соединениями — по-моему (сам с этой СУБД не работал), есть в и приносит некоторое количество головной боли, ведь оптимальный план запроса в немалой степени зависит от самих данных.

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

Спрашивается, как без самих данных база угадает оптимальный план? Если ей приедет запрос на status = waiting, оптимально идти по индексу status. Если придёт запрос в статусе done — есть ещё несколько вариантов: при малом лимите имеет смысл пойти по индексу id и просто выкидывать записи с неподходящим статусом.

How to prevent SQL injection

Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

The following code is vulnerable to SQL injection because the user input is concatenated directly into the query:

This code can be easily rewritten in a way that prevents the user input from interfering with the query structure:

Parameterized queries can be used for any situation where untrusted input appears as data within the query, including the clause and values in an or statement. They can’t be used to handle untrusted input in other parts of the query, such as table or column names, or the clause. Application functionality that places untrusted data into those parts of the query will need to take a different approach, such as white-listing permitted input values, or using different logic to deliver the required behavior.

For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant, and must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It is all too easy to make mistakes about the possible origin of data, or for changes in other code to violate assumptions about what data is tainted.

Second-order SQL injection

First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into an SQL query in an unsafe way.

In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into an SQL query in an unsafe way.

Second-order SQL injection often arises in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

Теперь защита.

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

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

С другой стороны к вопросу подходит механизм : у нас есть конечное число запросов на приложении, но использующие разные данные. Поэтому для решили явным образом разделить структуру запроса и данные. Теперь вместо ситуации «привет, выполни вот этот запрос» приложение через специальный протокол говорит СУБД «привет, приготовься выполнить вот такой запрос», а затем: «помнишь вот тот запрос готовили? Теперь выполни его и используй в качестве первого параметра — эти следующие 8 байт, а для второго параметра — следующие 20 байт». Данные для запроса передаются физически отдельно от структуры запроса, поэтому СУБД в принципе не может перепутать данные с запросом, даже при том, что никакого экранирования не происходит. Важный момент — именно поэтому через механизм невозможно изменить структуру запроса, даже банально изменить направление сортировки .

Данные будут переданы как есть без искажений ни самих данных, ни структуры запроса, всё хорошо.

Автоматизация.

Частенько мелькают сообщения на андергрант-форумах, дескать илита не пользуется софтом, а раскручивает все ручками. Возможно где-то и есть уникумы, которые time based скулю раскручивает с секундомером в руках, в качестве браузера используют telnet на 80 порт, а md5 хеши брутфорсят с помощью калькулятора, карандаша и листа A4, но мы к такой илите не относимся (мы вообще к илите не относимся).

Как я уже советовал вам ранее, поставьте Burp Suite. Хотя вы можете использовать любые другие отладочные прокси (Fiddler, Charles и т.д.), это уже скорее дело привычки, но Burp Suite все-таки заточен именно под поиск и эксплуатацию уязвимостей. Берем http-запрос, отправляем в Intruder, сразу смотрим результат. Шик же.

Если говорить об автоматизации sql-инъекций, то тут две софтины впереди планеты всей.

havij — утилита must have для школо-хеккера (а также сценарной детки). Многие из тех кто используют эту программу, не знают, как провести атаку, если уязвимый параметр передается Post’ом или в куках. И это при том, что есть вполне сносная справка на сайте.

Любознательным товарищам будет полезно запустить havij через прокси (тот же burp suite или fiddler), чтобы увидеть и понять, как именно работает havij. Софт заточен под винду, имеет free и pro версию. «Крякнутые» версии практически всегда с чем-то склеены, и не обладают полным функционалом.

Определенно, есть много объективных причин (и все на поверхности), почему софт так популярен в массах. Есть масса аналогов, Pangolin, SQLi-helper и других, которые даже до havij не всегда дотягивают. Те же яйца, вид сбоку.

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

Чтобы подтянуть знания по SQL-инъекциям, можно посмотреть исходники sqlmap (ну или поснифать запросы через веб-прокси).

Алгоритм для автоматизации простой:

  1. Burp Proxy. Сохраняем интересный запрос в файл request.txt (ПКМ -> Copy to file)
  2. Запускаем: sqlmap.py -r request.txt

Можно поставить плагин для burp (https://code.google.com/p/gason/) и отправлять запрос из Burp Proxy в sqlmap двумя кликами.

Это что касается автоматизации тестирования на sql-инъекции на одном сайте. Если вам нужно чекнуть на скули несколько десятков (сотен, тысяч) сайтов, то алгоритм, приведенный выше, вряд ли подойдет (если только вы не Дункан Маклауд).

О глобальной автоматизации (и создании убер-комбайна по взлому сайтов) мы поговорим в следующих статьях.

Способы обнаружения

  • Тестирование функций (black/white-box)
  • Фаззинг (fuzzing)
  • Cтатический/динамический/ручной анализ исходного кода

Методы для работы с БД

Язык Ключевое слово
VB.NET Sql SqlClient, OracleClient, Sql Data Adapter
C# Sql, SqlClient, OracleClient, Sql Data Adapter
РНР mysql_connect
Perl DBI, Oracle, SQL
Ruby ActiveRecord
Python (MySQL) MySQLdb
Python (Oracle) DCOracle2
Python (SQL Server) pymssql
Java (cJDBC) java.sql, sql
Active Server Pages ADODB
C++ (Microsoft Foundation Classes) СDatabase
C/C++ (MySQL) #include <mysql++.h> #include <mysql.h>
C/C++ (ODBC) #include <sql.h>
C/C++ (ADO) ADODB, #import «msadol5.dll»
SQL exec, execute, sp_executesql
ColdFusion cfquery

Дополнительная информация

Конструкция Комментирование остатка строки Получение версии Конкатенация строк
MySQL — /* version() concat (string1, string2)
MS SQL @@version string1 + string2
Oracle — /* select banner from v$version string1 || string2 concat (string1, string2)
MS Access Внедрение в запрос NULL‑байта: %00
PostgreSQL version() string1 || string2
Sybase @@version string1 + string2
IBM DB2 select versionnumber from sysibm.sysversions string1 || string2 string1 concat string2
Ingres dbmsinfo(‘_version’) string1 || string2

Суть атаки на основе SQL-инъекции

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

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

select * from Users where userid=’uname’ AND password= ‘pword’;

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

Рисунок 1. Иллюстрация простой атаки с использованием SQL-инъекции

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

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

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

<form action=’reg.php’ method=’post’>

<input type=’text’ name=’login’ placeholder=’Логин’ required><br>

<input type=’password’ name=’password’ placeholder=’Пароль’ required><br>

<input type=’submit’ value=’Зарегистрироваться’>


</form>

Они отправляются на сервер и вставляются в запрос такого вида:

$query = «INSERT INTO userlist („.$keys.“) VALUES („.$values.“)»;

В переменной $keys содержатся ключи из супермассива $_POST, а в $values — значения:

$keys = «»;

$values = «»;

$first = 1;

foreach($_POST as $key => $value) {

if($first == 0) { //Добавляем запятую перед каждым пунктом, кроме первого

       $keys .= «,»;

       $values .= «,»;

}

$keys .= $key;

$values .= «‘».$value.»‘»;

$first = 0;

}

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

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

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

Возьмем некий псевдо код

if( intval($_GET) )
    mysql_query('select * from news where id="'.$_GET.'"';

Здесь есть проверка на то, что  intval должен вернуть целое число, и если в id лежит не число, то условие не сработает и запрос не будет исполнен.

И это верно работает, если сделать такой запрос

http://sitename.ru/index.php?id=new

то условие не выполнится: intval(‘new’) вернет 0.

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

http://sitename.ru/index.php?id=39new

Удивительно, но условие сработает. intval в этом плане, очень крутая функция. В отличии к примеру от JavaScript’овского parseInt, который вернет в таком случае NaN. Она спокойно переварит такие входные данные, и возьмет из них только число (заметим, что intval(‘new39’) вернет 0.)

Отсюда вытекает дыра в безопасности. Через нее, можно вставить любой SQL запрос. Вплоть до delete from news

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

Говорят, таким атакам подвержены даже смартфоны и подобные девайсы. Большинство из них, в своей операционной системе данные хранят в SQLLite, а следовательно и сопутствующие неприятности связанные с SQL инъекциями возникнуть могут. Вероятно какой-нибудь samsung galaxy s iv этому не подвержен, но не стоит забывать, что старые устройства никуда не уходят, и подвержены риску.

Почему нельзя хранить пароли в открытом виде

Главная причина — минимизация ущерба в случае утечки базы данных.

Но если в его руках окажутся логины и пароли, он может попытаться использовать эти данные для входа в почтовые сервисы (Gmail, Яндекс.Почта, Mail.ru и т.д.), социальные сети, мессенджеры, клиент-банки и т.д.

В тот же личный кабинет Пятёрочки, чтобы перевыпустить карту и потратить чужие бонусы.

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

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

  • Разработчик — не робот, он не может не совершать ошибок.
  • Взлом может произойти со стороны хостинг-провайдера, работу которого не всегда возможно контролировать.
  • Некорректная настройка сервера может привести к возможному доступу других пользователей хостинга к вашему сайту (актуально для виртуальных хостингов).
  • Бывший коллега по работе может слить базу данных конкурентам. Может в качестве мести, а может просто ради денег.

Короче, пароли в открытом виде хранить нельзя.

SQL injection examples

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:

  • , where you can modify an SQL query to return additional results.
  • , where you can change a query to interfere with the application’s logic.
  • UNION attacks, where you can retrieve data from different database tables.
  • Examining the database, where you can extract information about the version and structure of the database.
  • Blind SQL injection, where the results of a query you control are not returned in the application’s responses.

Hacking Activity: SQL Inject a Web Application

To get round that, we can instead exploit the password field. The diagram below shows the steps that you must follow

Let’s suppose an attacker provides the following input

  • Step 1: Enter This email address is being protected from spambots. You need JavaScript enabled to view it. as the email address
  • Step 2: Enter xxx’) OR 1 = 1 — ]

  • Click on Submit button
  • You will be directed to the dashboard

The generated SQL statement will be as follows

The diagram below illustrates the statement has been generated.

HERE,

  • The statement intelligently assumes md5 encryption is used
  • Completes the single quote and closing bracket
  • Appends a condition to the statement that will always be true

In general, a successful SQL Injection attack attempts a number of different techniques such as the ones demonstrated above to carry out a successful attack.

SQL Injection Based on «»=»» is Always True

Here is an example of a user login on a web site:

Username:

Password:

Example

uName = getRequestString(«username»);uPass = getRequestString(«userpassword»);sql = ‘SELECT * FROM Users WHERE Name =»‘ + uName + ‘» AND Pass =»‘ + uPass + ‘»‘

Result

SELECT * FROM Users WHERE Name =»John Doe» AND Pass =»myPass»

A hacker might get access to user names and passwords in a database by simply inserting » OR «»=» into the user name or password text box:

User Name:

Password:

The code at the server will create a valid SQL statement like this:

Result

SELECT * FROM Users WHERE Name =»» or «»=»» AND Pass =»» or «»=»»

The SQL above is valid and will return all rows from the «Users» table, since OR «»=»» is always TRUE.

Use SQL Parameters for Protection

To protect a web site from SQL injection, you can use SQL parameters.

SQL parameters are values that are added to an SQL query at execution time, in a controlled manner.

ASP.NET Razor Example

txtUserId = getRequestString(«UserId»);txtSQL = «SELECT * FROM Users WHERE UserId = @0»;db.Execute(txtSQL,txtUserId);

Note that parameters are represented in the SQL statement by a @ marker.

The SQL engine checks each parameter to ensure that it is correct for its column and are treated literally, and not as part of the SQL to be executed.

Another Example

txtNam = getRequestString(«CustomerName»);txtAdd = getRequestString(«Address»);txtCit = getRequestString(«City»); txtSQL = «INSERT INTO Customers (CustomerName,Address,City) Values(@0,@1,@2)»;db.Execute(txtSQL,txtNam,txtAdd,txtCit);

Examples

The following examples shows how to build parameterized queries in some common web languages.

SELECT STATEMENT IN ASP.NET:

txtUserId = getRequestString(«UserId»); sql = «SELECT * FROM Customers WHERE CustomerId = @0»;command = new SqlCommand(sql);command.Parameters.AddWithValue(«@0»,txtUserID); command.ExecuteReader();

INSERT INTO STATEMENT IN ASP.NET:

txtNam = getRequestString(«CustomerName»);txtAdd = getRequestString(«Address»);txtCit = getRequestString(«City»); txtSQL = «INSERT INTO Customers (CustomerName,Address,City) Values(@0,@1,@2)»;command = new SqlCommand(txtSQL); command.Parameters.AddWithValue(«@0»,txtNam); command.Parameters.AddWithValue(«@1»,txtAdd); command.Parameters.AddWithValue(«@2»,txtCit);command.ExecuteNonQuery();


INSERT INTO STATEMENT IN PHP:

$stmt = $dbh->prepare(«INSERT INTO Customers (CustomerName,Address,City) VALUES (:nam, :add, :cit)»);$stmt->bindParam(‘:nam’, $txtNam); $stmt->bindParam(‘:add’, $txtAdd);$stmt->bindParam(‘:cit’, $txtCit); $stmt->execute();

Дополнительная защита сайта от взлома

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

1. Запретите прямой доступ к служебным файлам

Все файлы на сайте можно открыть или скачать, если знать их адрес. Например, можно попытаться скачать файл header.php, чтобы найти там уязвимости (если скачивание будет удачным).

Поэтому лучше все подключаемые файлы переместить в отдельную директорию и запретить к ней прямой доступ. Например, можно создать папку includes и поместить туда:

  • отдельные блоки сайта;
  • библиотеки пользовательских функций;
  • файл подключения к базе данных;
  • обработчики форм и так далее.

Для этого создайте в этой папке файл .htaccess и добавьте туда такую строчку:

deny from all

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

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

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

3. Проверяйте копипасту

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

В идеале лучше вручную переписывать код — так вы точно заметите все подозрительные команды.

4. Отключите вывод ошибок

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

Отключить вывод можно в файле .htaccess, добавив туда следующие строки:

php_flag display_errors off

php_value error_reporting 0

Кроме того, уберите вывод ошибок, который вы прописали в самом коде.

5. Ограничьте права пользователя базы данных

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

Пока ни одна галочка не отмечена — поставьте ее на пункт «Данные». Так можно будет оперировать существующими данными, но нельзя будет создать новую таблицу или удалить старую. Так вы защититесь в том числе и от атаки с помощью команды DROP, которая может удалить все статьи или комментарии с сайта.

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

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

6. Установите последнюю версию языка

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

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

7. Используйте сложный пароль

Банально, но простой пароль можно подобрать за несколько секунд. Особенно если он содержит персональные данные:

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

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

My approach:

  • If you expect input to be integer make sure it’s really integer. In a variable-type language like PHP it is this very important. You can use for example this very simple but powerful solution:

  • If you expect anything else from integer hex it. If you hex it, you will perfectly escape all input. In C/C++ there’s a function called , in PHP you can use .

    Don’t worry about that the escaped string will have a 2x size of its original length because even if you use , PHP has to allocate same capacity , which is the same.

  • This hex method is often used when you transfer binary data, but I see no reason why not use it on all data to prevent SQL injection attacks. Note that you have to prepend data with or use the MySQL function instead.

So, for example, the query:

Will become:

or

Hex is the perfect escape. No way to inject.

Заключение

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

Похожие темы

  • Оригинал статьи: Fight against SQL injection attacks.
  • Посетите раздел SQL Injection Hall of Shame на сайте Code Curmudgeon.
  • Материалы developerWorks по вопросам безопасности в Твиттере.
  • Дополнительные сведения и загрузка продукта Security AppScan Standard.
  • Загрузка продукта Microsoft .NET Framework version 4.5.

С этим читают