SQL-инъекции могут быть использованы различными способами для создания серьезных проблем. Используя SQL-инъекции, злоумышленник может обойти аутентификацию, получить доступ, изменить или удалить данные в базе данных. В некоторых случаях SQL-инъекции могут даже использоваться для выполнения команд в операционной системе, что потенциально позволяет злоумышленнику перейти к более разрушительным атакам внутри сети, которая находится за брандмауэром.
SQL-инъекции можно разделить на три основные категории – In-band SQLi, Inferential SQLi и Out-of-band SQLi.
In-band SQLi (классический SQLi)
In-band SQL инъекция является самым распространенным и самым простым в исполнении видом атак SQL инъекции. In-band SQL инъекции возникают, когда злоумышленник может использовать один и тот же канал связи для запуска атаки и сбора результатов.
Два наиболее распространенных типа in-band SQL инъекций – это SQLi на основе ошибок (Error-based SQLi) и SQLi на основе объединений (Union-based SQLi).
Error-based SQLi
Error-based SQLi – это метод внутриполосной SQL-инъекции, который полагается на сообщения об ошибках, отправляемые сервером базы данных для получения информации о структуре базы данных. В некоторых случаях злоумышленнику достаточно одной только error-based SQL-инъекции, чтобы перечислить всю базу данных. Хотя ошибки очень полезны на этапе разработки веб-приложений, их следует отключить на исправном сайте или вместо этого записать в файл с ограниченным доступом.
Union-based SQLi
Union-based SQLi – это внутриполосная техника SQL-инъекций, которая использует оператор UNION SQL для объединения результатов двух или более SELECT-операторов в один результат, который затем возвращается как часть HTTP-ответа.
Inferential SQLi (blind SQL)
Существует два типа inferential SQL-инъекций: SQLi на основе слепых булевых операций и SQLi на основе слепых временных операций (Blind-boolean-based SQLi и Blind-time-based SQLi).
Boolean-based (content-based) Blind SQLi
Boolean-based SQL инъекция – это метод Inferential SQL инъекции, основанный на отправке SQL-запроса в базу данных, который заставляет приложение возвращать разные результаты в зависимости от того, возвращает ли запрос результат TRUE или FALSE.
В зависимости от результата содержимое HTTP-ответа изменяется или остается неизменным. Это позволяет злоумышленнику сделать вывод о том, что используемая полезная нагрузка вернула true или false, даже если никаких данных из базы данных не возвращается. Эта атака обычно является медленной (особенно для больших баз данных), поскольку злоумышленнику нужно пересчитать базу данных, символ за символом.
Time-based Blind SQLi
Time-based SQL инъекция – это техника выводной SQL инъекции, которая основана на отправке SQL запроса к базе данных, что заставляет базу данных ждать определенное время (в секундах) перед тем, как ответить на него. Время ответа укажет злоумышленнику, является ли результат запроса TRUE или FALSE.
В зависимости от результата, HTTP-ответ будет возвращен с задержкой или возвращен немедленно. Это позволяет злоумышленнику сделать вывод о том, вернулась ли полезная нагрузка (payload) истинной или ложной, даже если никаких данных из базы данных не возвращается. Эта атака обычно медленная (особенно для больших баз данных), поскольку злоумышленнику нужно перебирать базу данных символ за символом.
Out-of-band SQLi
Out-of-band SQLинъекции не очень распространены, в основном потому, что они зависят от функций, включенных на сервере базы данных, используемом веб-приложением Out-of-band SQL инъекции возникают, когда злоумышленник не может использовать один и тот же канал для запуска атаки и сбора результатов.
Внеканальные методы предлагают злоумышленнику альтернативу методам, основанным на вычислении времени, особенно если ответы сервера не очень стабильны (что делает атаку, основанную на вычислении времени, ненадежной).
Out-of-band SQLi полагаются на способность сервера базы данных делать DNS или HTTP-запросы для передачи данных злоумышленнику. Это касается команды xp_dirtree в Microsoft SQL Server, которую можно использовать для отправки DNS-запросов на сервер, который контролирует злоумышленник; а также пакета UTL_HTTP в Oracle Database, который можно использовать для отправки HTTP-запросов с SQL и PL/SQL на сервер, который контролирует злоумышленник.
Как обнаружить SQL инъекции ?
Если используется только коммерческое или открытое программное обеспечение и отсутствует собственная разработка, то может быть достаточно определить точную версию используемой системы или приложения. Если определенная версия чувствительна к SQLi, можно предположить, что программное обеспечение уязвимо. Можно определить версию самостоятельно или воспользоваться соответствующим инструментом безопасности, например, решением для анализа состава программного обеспечения (SCA) для веб-приложений или сетевым сканером для сетевых систем и приложений.
Если разработчик приложений хочет иметь возможность потенциально находить в них SQLi уязвимости, он должен иметь возможность успешно эксплуатировать SQLi уязвимость, чтобы быть уверенным в ее существовании. Для этого нужно либо выполнить мануальное тестирование на проникновение с помощью исследователей безопасности, либо воспользоваться инструментом для сканирования уязвимостей, который может использовать автоматизацию для эксплуатации веб-уязвимостей. Примерами таких инструментов являются Invicti и Acunetix.
Как защититься от атак SQL-инъекций?
Возможные методы защиты от SQLi атак зависят от типа уязвимого программного обеспечения:
- В случае пользовательского программного обеспечения, такого как веб-приложения, единственным способом постоянной защиты от SQLi является использование параметризованных (parameterized) запросов или хранимых процедур, если параметризованные запросы недоступны. К другим мерам следует прибегать лишь в том случае, если переход на параметризованные запросы потребует значительных изменений в дизайне программного обеспечения, например, если нужно перенести устаревшее PHP-приложение с оригинального API MySQL на PDO или MySQLi.
- В случае известного SQLis в стороннем программном обеспечении, нужно проверить последние рекомендации по безопасности на наличие исправлений и обновить его до неуязвимой версии (как правило, до последней версии).
- В случае с zero-day SQLis в стороннем программном обеспечении, можно полагаться лишь на временные правила WAF (брандмауэр веб-приложений) для смягчения последствий. Однако, это лишь усложнит эксплуатацию SQLi и не устранит первопричину проблемы.
Далее рассмотрены меры, которые помогут уменьшить ущерб в случае успешной эксплуатации имеющейся уязвимости в SQLi:
- Разработчики: Для доступа к базе данных следует использовать самые низкие возможные привилегии. Каждый раз, когда выполняется доступ к базе данных в приложении, необходимо убедиться, что используется учетная запись базы данных, которая имеет минимально необходимые для этой операции привилегии.
- Администраторы базы данных: Отключить все опции, которые вызывают возвращение пользователю сообщений об ошибках базы данных, например, в ответах HTTP. Включить такие опции временно, только во время отладки кода.
- Системные администраторы: Убедитесь, что базовые операционные системы приложения и сервера базы данных защищены и обновлены. Это поможет предотвратить атаки на повышение привилегий в случае, если в приложении существует уязвимость SQL-инъекции.
