📕 Тройни в сетях

Сегодня не про баги, а про основы, которые многие путают. URI, URL, URN согласно RFC 3986 — в чём разница и зачем это знать пентестеру?

➡️1) URI (Uniform Resource Identifier) — "Унифицированный идентификатор ресурса". Это общий термин для всего, что однозначно идентифицирует ресурс: документ, сервис, изображение, устройство и т.д.

Примеры:
• https://domain.ru/login (это и URI, и URL)
• mailto:[email protected] (URI, но не URL и не URN)
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 (URN, а значит, и URI)

URI включает два основных подтипа:
• URL — указывает местоположение ресурса.
• URN — указывает уникальное имя, но не путь.

Везде, где есть идентификация ресурсов (API, веб-приложения, сетевые протоколы), используются URI. Понимание их структуры помогает находить уязвимости (например, инъекции в схемах "data:", "javascript:" или нестандартных URI).


➡️2) URL (Uniform Resource Locator) — "Унифицированный указатель ресурса". Это частный случай URI, который отвечает на вопросы:
• Где находится ресурс?
• Как к нему обратиться?

Разбор структуры URL:
https://domain.ru:443/api/pay?amount=1000#something
• https:// — схема (протокол) — определяет способ доступа.
• domain.ru — хост (домен или IP) — адрес сервера, где расположен ресурс.
• :443 — порт — необязательный параметр (по умолчанию 80 для HTTP, 443 для HTTPS).
• /api/pay — путь к файлу — указывает на конкретный ресурс на сервере.
• ?amount=1000 — параметр запроса — дополнительные данные для запроса (частая цель для атак).
• #something — якорь — ссылка на определённую часть страницы, которая не передаётся на сервер.

URL является основным вектором для атак, например, IDOR, reflected XSS, SQLi, Open Redirect и т.д.


➡️3) URN (Uniform Resource Name) — "Унифицированное имя ресурса". Это уникальный идентификатор, который не зависит от местоположения. В отличие от URL, URN не указывает, как получить ресурс, а только как его назвать.

Примеры:
urn:isbn:0451450523 — идентификатор книги.
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 — уникальный UUID.
urn:ietf:rfc:2648 — ссылка на RFC-документ.

В корпоративных системах URN могут использоваться для внутренней идентификации (например, в SOAP-сервисах). Также иногда в логах или API встречаются URN вместо URL — важно понимать, что это и как с ними работать.


▎ Итоги
➡️URI — общее понятие, включающее URL и URN, но не ограничивающееся ими (например, mailto:);
➡️URL указывает местоположение ресурса, URN — только его уникальное имя;
➡️Для пентестера URL — основной вектор атак, а URN — источник информации о системе;
➡️В реальных системах бывают гибридные схемы (например, git:// + URN) — это требует отдельного анализа.

Нашли пасхалку?

⚰️ Press F to pay respect

С сегодняшнего дня Microsoft больше не будет поддерживать файлообменник Skype.

Скааааааааайп

📕 Сеньёр-помидор

Нашёл для вас интересный, а самое главное — полезный материал: слитый курс Senior Web Penetration Tester (Hack The Box) за ноябрь 2024 года. На площадке HTB этот курс доступен по годовой подписке стоимостью 1055€.

▎ Содержание курса:
➡️Injection Attacks — Атаки инъекциями;
➡️Introduction to NoSQL Injection — Введение в NoSQL-инъекции;
➡️Attacking Authentication Mechanisms — Атаки на механизмы аутентификации;
➡️Advanced XSS and CSRF Exploitation — Продвинутая эксплуатация XSS и CSRF;
➡️HTTPs-TLS Attacks — Атаки на HTTPS/TLS;
➡️Abusing HTTP Misconfigurations — Абуз ошибочных конфигураций HTTP;
➡️HTTP Attacks — HTTP-атаки;
➡️Blind SQL Injection — Слепые SQL-инъекции;
➡️Intro to Whitebox Pentesting — Введение в тестирование методом белого ящика;
➡️Modern Web Exploitation Techniques — Современные техники эксплуатации веб-уязвимостей;
➡️Introduction to Deserialization Attacks — Введение в атаки на десериализацию;
➡️Whitebox Attacks — Атаки методом белого ящика;
➡️Advanced SQL Injections — Продвинутые SQL-инъекции;
➡️Advanced Deserialization Attacks — Продвинутые атаки на десериализацию;
➡️Parameter Logic Bugs — Логические уязвимости в параметрах.

Архив без вирусов, загружен на облако с моего твинка.

🔗 Ссылка на слитый курс Senior Web Penetration Tester

#материал

🙁 Хейт убивает open-source

Сегодня наткнулся на историю разработчика, который из-за одного токсичного письма решил закрыть свой проект "LDAP Client and Server API for node.js". Репозиторий годами поддерживался на энтузиазме и рефакторился, пока аноним не прислал угрозы из-за "неудобного API".

Open-source держится на людях, которые тратят своё время за бесплатно. Критикуйте конструктивно, предлагайте помощь или просто скажите "спасибо". Если проект заморожен — форкните и доработайте.

🔗 Ссылка на репозиторий GitHub

#github

🗣 Всем привет!

Как вы уже могли заметить, в сторисы канала я скидываю мемы на тему ИБ. Если у вас есть, чем поделиться (желательно на тему offensive в формате видео, но фото тоже приветствуется), присылайте в предложку — @hackerbiker_memes_bot. Самые интересные и приемлемые буду публиковать в сторис канала.

Мемы в формате .exe не присылайте, могу не удержаться

📕 RAD COP на PHD

Пришли небольшим коллективом из круга хакеров на Positive Hack Days. Если хотите познакомиться, обсудить крутые кейсы или просто поболтать за кофе, пишите в личку или в комменты. Будем рады пообщаться!

Пользуясь случаем, хочу сказать, мой хороший коллега на фотке на днях сдал CEH (Certified Ethical Hacker). Если хотите его поздравить с новым сертификатом, то напишите приятные слова в комментариях под его постом, ему будет приятно😁

😈 Ержан, вставай!

Давно не было разбора атак на моих проектах. Время исправляться, есть интересная находка. Впервые на проекте нашёл вектора для DoS-атаки, так еще и первая на практике критическая уязвимость.

Конечные точки API для осуществления денежного перевода на вход в JSON-запросе принимают экспоненциальное значение (1e-1) и обрабатывают её, выдавая в ответе рассчитанную сумму с учётом комиссии. При увеличении количества нулей в экспоненте (1e-100...) возрастает время ответа от сервера. На обычные запросы это ~100 мс, после 300, 1000, 8000 и так далее. Наткнулся на такое значение экспоненты, при котором ответ с сервера я получаю через 60000 мс (стандартное ограничение в некоторых браузерах) с 504 HTTP ошибкой.

Решили с Заказчиком провести более глубокое исследование потенциального DoS под наблюдением за сервером. Выяснилось, что экспонента 1e-100000000 и подобные нагружают сервер до 30% при отправке очередью (при ожидании ответа на каждый запрос), когда в обычном состоянии нагрузка не выше 5%. Физически такое число практически равно нулю, но математически нет. Если код пытается его обрабатывать "честно" (например, переводя в дробь или делая арифметику с высокой точностью), это может создать огромную вычислительную нагрузку. Всё говорит о серьёзной проблеме, учитывая то, что это было проделано лишь с помощью одного устройства. А если это сделать в кооперации с другими устройствами? Нагрузка выйдет куда выше.

▎ Риски:
➡️Отказ в обслуживании: один запрос нагружает сервер до 30%, а координированная атака способна нанести более серьёзный урон;
➡️Финансовые потери: запросы связаны с платёжным API, в случае его отказа возможны сбои в транзакциях пользователей;
➡️Репутационный ущерб: нестабильность сервиса подрывает доверие пользователей.

▎ Рекомендации по устранению уязвимости:
✅Валидация входных данных: запрет экспоненциальной записи;
✅Лимиты на обработку чисел: установка максимальной точности (например, округление до 5 знаков после запятой). Timeout на обработку запроса (например, 1 сек), при которой сервер автоматически будет откидывать запросы, которые обрабатывает более установленного времени;
✅Защита от DoS/DDoS: пропускать не более, например, 100 запросов/мин с одного IP, иметь детекты на атаку с различных IP-адресов и отражать вредоносные запросы на сервер;
✅Мониторинг и логирование: алерты при резком росте нагрузки на CPU, логирование подозрительных запросов.

Снова тот случай, когда недостаточная валидация входных данных может привести к катастрофическим последствиям. Нельзя доверять пользовательскому вводу.

"1e-100000000" — это не число, а таймер до перезагрузки сервера.

#кейс

👨‍💻 Награждение Red Team на Standoff 15