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
Forwarded from Whitehat Lab
Windows, *nix машины для самостоятельного пентеста. Во free тарифе всегда доступно 20 машин. Обучение, академия, лабы и т.д. Есть огромное количество CTF заданий в различных категориях.
Возможность сдать экзамены и получить сертификаты CBBH (Certified Bug Bounty Hunter), CPTS (Certified Penetration Testing Specialist), CWEE (Certified Web Exploitation Expert) и CDSA (Certified Defensive Security Analyst)🙃
Аналог HackTheBox без CTF заданий. Академия в наличии, также присутствует free тариф😁
Академия веб пентеста от создателей BurpSuite. Для сдачи экзамена необходима активная подписка на Burp Suite Professional, цена экзамена 99$😈
Информацию почти обо всех прошедших и предстоящих CTF соревнованиях можно найти здесь
Русскоязычная площадка😎 . Большое (300+) количество CTF задач в самых различных категориях (web, crypto, rev, pwn, osint и т.д.), в наличии Windows и Linux машины. Есть бесплатный тариф
Один из лучших ресурсов с задачами по криптографии. Нравится криптография ? Вам сюда, от азов до сложнейших задач
Киберполигон от компании😎 Positive Technologies. Это виртуальная инфраструктура с реалистичными копиями IT-систем из разных отраслей. Достаточно высокий порог вхождения. Ежегодно проводятся турниры, куда вы можете отобраться со своей командой
Русскоязычная площадка от ребят из команды TaipanByte, большое кол-во тасков (80+) во всех основных категориях
Образовательная платформа, позволяющая изучать и практиковать основные концепции кибербезопасности. Рассчитана на новичков
Appsec тренировки, LLM, owasp top10, owasp api top10, aws top10 и т.д.
Путешествие в мир Linux, основные команды, лабы, руководства
Игра из 34 уровней для изучения Linux
Большое количество (~4000) крякми для изучения. Подойдет реверсерам
Для любителей бинарной эксплуатации (PWN)
Русскоязычная площадка. One task of the month - выкладывают по 1ой CTF задаче в месяц, в этом году планируют 10 заданий в категориях: web, pwn, crypto, reverse, misc и т.д.
Огромное (500+) кол-во заданий в самых разных категориях
Площадка с CTF заданиями начального уровня, почти на все задания можно найти райтапы
ВМ Phoenix для изучения уязвимостей, разработки эксплойтов, отладки программного обеспечения и общих проблем кибербезопасности
Темы - Network programming, Stack overflows, Format string vulnerabilities, Heap overflows
Парольные загадки (ребусы), например, пароль это сумма чисел от 1 до 446, соответственно надо написать простенькую автоматизацию и ввести в поле ввода
Простенький хакер квест состоящий из 20 уровней
#htb #crackmes #bandit #hacking #ctf #ethical
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥3
Представим ситуацию, у нас реализуется web-приложение с stateless сессиями — с использованием accessToken. Пользователь проходит аутентификацию, и backend-сервер выпускает accessToken и передает его клиенту.
Классический вопрос: «Где хранить accessToken на клиенте?».
Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage?
😏 Чем плохо такое решение? Если хранить accessToken в localStorage, то при XSS у злоумышленника будет доступ к хранилищу браузера, и токен может быть украден.
На практике мне встречалась реализация, где разработчикии рыбку съели и токен хранили в Cookie, и подставляли его в HTTP Header через JS.
Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly.
😏 Чем плох этот вариант? Помимо XSS, при небезопасной конфигурации CORS, злоумышленник сможет получить токен жертвы из ответа сервера, заманив ее на подконтрольный ресурс.
Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers.
Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена.
Web Worker делится на три вида:
• Dedicated workers: используется только одним скриптом
• Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах.
• Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью.
🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker.
🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.
Классический вопрос: «Где хранить accessToken на клиенте?».
Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage?
На практике мне встречалась реализация, где разработчики
Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly.
Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers.
Web Workers это механизм, который позволяет скрипту выполняться в фоновом потоке, который отделен от основного потока веб-приложения.
Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена.
Web Worker делится на три вида:
• Dedicated workers: используется только одним скриптом
• Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах.
• Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью.
🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker.
🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.
Please open Telegram to view this post
VIEW IN TELEGRAM
MDN Web Docs
DedicatedWorkerGlobalScope - Web APIs | MDN
The DedicatedWorkerGlobalScope object (the Worker global scope) is accessible through the self keyword. Some additional global functions, namespaces objects, and constructors, not typically associated with the worker global scope, but available on it, are…
👍6❤4🔥3