Чек-лист устранения sql-инъекций

SQL-инъекция

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

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

Принцип атаки

Простой способ найти точки инъекции

1. Ищите веб-страницы с URL-адресами со строками запроса (например, запрашивайте страницы с «id =» в URL-адресе).

2. Отправьте запрос на этот веб-сайт и измените оператор id = на дополнительную одинарную кавычку (например: id = 123 ’).

3. Посмотрите на возвращаемый контент, найдите такие ключевые слова, как «sql», «statement» и т. Д. (Это также означает, что были возвращены определенные сообщения об ошибках, что само по себе плохо)

4. Указывает ли сообщение об ошибке, что параметры, отправленные на сервер SQL, неправильно закодированы? Если да, это означает, что веб-сайт может быть атакован с помощью SQL-инъекции.

Как предотвратить атаки с использованием SQL-инъекций

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

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

Так называемый параметризованный запрос (Parameterized Query или Parameterized Statement) относится к использованию параметров (Parameter) для предоставления значений при проектировании соединения с базой данных и доступе к данным, где значения или данные должны быть заполнены.

Пример: SELECT * FROM myTable WHERE myID = @myID

INSERT INTO myTable (c1, c2, c3, c4) VALUES (@ c1, @ c2, @ c3, @ c4) или INSERT INTO myTable (c1, c2, c3, c4) VALUES (?,?,?,?)

Укажите заполнитель с помощью (?). Разумеется, при добавлении параметров вы должны добавлять их в порядке (c1, c2, c3, c4), иначе возникнет ошибка.

Заранее подготовленные инструкции

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

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

Когда такая команда поступает на SQL-сервер, он ее анализирует, компилирует и оптимизирует. В завершении сервер эту программу выполняет и возвращает ее результат.

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

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

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

<?php  $stmt = $mysqli->prepare(“SELECT Id FROM Users WHERE Username=? AND Password=?”);  $stmt->bind_param(“ss”, $username, $password);  $stmt->execute();?>

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

Здесь также нужно запомнить, что подготовленные инструкции не обязательно на 100% обезопасят сайт от внедрений SQL, так как использовать их нужно продуманно. Например, мы конкатенируем пользовательский ввод с функцией , а затем сразу ее выполняем:

<?php  $stmt = $mysqli->prepare(“SELECT Id FROM Users WHERE Username=’$username’ AND Password=’$password’”);  $stmt->execute();?>

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

Как предотвратить атаку SQL-инъекции

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

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

• Использование подготовленных операторов (с параметризованными запросами). Этот метод очистки входных данных базы данных включает в себя принуждение разработчиков сначала определить весь SQL-код, а затем передать только определенные параметры в SQL-запрос. Вводимые данные явно имеют ограниченную область, которую он не может расширить за ее пределы. Это позволяет базе данных проводить различие между вводимыми данными и выполняемым кодом независимо от типа данных, указанных в поле ввода. Некоторые библиотеки объектно-реляционного сопоставления (ORM) обычно используются для этой цели, так как некоторые версии будут автоматически очищать входные данные базы данных. Защитить все введеные пользовательские данные. При написании SQL определенные символы или слова имеют особое значение. Например, символ «*» означает «все», а слова «или» являются условиями. Чтобы обойти пользователей, которые вводят эти символы случайно или злонамеренно в запрос API к базе данных, вводимые пользователем данные могут быть экранированы. Экранирование символа — это способ сказать базе данных не анализировать его как команду или условие, а вместо этого рассматривать его как литеральный ввод.
• Использование хранимых процедур. Хотя сама по себе стратегия безопасности не является надежной, хранимые процедуры могут помочь ограничить риск, связанный с внедрением SQL. При правильном ограничении разрешений учетной записи базы данных, выполняющей запросы SQL, даже ненадежный код приложения, уязвимый для внедрения SQL, не будет иметь разрешений, необходимых для управления несвязанными таблицами базы данных. Хранимые процедуры могут также проверять тип входных параметров, предотвращая ввод данных, которые нарушают тип поля, предназначенного для получения. В случаях, когда статических запросов недостаточно, хранимых процедур обычно следует избегать.

Соблюдение минимальных прав

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

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

Причины SQL-инъекции

• Отсутствие фильтрации
• Неправильная обработка типов
• Уязвимости в базе данных сервера
• Условные ошибки

1. Отсутствие фильтрации

SQL-запрос

<?php

$sqlStatement = "SELECT * FROM users WHERE username = '" + $username + "' AND email = '" + $email + "' ";

?>

[email protected]’; DROP TABLE users; SELECT * FROM customers WHERE name LIKE ‘%

<?php

$sqlStatement = "SELECT * FROM users WHERE username = 'james' AND email = '[email protected]'; DROP TABLE users; SELECT * FROM customers WHERE name LIKE '%'";

?>

аутентификацию

20; DROP TABLE users

<?php

$sqlStatement = "SELECT * FROM customers WHERE age = 20; DROP TABLE users;";

?>

$ageValue

Защита от SQL-инъекций

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

1) Числа

Функция is_numeric(n) используется для проверки переменной на числовое значение, которая вернёт true, если параметр n — число, а в противном случае — false. Также переопределить тип возможно вручную.

Пример:

2) Строки

Компрометации через SQL-конструкции происходят и по причине нахождения в строках небезопасных кавычек и других специальных символов. Для предотвращения такой угрозы необходимо использовать функцию addslashes($str), которая возвращает строку $str с добавленным обратным слешем (\) перед каждым специальным символом. Данный процесс называется экранированием. Для этого в PHP используют функцию mysqli_real_escape_string($str).

3) Параметризированные запросы (PDO)

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

При использовании PDO сначала передается запрос в БД, а потом в него подставляются данные из переменных. Таким образом, за имя пользователя будет приниматься вся строка admin’ or ‘1’=’1, введенная им, что не позволит хакеру проэксплуатировать SQL-инъекцию.

Пример кода:

4) Хранимые процедуры

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

5) Использование WAF

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

В одной из статей мы рассматривали способы тестирования Nemesida WAF различными инструментами.

Я твой WAF payload шатал
Пару недель назад команда Vulners опубликовала сравнение нескольких популярных WAF. Поймав себя на м…
habr.com

6) Принцип наименьших привилегий

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

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

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

• создавайте «белые» списки;

• регулярно устанавливайте обновления;

• удаляйте неиспользуемый функционал;

• задавайте конкретные значения названиям таблиц, полей и базам;

• периодически проводите анализ защищенности веб-приложений вручную и с помощью инструментов автоматизации (например, Wapiti)

• используйте средства защиты веб-приложений (WAF).

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

Коротко о DDoS

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

Основные типы DDoS-атак — Layer 3 и Layer 7. Они названы так в соответствии с уровнями сетевой модели OSI, на которых выполняются. 

Layer 3 DDoS нацелен на сетевое оборудование и соединения. В ходе атаки создаётся огромный паразитный трафик, например, с помощью SYN-пакетов (syn-flood). Этот трафик забивает канал связи и блокирует прохождение легитимных пакетов. В настоящее время большинство крупных хостинг-провайдеров и дата-центров сегодня хорошо защищены от атак Layer 3 , поэтому в этом посте мы сосредоточимся на другой разновидности атак, противостоять которой несколько сложнее. 

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

Существует множество способов и инструментов для проведения такого рода атак и множество способов защиты. Сегодня мы сосредоточимся на защите от распределённых атак на отказ в обслуживании на уровне приложений (уровень 7), сокращенно L7 DDoS.

Инъекция правил валидатора

Давайте посмотрим на следующий уязвимый код:

Вы заметили уязвимость в строке ? Так держать! (нет)

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

1. Сделать правило проверки необязательным

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

2. DDOS сервер путем создания злого правила проверки REGEX

Другой вектор атаки может заключаться в создании злой и уязвимой проверки Regex для ReDoS атаки и DDOS приложения. Например, следующий запрос потребляет много процессорного времени, и если несколько запросов отправляются одновременно, это может вызвать большой скачок нагрузки на ЦП сервера:

3. SQL-инъекция

Простейшей SQL-инъекцией было бы просто добавить дополнительное правило проверки передаваемое в запрос. Например:

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

Советы по профилактике:

1. Лучшая профилактика — не использовать данные, предоставленные пользователем, для создания правила валидации;

2. Если вам нужно создать правило проверки на основе предоставленных данных (ID в нашем примере), обязательно приведите или подтвердите предоставленное значение, прежде чем помещать его в правило проверки.

SQL Справочник

SQL Ключевые слова
ADD
ADD CONSTRAINT
ALTER
ALTER COLUMN
ALTER TABLE
ALL
AND
ANY
AS
ASC
BACKUP DATABASE
BETWEEN
CASE
CHECK
COLUMN
CONSTRAINT
CREATE
CREATE DATABASE
CREATE INDEX
CREATE OR REPLACE VIEW
CREATE TABLE
CREATE PROCEDURE
CREATE UNIQUE INDEX
CREATE VIEW
DATABASE
DEFAULT
DELETE
DESC
DISTINCT
DROP
DROP COLUMN
DROP CONSTRAINT
DROP DATABASE
DROP DEFAULT
DROP INDEX
DROP TABLE
DROP VIEW
EXEC
EXISTS
FOREIGN KEY
FROM
FULL OUTER JOIN
GROUP BY
HAVING
IN
INDEX
INNER JOIN
INSERT INTO
INSERT INTO SELECT
IS NULL
IS NOT NULL
JOIN
LEFT JOIN
LIKE
LIMIT
NOT
NOT NULL
OR
ORDER BY
OUTER JOIN
PRIMARY KEY
PROCEDURE
RIGHT JOIN
ROWNUM
SELECT
SELECT DISTINCT
SELECT INTO
SELECT TOP
SET
TABLE
TOP
TRUNCATE TABLE
UNION
UNION ALL
UNIQUE
UPDATE
VALUES
VIEW
WHERE

MySQL Функции
Функции строк
ASCII
CHAR_LENGTH
CHARACTER_LENGTH
CONCAT
CONCAT_WS
FIELD
FIND_IN_SET
FORMAT
INSERT
INSTR
LCASE
LEFT
LENGTH
LOCATE
LOWER
LPAD
LTRIM
MID
POSITION
REPEAT
REPLACE
REVERSE
RIGHT
RPAD
RTRIM
SPACE
STRCMP
SUBSTR
SUBSTRING
SUBSTRING_INDEX
TRIM
UCASE
UPPER
Функции чисел
ABS
ACOS
ASIN
ATAN
ATAN2
AVG
CEIL
CEILING
COS
COT
COUNT
DEGREES
DIV
EXP
FLOOR
GREATEST
LEAST
LN
LOG
LOG10
LOG2
MAX
MIN
MOD
PI
POW
POWER
RADIANS
RAND
ROUND
SIGN
SIN
SQRT
SUM
TAN
TRUNCATE
Функции дат
ADDDATE
ADDTIME
CURDATE
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
CURTIME
DATE
DATEDIFF
DATE_ADD
DATE_FORMAT
DATE_SUB
DAY
DAYNAME
DAYOFMONTH
DAYOFWEEK
DAYOFYEAR
EXTRACT
FROM_DAYS
HOUR
LAST_DAY
LOCALTIME
LOCALTIMESTAMP
MAKEDATE
MAKETIME
MICROSECOND
MINUTE
MONTH
MONTHNAME
NOW
PERIOD_ADD
PERIOD_DIFF
QUARTER
SECOND
SEC_TO_TIME
STR_TO_DATE
SUBDATE
SUBTIME
SYSDATE
TIME
TIME_FORMAT
TIME_TO_SEC
TIMEDIFF
TIMESTAMP
TO_DAYS
WEEK
WEEKDAY
WEEKOFYEAR
YEAR
YEARWEEK
Функции расширений
BIN
BINARY
CASE
CAST
COALESCE
CONNECTION_ID
CONV
CONVERT
CURRENT_USER
DATABASE
IF
IFNULL
ISNULL
LAST_INSERT_ID
NULLIF
SESSION_USER
SYSTEM_USER
USER
VERSION

SQL Server функции
Функции строк
ASCII
CHAR
CHARINDEX
CONCAT
Concat with +
CONCAT_WS
DATALENGTH
DIFFERENCE
FORMAT
LEFT
LEN
LOWER
LTRIM
NCHAR
PATINDEX
QUOTENAME
REPLACE
REPLICATE
REVERSE
RIGHT
RTRIM
SOUNDEX
SPACE
STR
STUFF
SUBSTRING
TRANSLATE
TRIM
UNICODE
UPPER
Функции чисел
ABS
ACOS
ASIN
ATAN
ATN2
AVG
CEILING
COUNT
COS
COT
DEGREES
EXP
FLOOR
LOG
LOG10
MAX
MIN
PI
POWER
RADIANS
RAND
ROUND
SIGN
SIN
SQRT
SQUARE
SUM
TAN
Функции дат
CURRENT_TIMESTAMP
DATEADD
DATEDIFF
DATEFROMPARTS
DATENAME
DATEPART
DAY
GETDATE
GETUTCDATE
ISDATE
MONTH
SYSDATETIME
YEAR
Функции расширений
CAST
COALESCE
CONVERT
CURRENT_USER
IIF
ISNULL
ISNUMERIC
NULLIF
SESSION_USER
SESSIONPROPERTY
SYSTEM_USER
USER_NAME

MS Access функции
Функции строк
Asc
Chr
Concat with &
CurDir
Format
InStr
InstrRev
LCase
Left
Len
LTrim
Mid
Replace
Right
RTrim
Space
Split
Str
StrComp
StrConv
StrReverse
Trim
UCase
Функции чисел
Abs
Atn
Avg
Cos
Count
Exp
Fix
Format
Int
Max
Min
Randomize
Rnd
Round
Sgn
Sqr
Sum
Val
Функции дат
Date
DateAdd
DateDiff
DatePart
DateSerial
DateValue
Day
Format
Hour
Minute
Month
MonthName
Now
Second
Time
TimeSerial
TimeValue
Weekday
WeekdayName
Year
Другие функции
CurrentUser
Environ
IsDate
IsNull
IsNumeric

SQL ОператорыSQL Типы данныхSQL Краткий справочник

SQL Учебник

SQL ГлавнаяSQL ВведениеSQL СинтаксисSQL SELECTSQL SELECT DISTINCTSQL WHERESQL AND, OR, NOTSQL ORDER BYSQL INSERT INTOSQL Значение NullSQL Инструкция UPDATESQL Инструкция DELETESQL SELECT TOPSQL MIN() и MAX()SQL COUNT(), AVG() и …SQL Оператор LIKESQL ПодстановочныйSQL Оператор INSQL Оператор BETWEENSQL ПсевдонимыSQL JOINSQL JOIN ВнутриSQL JOIN СлеваSQL JOIN СправаSQL JOIN ПолноеSQL JOIN СамSQL Оператор UNIONSQL GROUP BYSQL HAVINGSQL Оператор ExistsSQL Операторы Any, AllSQL SELECT INTOSQL INSERT INTO SELECTSQL Инструкция CASESQL Функции NULLSQL ХранимаяSQL Комментарии

Чистка

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

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

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

<?php$order_by = $mysqli->real_escape_string($_POST);  $stmt = $mysqli->prepare(“SELECT Id FROM Emails WHERE Username=? AND AcessKey=? ORDER BY $order_by”);  $stmt->bind_param(“ss”, $username, $accesskey);  $stmt->execute();?>

Защищайтесь эффективно!

Как вы видите, есть немало вариантов защиты от внедрения SQL-кода. Лучший способ — это по возможности использовать везде подготовленные инструкции или же утвержденный список, если такие инструкции применить невозможно. Приведение типов можно рассмотреть в качестве альтернативы утвержденному списку, но опять же, если нет возможности использовать подготовленные инструкции. Чистку ввода не рекомендуется задействовать в качестве единственного метода защиты от внедрений SQL-кода. Этот метод следует применять в совокупности с подготовленными инструкциями и утвержденным списком, чтобы добиться наилучшей безопасности, а также устранить ряд других web-уязвимостей.

• Развертывание Flask приложения на Heroku и подключение к БД MySQL — JawsDB
• Использование SQLite с Rust и Actix Web (с тестами)
• SQL в науке о данных

Читайте нас в Telegram, VK и

Наш взгляд на проблему

Мы предположили, что, как это часто бывает с «продвинутымии» DDoS-атаками Layer 7,  увидим только один или два http-запроса на каждый атакующий IP-адрес и что нам нужно иметь возможность принимать решения на уровне страны или AS. И именно здесь в игру вступает баунсер Cloudflare в составе Crowdsec.

Cloudflare через свой API позволяет устанавливать правила, нацеленные не только на диапазоны IP, но и на AS и страны, что удобно для нашего случая, а в качестве дополнительных средств защиты в нём имеются капча и JavaScript-челлендж. 

Вот чего мы хотели бы добиться (национальные флаги изображены произвольно и не имеют отношения к реальности):

Во время атаки Layer 7 для стран, откуда в основном идет атака, будет показываться капча (Китай, Индонезия и Индия в нашем примере), но легитимные пользователи оттуда всё равно попадут на сайт, в то время как пользователи из других стран (здесь — Франция и Испания) будут проходить без проверок. 

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

Далее мы создали сценарий CrowdSec для обнаружения чрезмерного трафика из определенной страны, автономной системы или любого заданного IP/диапазона. Этот сценарий через API Cloudflare включает капчу для источника атаки — страны/AS/диапазона/IP. 

Для корректной работы Apache должен быть настроен на работу с HTTP-заголовком X-forwarded-for, чтобы отображать реальные IP атакующих, а не адреса Cloudflare.

4. Не выводите сообщения об ошибках

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

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

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

Не нужно показывать оскорбительных надписей вроде «F*ck you, hacker!», это может обидеть некоторых тестеров. И вместо обычной процедуры «попробовал-не нашёл-переключился на следующий», тестер может взяться за ваш сайт серьёзно.

Рассмотрим такой вариант скрипта:

        <?php
        $mysqli = new mysqli("localhost", "root", "", "db_library");
        if (mysqli_connect_errno()) {
            printf("Не удалось подключиться: %sn", mysqli_connect_error());
            exit();
        } else {
            $mysqli->query("SET NAMES UTF8");
            $mysqli->query("SET CHARACTER SET UTF8");
            $mysqli->query("SET character_set_client = UTF8");
            $mysqli->query("SET character_set_connection = UTF8");
            $mysqli->query("SET character_set_results = UTF8");
        }

        $name = filter_input(INPUT_GET, 't');
        if ($result = $mysqli->query("SELECT * FROM `members` WHERE name = $name")) {
            while ($obj = $result->fetch_object()) {
                echo "<p><b>Ваше имя: </b> $obj->name</p>
        <p><b>Ваш статус:</b> $obj->status</p>
        <p><b>Доступные для Вас книги:</b> $obj->books</p><hr />";
            }
        } else {
           // printf("Ошибка: %sn", $mysqli->error);
        }
        $mysqli->close();
        ?>

Т.е. ничего не фильтруется и даже не поставлены кавычки вокруг $name. Результат следующий:

Т.е. в первый момент sqlmap назвала параметр не способным к инъекциям, но очень скоро спохватилась:

GET parameter 't' seems to be 'MySQL >= 5.0 boolean-based blind - Parameter replace' injectable

Т.е. параметр уязвим к слепой инъекции.