Вкратце знакомимся с DOM Clobbering.
Шаг 1
Из учебника JS узнаем, что:
При чтении HTML браузер генерирует DOM-модель. При этом большинство стандартных HTML-атрибутов становятся свойствами соответствующих объектов.
Например, если тег выглядит как
Глобальный объект предоставляет переменные и функции, доступные в любом месте программы. В браузере это
Шаг 2
Из книги JavaScript for Hackers узнаем непосредственно про сам DOM Clobbering: «Затирание (clobbering) DOM это метод, пользующийся преимуществом шаблона кодирования, который проверяет глобальную переменную и когда она не существует, следует иным путём кода.»
Основная идея состоит в том, что вы затираете несуществующую глобальную переменную неким элементом DOM, чаще всего элементом привязки (ancor).
Представьте что у вас имеется следующий код:
Данный образец кода на первый взгляд выглядит безобидным, но в действительности
Для большего понимания в терминологии данной книги «элементы привязки (ancor)» определены здесь: HTMLAnchorElement
Элементы привязки позволяют вам применять атрибут
Т.е. глобальная переменная
Шаг 3
Далее, знакомимся с DOM-коллекциями: «Особый перебираемый объект-псевдомассив»
В контексте атаки можно использовать несколько элементов с одним и тем же
В приводимом выше примере имеются две совместно используемых привязки атрибута
Шаг 4
Этих знаний должно быть достаточно для решения лабораторной работы в PortSwigger Academy, а так же ответа на вопрос из предыдущей подборки
DOM Clobbering Cheatsheet
#js
Шаг 1
Из учебника JS узнаем, что:
При чтении HTML браузер генерирует DOM-модель. При этом большинство стандартных HTML-атрибутов становятся свойствами соответствующих объектов.
Например, если тег выглядит как
<body id="page">, то у объекта будет свойство body.id = "page".Глобальный объект предоставляет переменные и функции, доступные в любом месте программы. В браузере это
window, а его свойства называются глобальные переменные.Шаг 2
Из книги JavaScript for Hackers узнаем непосредственно про сам DOM Clobbering: «Затирание (clobbering) DOM это метод, пользующийся преимуществом шаблона кодирования, который проверяет глобальную переменную и когда она не существует, следует иным путём кода.»
Основная идея состоит в том, что вы затираете несуществующую глобальную переменную неким элементом DOM, чаще всего элементом привязки (ancor).
Представьте что у вас имеется следующий код:
let url = window.currentUrl || 'http:///example.com';
Данный образец кода на первый взгляд выглядит безобидным, но в действительности
window.currentUrl управляется не только через глобальную переменную , но также и через элемент DOM. Для большего понимания в терминологии данной книги «элементы привязки (ancor)» определены здесь: HTMLAnchorElement
Элементы привязки позволяют вам применять атрибут
"href" для изменения имеющегося значения затираемого объекта:
<a href="clobbered:1337" id=x></a>
<noscript>
alert(x);//clobbered:1337
alert(typeof x);//object
</noscript>
Т.е. глобальная переменная
x затирается с помощью элемента привязки id, а значение переменной задается элементом привязки href.Шаг 3
Далее, знакомимся с DOM-коллекциями: «Особый перебираемый объект-псевдомассив»
В контексте атаки можно использовать несколько элементов с одним и тем же
id или name и это создаёт коллекцию
<a id=x>
<a id=x name=y href=clobbered:1337>
<noscript>
alert(x.y)//clobbered:1337
</noscript>
В приводимом выше примере имеются две совместно используемых привязки атрибута
id с одним и тем же значением "x", это формирует DOM-коллекцию, кроме того, вторая привязка обладает атрибутом name, а поскольку это коллекция DOM, вы можете ссылаться на элементы в такой коллекции по имени или индексу, в данном случае мы ссылаемся на вторую привязку по имени "y". Шаг 4
Этих знаний должно быть достаточно для решения лабораторной работы в PortSwigger Academy, а так же ответа на вопрос из предыдущей подборки
DOM Clobbering Cheatsheet
#js
learn.javanoscript.ru
Современный учебник JavaScript
Современный учебник JavaScript, начиная с основ, включающий в себя много тонкостей и фишек JavaScript/DOM.
👍3
1/2
Что можно предложить разрабам вместо .innerHTML, чтобы избежать DOM XSS (без использования фреймворков)?
Исходный код:
Тут сразу стоит сказать, что payload вида <noscript>alert(1)</noscript> не отработает, т.к. браузер парсит (анализирует) строку HTML и создаёт соответствующие DOM-элементы, но браузер только создаёт элемент в DOM, но не выполняет код внутри него. Связано это со спецификацией браузеров.
🔘 1. Вставлять пользовательский ввод как текст
В этом случае в теге <div> весь HTML код будет отображаться как текст. Не подходит для случаев, когда .innerHTML используется для вставки HTML-кода (например, для добавления новых элементов на сайт, которые зависят от пользовательского ввода)
🔘 2. Использовать CSP.
В данном примере директивы CSP объявляются через тег <meta> для удобства, но хорошей практикой считается выставление директив через HTTP заголовок, поскольку тег не контролирует контент до объявления тега + отсутствие поддержки некоторых директив посредством объявления через тег
CSP по умолчанию запрещает выполнение inline-скриптов, включая обработчики событий, таких как onerror, если не разрешено явно через 'unsafe-inline', хэши или nonces.
Получается, что тег <noscript> не вставить из-за спецификации браузера, а вставить onerror (да и любой другой обработчик событий) в любой другой тег не получится из-за CSP.
Такую защиту можно обойти, если в CSP будет указана директива ’unsafe-inline’ для скриптов. Возможно, есть еще байпас такого решения, но сходу не нашел
Что можно предложить разрабам вместо .innerHTML, чтобы избежать DOM XSS (без использования фреймворков)?
Исходный код:
<body>
<div id="output"></div>
<noscript src="test1.js"></noscript>
</body>
const userInput = '<img src=x onerror=alert(1)>';
const element = document.getElementById('output');
element.innerHTML = userInput;
Тут сразу стоит сказать, что payload вида <noscript>alert(1)</noscript> не отработает, т.к. браузер парсит (анализирует) строку HTML и создаёт соответствующие DOM-элементы, но браузер только создаёт элемент в DOM, но не выполняет код внутри него. Связано это со спецификацией браузеров.
🔘 1. Вставлять пользовательский ввод как текст
element.innerText = userInput;
element.textContent = userInput;
element.insertAdjacentText('beforeend', userInput);
В этом случае в теге <div> весь HTML код будет отображаться как текст. Не подходит для случаев, когда .innerHTML используется для вставки HTML-кода (например, для добавления новых элементов на сайт, которые зависят от пользовательского ввода)
🔘 2. Использовать CSP.
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; noscript-src 'self';">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<noscript>Document</noscript>
</head>
<body>
<div id="output"></div>
<noscript src="test1.js"></noscript>
</body>
</html>
В данном примере директивы CSP объявляются через тег <meta> для удобства, но хорошей практикой считается выставление директив через HTTP заголовок, поскольку тег не контролирует контент до объявления тега + отсутствие поддержки некоторых директив посредством объявления через тег
CSP по умолчанию запрещает выполнение inline-скриптов, включая обработчики событий, таких как onerror, если не разрешено явно через 'unsafe-inline', хэши или nonces.
Получается, что тег <noscript> не вставить из-за спецификации браузера, а вставить onerror (да и любой другой обработчик событий) в любой другой тег не получится из-за CSP.
Такую защиту можно обойти, если в CSP будет указана директива ’unsafe-inline’ для скриптов. Возможно, есть еще байпас такого решения, но сходу не нашел
2/2
Две новые технологии, с которыми я знакомлюсь:
🔘 3. Использовать Trusted Types API (TTA)
Основная идея и ее использование хорошо описано в данном видео.
Если вкратце, то браузер позволит вставить в DOM только «доверенные типы» данных. Чтобы использовать данную технологию, добавляем политику CSP с директивой require-trusted-types-for (использование TTA не совместимо с использованием классического CSP).
Пример:
Здесь мы говорим, что хотим применять политику TTA в скриптах. Теперь объявим «доверенный тип» my-types в политике CSP:
Опишем его:
Хук createHTML вызывается, когда код пытается произвести изменения в DOM, вставить какую-либо строку, и он эту строку должен обработать. Его обработкой (санитизацией) занимается сам разработчик. В данном примере идет замена в строке символа на закодированный. Здесь так же можно использовать сторонние библиотеки, например DOMPurify:
Существует всего три хука: createHTML, createScript, createScriptURL
Данная технология отработает в Google Chrome, выдав ошибку
Но в Firefox ситуация обратная, alert(1) выполнился, а браузер указал, что не знает такой директивы:
В этом минус данной технологии, ее не поддерживают все браузеры: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
🔘 4. Sanitizer API.
Из того же видео узнаем, что в современных браузерах есть встроенное API для санитизации. В видео два примера, один с явным созданием объекта Sanitizer:
Второй — более простой, просто с использованием метода .setHTML() вместо .innerHTML.
В Google Chrome в свежих версиях включен по умолчанию, в Firefox в тестовом режиме, поэтому выключен. Можно включить в настройках (`about:config`): dom.security.sanitizer.enabled
Почитать можно здесь: https://web.dev/articles/sanitizer
Две новые технологии, с которыми я знакомлюсь:
🔘 3. Использовать Trusted Types API (TTA)
Основная идея и ее использование хорошо описано в данном видео.
Если вкратце, то браузер позволит вставить в DOM только «доверенные типы» данных. Чтобы использовать данную технологию, добавляем политику CSP с директивой require-trusted-types-for (использование TTA не совместимо с использованием классического CSP).
Пример:
<meta http-equiv="Content-Security-Policy" content="require-trusted-types-for 'noscript';">
Здесь мы говорим, что хотим применять политику TTA в скриптах. Теперь объявим «доверенный тип» my-types в политике CSP:
<meta http-equiv="Content-Security-Policy" content="trusted-types my-types; require-trusted-types-for 'noscript';">
Опишем его:
const escapeHTMLPolicy = window.trustedTypes.createPolicy('my-types', {
createHTML: string => string.replace(/\</g, '<'),
})
Хук createHTML вызывается, когда код пытается произвести изменения в DOM, вставить какую-либо строку, и он эту строку должен обработать. Его обработкой (санитизацией) занимается сам разработчик. В данном примере идет замена в строке символа на закодированный. Здесь так же можно использовать сторонние библиотеки, например DOMPurify:
const escapeHTMLPolicy = trustedTypes.createPolicy('my-types', {
createHTML: (input) => {
// Очистка или проверка входных данных
return DOMPurify.sanitize(input);
},
});
Существует всего три хука: createHTML, createScript, createScriptURL
Данная технология отработает в Google Chrome, выдав ошибку
This document requires 'TrustedHTML' assignment.
Uncaught TypeError: Failed to set the 'innerHTML' property on 'Element': This document requires 'TrustedHTML' assignment.
Но в Firefox ситуация обратная, alert(1) выполнился, а браузер указал, что не знает такой директивы:
Content-Security-Policy: Не удалось обработать неизвестную директиву «require-trusted-types-for»
В этом минус данной технологии, ее не поддерживают все браузеры: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
🔘 4. Sanitizer API.
Из того же видео узнаем, что в современных браузерах есть встроенное API для санитизации. В видео два примера, один с явным созданием объекта Sanitizer:
let sanitizer = new Sanitizer();
let b = sanitizer.sanitizeFor("div", userInput);
console.log(b)
Второй — более простой, просто с использованием метода .setHTML() вместо .innerHTML.
const userInput = '<img src=x onerror=alert(1)>';
const element = document.getElementById('output');
element.setHTML(userInput);
В Google Chrome в свежих версиях включен по умолчанию, в Firefox в тестовом режиме, поэтому выключен. Можно включить в настройках (`about:config`): dom.security.sanitizer.enabled
Почитать можно здесь: https://web.dev/articles/sanitizer
YouTube
No more XSS. Trusted Types will save you
In this video you will learn how to use the Trusted Types header and how it can solve all your XSS problems.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types
We'll also talk a little about the new DOM API…
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types
We'll also talk a little about the new DOM API…
🔥1
Недавно установил себе агрегатор новостей. Довольно удобно, все в одном месте, можно собрать сборник про политику, можно на другие темы. Так же есть возможность добавить YouTube каналы. Мб можно еще телеграмм каналы, но пока не разобрался.
Вот список, который у меня собрался на данный момент.
Вот список, который у меня собрался на данный момент.
App Store
feeeed: rss reader and more App - App Store
Download feeeed: rss reader and more by James Parrott on the App Store. See screenshots, ratings and reviews, user tips, and more games like feeeed: rss reader…
👍4
Intro в client-side уязвимости. Будет полезно знать чуть больше, чем 3 вида XSS и CSRF.
https://wr3dmast3r.gitbook.io/client-side-fundamental
https://wr3dmast3r.gitbook.io/client-side-fundamental
wr3dmast3r.gitbook.io
Добро пожаловать | Client-Side Fundamental
👍5
Еще один ИБ-шный roadmap, в этот раз по специальностям на русском языке с материалами.
Так же в ней выделены перспективные специальности на горизонте 3-5 лет. В основном связано с *SecOps направлениями, ML и крипта.
https://cybersecurity-roadmap.ru
Так же в ней выделены перспективные специальности на горизонте 3-5 лет. В основном связано с *SecOps направлениями, ML и крипта.
https://cybersecurity-roadmap.ru
cybersecurity-roadmap.ru
Схема карьерных треков в кибербезопасности (информационной безопасности)
Дорожная карта развития в области информационной безопасности
👍3
Если говорить про санитизацию с использованием объектных моделей, то в контексте запросов к СУБД в голову сразу приходит ORM (Object-Relational Mapping).
Для других подсистем объектная модель обычно реализуется через шаблон проектирования
Для лучшего понимания паттернов в особенности билдеров может подойти ресурс https://refactoring.guru/design-patterns/creational-patterns
Для других подсистем объектная модель обычно реализуется через шаблон проектирования
Builder (например java.lang.ProcessBuilder для контекста запросов к ОС). Но что такое этот ваш билдер?Для лучшего понимания паттернов в особенности билдеров может подойти ресурс https://refactoring.guru/design-patterns/creational-patterns
refactoring.guru
Builder
Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.
👍5
Host-Only Cookie
Вы когда-нибудь задумывались, как изменится поведение браузера относительно Cookie при указании дополнительного атрибута
В контексте SameSite Cookie, "site" определяется как домен верхнего уровня (TLD), обычно что-то вроде
Однако, если явно указать атрибут
Явное указание домена Cookie сервером расширяют область, где они отправляются, вплоть до уязвимых поддоменов.
Firefox, например, явно добавляет данный атрибут всем Cookie, у кого был указан домен (в общем списке будет начинаться с точки), но только, если выбрать Cookie для просмотра.
Вы когда-нибудь задумывались, как изменится поведение браузера относительно Cookie при указании дополнительного атрибута
domain?
Set-Cookie: session=...; SameSite=Strict;
Set-Cookie: session=...; SameSite=Strict; domain=example.com
В контексте SameSite Cookie, "site" определяется как домен верхнего уровня (TLD), обычно что-то вроде
.com или .net, плюс один дополнительный уровень доменного имени (эта часть обозначается как TLD+1), а также учитывается схема URL-адресов: http://{...}.example.com. Несмотря на это, Cookie без явного указания домена сервером не будут подставляться для поддоменов. Такие Cookie привязаны исключительно к точному домену и называются host-only.Однако, если явно указать атрибут
domain, то политика браузера подразумевает использования Cookie для всех поддоменов относительно указанного домена. Т.е. Cookie session с указанным атрибутом domain=example.com для браузера тоже самое, что domain=.example.com (он так и будет помечать область действия Cookie). Явное указание домена Cookie сервером расширяют область, где они отправляются, вплоть до уязвимых поддоменов.
Firefox, например, явно добавляет данный атрибут всем Cookie, у кого был указан домен (в общем списке будет начинаться с точки), но только, если выбрать Cookie для просмотра.
🔥5❤1👍1
Как известно Site в контексте браузера это схема и TLD+1 (см. подробнее здесь). Представим, что мы зарегистрированы на ресурсе
"Public Suffix List" – список доменных окончаний (например,
В прошлом браузеры использовали алгоритм, который запрещал установку wide-ranging Cookie (или Super Cookie) только для доменов верхнего уровня (TLD) без точек (например,
Чтобы предотвратить подобные проблемы, браузеры используют Public Suffix List. Этот список помогает ограничить установку Cookie на такие общие домены, тем самым предотвращая установку «Super Cookie». А определение Site в контексте браузера корректнее интерпретировать как URL схема и eTLD+1.
Подробнее: https://publicsuffix.org/learn/same-site
tsu.edu.ru, и браузер хранит Cookie для данного хоста. Как поведет себя браузер, если мы посетим ресурс tusur.edu.ru? Отправит ли он Cookie одного ресурса на другой, если выполняется условие TLD+1?"Public Suffix List" – список доменных окончаний (например,
.com, .co.uk), под которыми конечные пользователи могут напрямую регистрировать свои доменные имена. Так же этот список еще называют eTLD (effective top-level domain).В прошлом браузеры использовали алгоритм, который запрещал установку wide-ranging Cookie (или Super Cookie) только для доменов верхнего уровня (TLD) без точек (например,
com или org). Однако это не работало для доменов верхнего уровня, в которых разрешена регистрация только третьего уровня (например, co.uk). В таких случаях сайты могли установить Cookie для домена .co.uk, который передавался каждому сайту, зарегистрированному в домене co.uk.Чтобы предотвратить подобные проблемы, браузеры используют Public Suffix List. Этот список помогает ограничить установку Cookie на такие общие домены, тем самым предотвращая установку «Super Cookie». А определение Site в контексте браузера корректнее интерпретировать как URL схема и eTLD+1.
Подробнее: https://publicsuffix.org/learn/same-site
🔥8
На meetup’е от koronatech узнал про интересную особенностью Postman — хранение данных, которые через него проходят, на серверах Postman’а в США. Отказ от подобного сбора данных ведет к «окерпичиванию» продукта. Особый интерес к этой особенности стоит обратить внимание компаниям, чьи разрабы/тестировщики активно используют Postman для работы с API.
В качестве альтернативы предложили рассмотреть https://hoppscotch.io/.
AppSec’и koronatech так же приложили руку к развитию данного продукта, закрывая свои потребности и проблемы при его использовании, отправляя MR’ы разработчикам hoppscotch.
В качестве альтернативы предложили рассмотреть https://hoppscotch.io/.
AppSec’и koronatech так же приложили руку к развитию данного продукта, закрывая свои потребности и проблемы при его использовании, отправляя MR’ы разработчикам hoppscotch.
🌚4👍3🔥2
Продолжаем узнавать Cookie чуть больше. Сегодня поговорим о «чипсах» в печеньках 🍪
Partitioned Cookies (CHIPS) — это специальные куки, которые работают только в рамках top-level site, даже если они установлены сторонним сервисом.
Cookies с пометкой Partitioned имеют двойной ключ: по источнику (origin), который их устанавливает , и по источнику top-level page.
Как это работает?
1. Обычные сторонние куки:
Допустим, сайт А и сайт Б используют один и тот же сервис аналитики (например, analytics.com). Без Partitioned Cookies сервис analytics.com может записать куки в браузер пользователя на сайте А, а потом использовать тот же куки на сайте Б. Это позволяет отслеживать, какие ресурсы вы посетили.
2. С Partitioned Cookies:
Куки от analytics.com будут привязаны к сайту А. Если пользователь перейдет на сайт Б, который тоже использует analytics.com, браузер создаст новый куки для сайта Б. Таким образом, аналитический сервис не сможет связать ваши действия на разных сайтах.
Примеры использования.
- Сохранение некоторой приватности. Сайты и рекламные сети больше не смогут собирать данные о вашем поведении на разных ресурсах через общие куки.
- Если вы зашли на сайт интернет-магазина и там работает встроенный чат от chat-service.com, этот сервис установит Partitioned Cookie. Позже, если вы откроете другой сайт с тем же чатом, chat-service.com не получит доступ к куки с интернет-магазина — чат начнется «с нуля»
Partitioned Cookies (CHIPS) — это специальные куки, которые работают только в рамках top-level site, даже если они установлены сторонним сервисом.
«Top-level site» (верхнеуровневый сайт) — это сайт, который вы видите в адресной строке браузера. Например, если вы открыли сайт shop.com, а на нём есть встроенная карта от maps-service.com или чат от chat-widget.com, то shop.com и будет top-level site.
Если вы открыли сайт news.com, то news.com — это top-level site (сайт верхнего уровня), а конкретная страница, например news.com/sports — это top-level page (страница верхнего уровня).
Cookies с пометкой Partitioned имеют двойной ключ: по источнику (origin), который их устанавливает , и по источнику top-level page.
Как это работает?
1. Обычные сторонние куки:
Допустим, сайт А и сайт Б используют один и тот же сервис аналитики (например, analytics.com). Без Partitioned Cookies сервис analytics.com может записать куки в браузер пользователя на сайте А, а потом использовать тот же куки на сайте Б. Это позволяет отслеживать, какие ресурсы вы посетили.
2. С Partitioned Cookies:
Куки от analytics.com будут привязаны к сайту А. Если пользователь перейдет на сайт Б, который тоже использует analytics.com, браузер создаст новый куки для сайта Б. Таким образом, аналитический сервис не сможет связать ваши действия на разных сайтах.
Примеры использования.
- Сохранение некоторой приватности. Сайты и рекламные сети больше не смогут собирать данные о вашем поведении на разных ресурсах через общие куки.
- Если вы зашли на сайт интернет-магазина и там работает встроенный чат от chat-service.com, этот сервис установит Partitioned Cookie. Позже, если вы откроете другой сайт с тем же чатом, chat-service.com не получит доступ к куки с интернет-магазина — чат начнется «с нуля»
Please open Telegram to view this post
VIEW IN TELEGRAM
MDN Web Docs
Cookies Having Independent Partitioned State (CHIPS) - Privacy on the web | MDN
Cookies Having Independent Partitioned State (CHIPS, also known as Partitioned cookies) allows developers to opt a cookie into partitioned storage, with a separate cookie jar per top-level site.
🔥5
Наконец-то прошел сертификацию: Burp Suite Certified Practitioner 😈
4 часа и 2 веб-приложения, в которых по 3 этапа (в каждом):
1. Получить доступ к низкопривилегированному пользователю
2. Поднять привилегии до админа
3. Прочесть файл: /home/carlos/secret
На каждом этапе и в каждом приложении полный рандом. Одно приложение может быть в копейку как лабы PS Academy (решение идентично), а второе — габелла. А может быть, что оба приложения не сахар.
Если сформировалось «тунельное зрение» на лабах PS Academy, вас на этом могут подловить. Перед сдачей сертификации вам на это тонко намекнут.
Опыт получился интересный, не безболезненный.
Ну и прувы: https://portswigger.net/web-security/e/c/a717674510ae8b65
4 часа и 2 веб-приложения, в которых по 3 этапа (в каждом):
1. Получить доступ к низкопривилегированному пользователю
2. Поднять привилегии до админа
3. Прочесть файл: /home/carlos/secret
На каждом этапе и в каждом приложении полный рандом. Одно приложение может быть в копейку как лабы PS Academy (решение идентично), а второе — габелла. А может быть, что оба приложения не сахар.
Если сформировалось «тунельное зрение» на лабах PS Academy, вас на этом могут подловить. Перед сдачей сертификации вам на это тонко намекнут.
Опыт получился интересный, не безболезненный.
Ну и прувы: https://portswigger.net/web-security/e/c/a717674510ae8b65
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Обновления.
В semgrep выше версии 1.100.0 решили убрать snippet’ы (участки исходного кода) в поле
Для этого нужно зарегаться на их площадке Semgrep AppSec Platform, создать токен доступа и прикрепить его себе в переменную окружения
Однако такой запрет обходится созданием переменной окружения
Например, такого Dockerfile будет вполне достаточно
Сканер вернет нам отчет с snippet’ами, как и положено
В semgrep выше версии 1.100.0 решили убрать snippet’ы (участки исходного кода) в поле
lines из отчетов для незалогиненных пользователей. В таком случае будет возвращаться «requires login»
"fingerprint": "requires login",
"lines": "requires login",
Для этого нужно зарегаться на их площадке Semgrep AppSec Platform, создать токен доступа и прикрепить его себе в переменную окружения
SEMGREP_APP_TOKEN.Однако такой запрет обходится созданием переменной окружения
SEMGREP_APP_TOKEN с произвольным значением и даже без доступа в интернет🌚.Например, такого Dockerfile будет вполне достаточно
FROM semgrep/semgrep
WORKDIR /opt
COPY . /opt/
ENV SEMGREP_APP_TOKEN="qqq"
CMD ["semgrep", "scan", "--metrics=off", "--config=/opt/rules", "--json", "/src", "--output", "/out/semgrep.json"]
Сканер вернет нам отчет с snippet’ами, как и положено
👍4🌚4
Forwarded from Arkiix's Blog
JWT blacklist bypass
Как вы все знаете, JWT самодостаточен. Именно это делает его таким удобным, но некоторые обычные вещи становятся невозможными, например завершение сессии пользователя.
Если пойти в Google с вопросом об отзыве JWT, вы наткнётесь на кучу обсуждений и предложений. Обычно подход заключается в занесении его в blacklist, который хранится, например, в Redis. В интернете много рекомендаций вроде: когда нужно отозвать токен, сохраняешь его (или его хэш) в Redis, а когда запрос с токеном прилетает на сервер — проверяешь, нет ли его там.
Во время пентеста я заметил интересную аномалию, природа которой описана в этой статье: Decoding the JWT anomaly. Если последний символ в подписи JWT заменить на смежный в алфавите, то сигнатура остаётся валидной, и сервер не замечает разницы.
Пример:
Заменив в конце токена букву s на t, получаем валидный токен. Можете проверить сигнатуру на jwt.io (ключ — “key”).
Отсюда появилась теория: если сервер ведёт blacklist JWT, сохраняя в него сам токен или его хэш, то, заменив последний символ, подпись останется валидной, но этого токена (или его хэша) не будет в blacklist.
Теорию я проверил на bug bounty, и уже во второй программе смог «возрождать» отозванные токены.
Если при разработке сервиса всё-таки необходимо отзывать JWT, то заносите в blacklist jti или другие уникальные идентификаторы токена.
Как вы все знаете, JWT самодостаточен. Именно это делает его таким удобным, но некоторые обычные вещи становятся невозможными, например завершение сессии пользователя.
Если пойти в Google с вопросом об отзыве JWT, вы наткнётесь на кучу обсуждений и предложений. Обычно подход заключается в занесении его в blacklist, который хранится, например, в Redis. В интернете много рекомендаций вроде: когда нужно отозвать токен, сохраняешь его (или его хэш) в Redis, а когда запрос с токеном прилетает на сервер — проверяешь, нет ли его там.
Во время пентеста я заметил интересную аномалию, природа которой описана в этой статье: Decoding the JWT anomaly. Если последний символ в подписи JWT заменить на смежный в алфавите, то сигнатура остаётся валидной, и сервер не замечает разницы.
Пример:
eyJhbGciOiJIUzI1NiJ9.eyIxIjoxfQ.OUTJgV9NjeWLUPzLk0QzICm280pH00Zf54IpR5C4IFs
eyJhbGciOiJIUzI1NiJ9.eyIxIjoxfQ.OUTJgV9NjeWLUPzLk0QzICm280pH00Zf54IpR5C4IFt
Заменив в конце токена букву s на t, получаем валидный токен. Можете проверить сигнатуру на jwt.io (ключ — “key”).
Отсюда появилась теория: если сервер ведёт blacklist JWT, сохраняя в него сам токен или его хэш, то, заменив последний символ, подпись останется валидной, но этого токена (или его хэша) не будет в blacklist.
Теорию я проверил на bug bounty, и уже во второй программе смог «возрождать» отозванные токены.
Если при разработке сервиса всё-таки необходимо отзывать JWT, то заносите в blacklist jti или другие уникальные идентификаторы токена.
👍7❤2🔥2🌚1
Сегодня решил покапать Bug Bounty и снова столкнулся с тестированием bitrix и словил пару флешбеков.
На тему безопасности bitrix был уже не один доклад.
Если вкратце, то вот хороший материал №1 и хороший материал №2 на эту тему.
Есть даже сканер, который позволяет автоматизированно проводить типовые проверки потенциальных sink’ов. За основу взят, наверное, самый популярный доклад по уязвимостям битрикс.
Так же обнаружил еще один способ обхода ограничений на
В моем случае загружает страницу входа, но без стилей и popup’ов. Это не мешает воспользоваться функционал данной страницы.
Так же вот доп ресурсы, которые я бы добавил:
- Worldlist ручек битрикса.
- Слитый код демо версии bitirx. Можно подглядывать при blackbox тестировании +еще (да, здесь был открытый код core части команды битрикса)
- Документация для разработчиков
- Официально опубликованные найденные уязвимости bitrix, некоторые содержат PoC
- Сплойты для CVE, есть и для bitrix
На тему безопасности bitrix был уже не один доклад.
Если вкратце, то вот хороший материал №1 и хороший материал №2 на эту тему.
Есть даже сканер, который позволяет автоматизированно проводить типовые проверки потенциальных sink’ов. За основу взят, наверное, самый популярный доклад по уязвимостям битрикс.
Так же обнаружил еще один способ обхода ограничений на
/bitrix/admin (помимо тех, что были в докладах):
/bitrix/components/bitrix/desktop/admin_settings.php?lang=ru&bxpublic=Y
В моем случае загружает страницу входа, но без стилей и popup’ов. Это не мешает воспользоваться функционал данной страницы.
Так же вот доп ресурсы, которые я бы добавил:
- Worldlist ручек битрикса.
- Слитый код демо версии bitirx. Можно подглядывать при blackbox тестировании +
- Документация для разработчиков
- Официально опубликованные найденные уязвимости bitrix, некоторые содержат PoC
- Сплойты для CVE, есть и для bitrix
Telegram
README.hta
Дано: предположительная компрометация сервера на CMS 1C:Битрикс.
⢉⣠⠃ ⠒⠥⠕⣁⢘⢄⠱⠸ ⢒⠓⠆⠥⡈ ⠰⢠⡡ ⢢⡉⡊⠩⠃⢤⡄⢔⢁⠬⠓⠙⢐ ⢔⠙⠓ ⢉⢈⢊⡑⠸⣀ ⡡⢡⡢⡂⠇⣁⠍⠡⠔⡠⡄⡄ ⡈⡈⡃⠙⠌⢑⣁⢰⡠ ⡤⡠⠢⠔ ⠉⠙⠎⠨⠥⡢ ⢔⠇⢢⠊⠨⢈⠖ ⢃⠕⠢⣈⠑⠋⡒⡑ ⡠⡤⠦⡑⠡⡤⠍⠍⠇⣂⢡⢃⢠⠉⡈⠩⢢⠉⠓⣁⡔⠤⢑⢤⠅⠚ ⢘⠒⢆⠬⡰⠩⡤ ⡈⡉⢠⠖⣐⠤⡰⠕⠆⣐⡢⠲ ⡔⡘⠙⡁⠌ ⢒⣀⡄⠢⡐⡐⠸⠸⢠⢌⠒⠱⢐ ⢄ ⡰⢨⠌ ⠨⠍⡄⠎⢃⡢ ⠋⣂⡠⠪⡊⠤⡘⠨⣐⠅⢒…
⢉⣠⠃ ⠒⠥⠕⣁⢘⢄⠱⠸ ⢒⠓⠆⠥⡈ ⠰⢠⡡ ⢢⡉⡊⠩⠃⢤⡄⢔⢁⠬⠓⠙⢐ ⢔⠙⠓ ⢉⢈⢊⡑⠸⣀ ⡡⢡⡢⡂⠇⣁⠍⠡⠔⡠⡄⡄ ⡈⡈⡃⠙⠌⢑⣁⢰⡠ ⡤⡠⠢⠔ ⠉⠙⠎⠨⠥⡢ ⢔⠇⢢⠊⠨⢈⠖ ⢃⠕⠢⣈⠑⠋⡒⡑ ⡠⡤⠦⡑⠡⡤⠍⠍⠇⣂⢡⢃⢠⠉⡈⠩⢢⠉⠓⣁⡔⠤⢑⢤⠅⠚ ⢘⠒⢆⠬⡰⠩⡤ ⡈⡉⢠⠖⣐⠤⡰⠕⠆⣐⡢⠲ ⡔⡘⠙⡁⠌ ⢒⣀⡄⠢⡐⡐⠸⠸⢠⢌⠒⠱⢐ ⢄ ⡰⢨⠌ ⠨⠍⡄⠎⢃⡢ ⠋⣂⡠⠪⡊⠤⡘⠨⣐⠅⢒…
🔥8
Случайно наткнулся на интересный ресурс — Сделай свой X.
Это GitHub репозиторий, в котором собраны практики по низкоуровневому программированию. Из примеров: Сделай свой
- блокчейн
- браузер
- эмулятор
- ОС
Будет не лишним для обучения или портфолио
Это GitHub репозиторий, в котором собраны практики по низкоуровневому программированию. Из примеров: Сделай свой
- блокчейн
- браузер
- эмулятор
- ОС
Будет не лишним для обучения или портфолио
GitHub
GitHub - codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.
Master programming by recreating your favorite technologies from scratch. - codecrafters-io/build-your-own-x
👍6
Я решил, что в рунете мало статей по SOP и CORS, поэтому решил добавить еще одну, попутно расписав другие cross-origin политики безопасности браузера.
Хабр
CORS, CORP, COEP, COOP. Разбираемся со всеми CO* и смотрим на нюансы
В сети интернет достаточно информации на русском языке по поводу SOP и CORS, но введение в такие технологии как CORP, COEP и COOP показалось недостаточным (а кто-то может видеть эти аббревиатуры...
🔥10👍1
Недавно проходил VolgaCTF, в котором я принимал участие в составе команды SiBears 🐻
Попался достаточно интересный таск на SQL-инъекцию, который удалось успешно решить. Решил поделиться размышлениями и ходом действий в решении таска.
🔍 Writeup-SQL-injection-task-VolgaCTF-2025
Попался достаточно интересный таск на SQL-инъекцию, который удалось успешно решить. Решил поделиться размышлениями и ходом действий в решении таска.
🔍 Writeup-SQL-injection-task-VolgaCTF-2025
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤1