Вы наверняка знаете, но если вдруг не знаете, то PayloadsAllTheThings — это уникальный репозиторий, наполненный полезными payload-ами и методами обхода.

Например, вот кейс его использования.

#cheatsheet #payload

Взломали Google (почти)

Написал на коленке writeup на таск категории web прошедшего Google CTF.

Из интересного в статье:
- Схема data:,, и как ее можно использовать в своих целях
- Использование event listener
- Особенности fetch() запроса для получения в ответе подконтрольных данных

Вредный совет, как можно решать таски (и только таски ctf 🌚), в которых нужен подконтрольный ресурс для отправки эксплойта и получения флага — лабы portswigger, например csrf.

В client-side лабах как правило предоставляется временный сервер для эксплойта. Он доступен в глобальной сети и идеально подходит под такие таски.
Удобно, быстро и бесплатно.

Почему такой Dockerfile считается плохой практикой?

FROM alpine
RUN echo "top-secret" > /password.txt
RUN rm /password.txt

Один слой создает файл, а следующий его удаляет. Если собрать этот образ и затем его запустить, то никаких следов файла password.txt вы не увидите:

vagrant@vagrant:~$ docker run --rm -it sensitive ls /password.txt
ls: /password.txt: No such file or directory

Однако не позволяйте ввести себя в заблуждение — конфиденциальные данные все равно попали в образ. Чтобы убедиться в этом, экспортируйте образ в файл tar с помощью команды docker save и разархивируйте его:

vagrant@vagrant:~$ docker save sensitive > sensitive.tar
vagrant@vagrant:~$ mkdir sensitive
vagrant@vagrant:~$ cd sensitive
vagrant@vagrant:~$ tar -xf ../sensitive.tar
vagrant@vagrant:~/sensitive$ ls
0c247e34f78415b03155dae3d2ec7ed941801aa8aeb3cb4301eab9519302a3b9.json
552e9f7172fe87f322d421aec2b124691cd80edc9ba3fef842b0564e7a86041e
818c5ec07b8ee1d0d3ed6e12875d9d597c210b488e74667a03a58cd43dc9be1a
8e635d6264340a45901f63d2a18ea5bc8c680919e07191e4ef276860952d0399
manifest.json

Где 0c24...json — конфигурация образа.

Конфигурация включает историю команд, выполнявшихся при формировании данного контейнера. Как можно видеть, в данном случае конфиденциальные данные отображаются на шаге выполнения команды echo:

vagrant@vagrant:~/sensitive$ cat 0c247*.json | jq '.history'
[
 {
  "created": "2019-10-21T17:21:42.078618181Z",
  "created_by": "/bin/sh -c #(nop) ADD
 file:fe1f09249227e2da2089afb4d07e16cbf832eeb804120074acd2b8192876cd28 in / "
 },
 {
  "created": "2019-10-21T17:21:42.387111039Z",
  "created_by": "/bin/sh -c #(nop) CMD [\"/bin/sh\"]",
  "empty_layer": true
 },
  {
  "created": "2019-12-16T13:50:43.914972168Z",
  "created_by": "/bin/sh -c echo \"top-secret\" > /password.txt"
 },
 {
  "created": "2019-12-16T13:50:45.085349285Z",
  "created_by": "/bin/sh -c rm /password.txt"
 }
]

Внутри каталога каждого из слоев находится еще один файл tar с содержимым файловой системы на этом слое. Можно легко извлечь файл password.txt

из каталога соответствующего слоя:

vagrant@vagrant:~/sensitive$ tar -xf 55*/layer.tar
vagrant@vagrant:~/sensitive$ cat password.txt
top-secret

Из этого ясно, что, даже если последующий слой и удаляет его, любой файл, когда-либо существовавший на любом из слоев, можно легко получить путем распаковки образа.

Звучит как таск на цтф 🙃️️️️️️
Подробнее можно почитать книгу O’Reily «Безопасность контейнеров»

#docker

Фанатам Саши Малого про его выступление на PHDays (первые 8 минут)

https://youtu.be/Q_0H2yxax0I?si=Zp-pgYg50TzPwDVl&t=7

Менее колхозные варианты поднять свой сервер без белого ip адреса:
- ngrok
- localtunnel
- serveo

Демо: https://www.youtube.com/watch?v=664imIyaK-A

Знали про такой прикол в JS?

j = -9007199254740991000
j === j +1 // true 

Максимальное целое число, которое может быть точно представлено в JavaScript, равно 2^53−1, что соответствует 9007199254740991. Числа, превышающие этот предел, теряют точность. Когда вы пытаетесь добавить 1 к числу, значительно превышающему этот предел, происходит потеря точности, и результат остается прежним.

Где это можно применить? Например, в циклах, где можно контролировать начальное и конечное значение для итераций (например, это одна и та же переменная), тем самым вызвать DoS из-за бесконечного цикла.

#js

https://dzen.ru/b/ZZ08RsNbaSNOES10

В копилку интересных вопросов для собеса

#interview

Вкратце знакомимся с DOM Clobbering.

Шаг 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

1/2

Что можно предложить разрабам вместо .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).

Пример:

<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, '&lt;'),
})

Хук 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 каналы. Мб можно еще телеграмм каналы, но пока не разобрался.
Вот список, который у меня собрался на данный момент.

Прикольный intro в Mobile Security

https://www.youtube.com/watch?v=8377woNhpzI

Intro в client-side уязвимости. Будет полезно знать чуть больше, чем 3 вида XSS и CSRF.

https://wr3dmast3r.gitbook.io/client-side-fundamental

Еще один ИБ-шный roadmap, в этот раз по специальностям на русском языке с материалами.
Так же в ней выделены перспективные специальности на горизонте 3-5 лет. В основном связано с *SecOps направлениями, ML и крипта.

https://cybersecurity-roadmap.ru

Если говорить про санитизацию с использованием объектных моделей, то в контексте запросов к СУБД в голову сразу приходит ORM (Object-Relational Mapping).

Для других подсистем объектная модель обычно реализуется через шаблон проектирования Builder (например java.lang.ProcessBuilder для контекста запросов к ОС). Но что такое этот ваш билдер?

Для лучшего понимания паттернов в особенности билдеров может подойти ресурс https://refactoring.guru/design-patterns/creational-patterns

Host-Only 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 для просмотра.

Как известно Site в контексте браузера это схема и TLD+1 (см. подробнее здесь). Представим, что мы зарегистрированы на ресурсе 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

На meetup’е от koronatech узнал про интересную особенностью Postman — хранение данных, которые через него проходят, на серверах Postman’а в США. Отказ от подобного сбора данных ведет к «окерпичиванию» продукта. Особый интерес к этой особенности стоит обратить внимание компаниям, чьи разрабы/тестировщики активно используют Postman для работы с API.
В качестве альтернативы предложили рассмотреть https://hoppscotch.io/.

AppSec’и koronatech так же приложили руку к развитию данного продукта, закрывая свои потребности и проблемы при его использовании, отправляя MR’ы разработчикам hoppscotch.