Продолжаем узнавать Cookie чуть больше. Сегодня поговорим о «чипсах» в печеньках 🍪

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 не получит доступ к куки с интернет-магазина — чат начнется «с нуля»

Наконец-то прошел сертификацию: 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

Недавно проходил VolgaCTF, в котором я принимал участие в составе команды SiBears 🐻

Попался достаточно интересный таск на SQL-инъекцию, который удалось успешно решить. Решил поделиться размышлениями и ходом действий в решении таска.

🔍 Writeup-SQL-injection-task-VolgaCTF-2025

🔄 🚩 💻Список площадок для оттачивания навыков этичного хакинга, подойдет для тренировок CTF.

😉 Hack The Box

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) 🙃

😉 TryHackMe

Аналог HackTheBox без CTF заданий. Академия в наличии, также присутствует free тариф 😁

😉 PortSwigger

Академия веб пентеста от создателей BurpSuite. Для сдачи экзамена необходима активная подписка на Burp Suite Professional, цена экзамена 99$ 😈

😉 CTFtime

Информацию почти обо всех прошедших и предстоящих CTF соревнованиях можно найти здесь

😉 HackerLab

Русскоязычная площадка 😎. Большое (300+) количество CTF задач в самых различных категориях (web, crypto, rev, pwn, osint и т.д.), в наличии Windows и Linux машины. Есть бесплатный тариф

😉 CryptoHack

Один из лучших ресурсов с задачами по криптографии. Нравится криптография ? Вам сюда, от азов до сложнейших задач

😉 Standoff365

Киберполигон от компании 😎 Positive Technologies. Это виртуальная инфраструктура с реалистичными копиями IT-систем из разных отраслей. Достаточно высокий порог вхождения. Ежегодно проводятся турниры, куда вы можете отобраться со своей командой

😉 TaipanByte CTF

Русскоязычная площадка от ребят из команды TaipanByte, большое кол-во тасков (80+) во всех основных категориях

😉 pwn.college

Образовательная платформа, позволяющая изучать и практиковать основные концепции кибербезопасности. Рассчитана на новичков

😉 Kontra

Appsec тренировки, LLM, owasp top10, owasp api top10, aws top10 и т.д.

😉 Linux Journey

Путешествие в мир Linux, основные команды, лабы, руководства

😉 OverTheWire Bandit

Игра из 34 уровней для изучения Linux

😉 Crackmes

Большое количество (~4000) крякми для изучения. Подойдет реверсерам

😉 Pwnable

Для любителей бинарной эксплуатации (PWN)

😉 Cyber-Ed

Русскоязычная площадка. One task of the month - выкладывают по 1ой CTF задаче в месяц, в этом году планируют 10 заданий в категориях: web, pwn, crypto, reverse, misc и т.д.

😉 Root Me

Огромное (500+) кол-во заданий в самых разных категориях

😉 picoCTF

Площадка с CTF заданиями начального уровня, почти на все задания можно найти райтапы

😉 Exploit Education

ВМ Phoenix для изучения уязвимостей, разработки эксплойтов, отладки программного обеспечения и общих проблем кибербезопасности
Темы - Network programming, Stack overflows, Format string vulnerabilities, Heap overflows

😉 0xf.at

Парольные загадки (ребусы), например, пароль это сумма чисел от 1 до 446, соответственно надо написать простенькую автоматизацию и ввести в поле ввода

😉 Hacker Test

Простенький хакер квест состоящий из 20 уровней

⚠️ P.S. Если вы знаете подобные площадки, лично проверяли и они заслуживают внимания, пишите пожалуйста в бота обратной связи - @wh_feedback_bot

#htb #crackmes #bandit #hacking #ctf #ethical

✈️ Whitehat Lab

Представим ситуацию, у нас реализуется 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.

Web Workers это механизм, который позволяет скрипту выполняться в фоновом потоке, который отделен от основного потока веб-приложения.

Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена.

Web Worker делится на три вида:
• Dedicated workers: используется только одним скриптом
• Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах.
• Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью.

🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker.

🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.

Что будет, если скрестить XSS и CSRF? Получится XSSI.

👁Cross Site Script Inclusion (XSSI) — это техника атаки (или уязвимость), позволяющая злоумышленникам похищать данные определенного типа через origin boundaries (дословно «границы сайта»), путем включения целевых данных с помощью тега SCRIPT в веб-страницу злоумышленника, как показано ниже:

<SCRIPT src="https://target.example.jp/secret"></SCRIPT>

Браузеры исполняют все скрипты, загруженные через тег <script>, в едином глобальном контексте страницы. Это означает, что когда внешний скрипт загружается через <script src="...">, его код выполняется как часть основной страницы, и все объявленные в нём переменные, функции и данные становятся доступны для другого JavaScript-кода на этой странице.

Один из примеров, который мне понравился:

HTTP ответ при посещении URL https://victim.com/service/csvendpoint:

HTTP/1.1 200 OK
Content-Type: text/csv
Content-Disposition: attachment; filename="a.csv"
Content-Length: 13

1,abc,def,ghi

Зловредный код на подконтрольном злоумышленнике ресурсе:

<!--error handler -->
<script>window.onerror = function(err) {alert(err)}</script>
<!--load target CSV -->
<script src="https://victim.com/service/csvendpoint"></script>

В итоге, когда браузер попробует отрендерить CSV как JS-код, это приведет к раскрытию данных злоумышленнику (см. вложенную картинку).

Ресурсы для самостоятельного изучения:
- https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion
- https://www.mbsd.jp/Whitepaper/xssi.pdf
- https://www.scip.ch/en/?labs.20160414