Штирлиц — Сеть печатных салонов в Перми

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

Sql инъекция это: SQL инъекции. Проверка, взлом, защита / Хабр

Почему SQL Injection — это самый опасный вид уязвимостей?

29 января 2018

Самый распространенный способ взлома сайтов и программ, работающих с базами данных, — SQL Injection. Чем же так опасна данная уязвимость?

SQL инъекция на данный момент является не только широко распространенной уязвимостью, а еще и одной из самых опасных по версии OWASP Top 10 Application Security Risks 2017. Попробуем разобраться почему.

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

Существует несколько типов SQL инъекций:

  • Классическая SQL Injection — простая и легкая в эксплуатации. Позволяет злоумышленнику атаковать БД и сразу видеть результат атаки. В последнее время встречается нечасто.
  • Error-based SQL Injection — чуть более сложный и затратный по времени тип атаки, позволяющий, на основе выводимых ошибок СУБД, получить информацию о всей БД и хранящиеся в ней данные. Эксплуатируется, если кто-то в спешке забыл отключить вывод ошибок.
  • Boolean-based SQL Injection — одна из «слепых» инъекций. Суть атаки сводится к добавлению специального подзапроса в уязвимый параметр, на который БД будет отвечать либо True, либо, неожиданно, False. Атака не позволяет сразу вывести все данные БД «на экран» злоумышленнику, но позволяет, перебирая параметры раз за разом, получить содержимое БД, хотя для этого потребуется временной отрезок соизмеримый с содержимым БД .
  • Time-based SQL Injection — следующая из «слепых» инъекций. В данном случае злоумышленник добавляет подзапрос, приводящий к замедлению или паузе работы БД при некоторых условиях. ), но, в зависимости от обстоятельств, чаще в БД хранится множество весьма критичных данных: учетные записи пользователей (включая пароли), номера телефонов, адреса электронной почты, а нередко номера карт, их сроки действия и прочие сопутствующие сведения.

    Чем грозит? В первую очередь, репутационными потерями, ведь мало кто захочет пользоваться сервисом, из которого могут вытащить какую-либо информацию о нём. Ещё хуже, если пароли хэшировались слабыми алгоритмами, что потенциально приведет к их восстановлению. Как вы понимаете, это крайне негативно отразится на всем бизнесе. Нечто подобное случилось у компании Taringa (новость на thehackernews.com), где пароли хранились хэшированными алгоритмом MD5, который еще в 2011 году был признан устаревшим (RFC 6151). В результате около 94% были восстановлены в течение нескольких суток.

    Deface


    Про последствия deface’а, наверняка, слышал каждый. Некоторые, даже встречали разного рода «акции», выраженные в размещении рекламы на главных страницах зачастую немаленьких и известных организаций, настройку редиректов на «вирусные сайты», замену всей главной страницы каким-нибудь мемом, а иногда даже и угрозами. Такие манипуляции зачастую организованы как раз при помощи SQL Injection-атак.
    Помимо столь грубых способов указать на проблемы безопасности, существуют более утонченные и элегантные. Например, долгое время предлагалась «услуга» по размещению номера телефона заказчика на сайте жертвы. То есть пользователь, заходя на сайт компании А, знакомился с описанием товаров и услуг, но звонил по подмененному номеру уже в компанию Б. И, что тоже немаловажно, такие «модификации» сайта замечаются далеко не сразу.

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

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

    Чтение системных файлов


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

    Повышение привилегий

    Некоторых нехороших пользователей по каким-то причинам может не устраивать тот факт, что они не являются администраторами в системах. С помощью SQL инъекции у таких пользователей появляется шанс исправить данную ситуацию. Так, например, в популярной CMS Joomla существовала возможность через инъекцию вытащить Cookie учётной записи администратора. Одним запросом, кстати говоря. А небезызвестная и распространённая MS SQL может предоставить даже несколько способов повысить привилегии (в зависимости от того, как сконфигурирована СУБД).

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

    Remote Code Execution (RCE)


    Является, пожалуй, самым опасным вектором атаки, к счастью, нечасто встречающимся. Обычно выполняется с целью получения shell’а и, следовательно, контроля над сервером целиком.
    Часто RCE осуществляется уже после атаки Privilege Escalation и из-за слабых настроек прав доступа в системе, но это происходит не всегда так. Для реализации атаки злоумышленник загружает файл-зловред и либо запускает его удалённо, либо сам одним из доступных образом «цепляется» к нему.
    Какие последствия могут быть? Любые, включая все ранее перечисленные. Все опять же зависит от целей злоумышленника. Кто-то начинает использовать сервер для майнинга криптовалюты, кто-то может настроить репликацию БД на «свой» сервер, а кто-то просто пойдет дальше и постарается получить управление остальными серверами в локальной сети. Последствия могут быть самыми печальными.

    Как защититься?

    Несмотря на всю серьёзность уязвимости, защита от атаки весьма проста: при разработке приложения необходимо уделить особое внимание фильтрации ввода и настройке прав. Обязательно отключайте вывод ошибок на «рабочей» системе, ни к чему пользователю такая чувствительная информация. И после каких-либо изменений в приложении проводить ASV-сканирования для гарантии. А в идеале, ввести данные действия в Software Development Life Cycle. Он же у вас уже есть, верно?

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

    Дополнительной мерой является установка Web Application Firewall (WAF) систем. Именно подобный класс решений заточен на борьбу с выше описанными атаками и, надо сказать, весьма хорош.

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

    Филипп Заболотный
    Ведущий инженер, Акрибия

    Follow @AcribiaRu

    Join channel

    Другие публикации по теме

    22 января 2018

    О требованиях по безопасности значимых объектов критической информационной инфраструктуры

    17 ноября 2017

    Рекомендации по защите: Distributed DoS (DDoS)

    27 августа 2017

    Обзор решения: RedCheck

    07 ноября 2017

    Инструменты аналитика SOC для выявления инцидентов

    Услуги

    Акрибия: Центр оперативного мониторинга

    Услуги

    Акрибия: Поддержка и аутсорсинг

    SQL-инъекция

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

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

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

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

    Распространенные примеры внедрения SQL

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

    Подрыв логики работы скрипта веб-сайта, где злоумышленник может изменить запрос для нарушения работоспособности кода сайта;

    UNION-атаки, где злоумышленник может получить данные из таблицы базы данных, например, логин и пароль;

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

    Слепое внедрение SQL — это когда результаты запроса к базе данных не возвращают ответ для корректной работы скрипта сайта.

    Предотвращение внедрения SQL

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

    Параметризованные запросы могут использоваться в любых случаях, когда ненадежный ввод отображается как данные в запросе, включая WHERE-предложение и значения в операторе INSERT или UPDATE. Их нельзя использовать для обработки ненадежного ввода в других частях запроса, таких как имена таблиц и столбцов или ORDER BY. Функциональные возможности скрипта, которые помещают ненадежные данные в эти части запроса, должны будут использовать другой подход, например, использование разрешенных входных значений белого списка или использование другой логики для обеспечения требуемого результата.

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

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

    (.*)$ — [F,L] </IfModule>