Недавно проходил 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="http://target.example.jp/secret"></SCRIPT>

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

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

HTTP ответ при посещении URL http://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 -->
<noscript>window.onerror = function(err) {alert(err)}</noscript>
<!--load target CSV -->
<noscript src="http://victim.com/service/csvendpoint"></noscript>

В итоге, когда браузер попробует отрендерить 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