Вы владелец этого канала? Начните продавать рекламу уже сейчас вместе с pomogach.io
Технологии и IT
Другое
Подписчики
717
Вовлеченность (ER)
13 %
Вы владелец этого канала? Начните продавать рекламу уже сейчас вместе с pomogach.io
+ 24 ч
+1
+ 7 дн
+2
+ 30 дн
+25
Подписчики
717
За 24 часа
+1
За неделю
+2
За месяц
+25
Вовлеченность (ER)
13 %
История канала
загрузка…
Смотреть
Динамика подписчиков
Подписчики
Охват (Просм. поста)
Охват (Просм. 24ч)
Интенсивность публикаций
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Пн
Вт
Ср
Чт
Пт
Сб
Вс
Меньше
Больше
Метрики публикаций
Публикации
0
за день
3
за неделю
23
за месяц
Репосты
0
за день
0
за неделю
0
за месяц
Просмотры на пост
116
за день
119
за неделю
200
за месяц
Данные за последний месяц
Кто рекламировал
1 / 1
Упоминаний
Всего
31
MAX
17
TG
14
Каналов
Всего
15
MAX
13
TG
2
Название, ссылка или ID канала…
ℹ️
| Канал | Публикаций | Подписчиков | Последний пост |
|---|---|---|---|
Похек
[telegram]
|
12 | 17191 | 30.06.26 |
|
Life-Hack - Хакер / Хаки…
[max]
|
1 | 997 | 26.05.26 |
|
Бэкап
[max]
|
1 | 483 | 26.05.26 |
|
ИБ Книга | Библиотека ИБ
[max]
|
1 | 1350 | 26.05.26 |
|
Mr. Robot
[max]
|
1 | 1682 | 26.05.26 |
|
Этичный Хакер
[max]
|
1 | 2440 | 26.05.26 |
|
Серверная Админа | Компь…
[max]
|
1 | 439 | 25.05.26 |
Кого рекламировал
1 / 1
Упоминаний
Всего
14
MAX
13
TG
1
Каналов
Всего
10
MAX
9
TG
1
Название, ссылка или ID канала…
ℹ️
| Канал | Публикаций | Подписчиков | Последний пост |
|---|---|---|---|
|
ZeroDay | Кибербезопасно…
[max]
|
3 | 885 | 26.05.26 |
|
Mr. Robot
[max]
|
1 | 1635 | 26.05.26 |
|
Life-Hack - Хакер / Хаки…
[max]
|
1 | 1013 | 26.05.26 |
|
infosec
[max]
|
3 | 833 | 26.05.26 |
|
ИБ Книга | Библиотека ИБ
[max]
|
1 | 1357 | 26.05.26 |
Blue (h/c)at Café
[telegram]
|
1 | 3670 | 08.05.26 |
|
Управление Уязвимостями …
[max]
|
1 | 506 | 01.04.26 |
Эффективность последних рекламных размещений
1 / 1
Загрузка данных...
| Размещенный пост | Текст публиакции | Рекламирующий канал | Просмотры | Просмотры 24 ч | Прирост подписчиков |
|---|
Загрузка данных...
| Размещенный пост | Текст публикации | Рекламируемый канал | Просмотры | Просмотры 24 ч | Прирост подписчиков |
|---|
Динамика просмотров публикаций по часам
1 / 1
| Дата и время публикации | Текст публикации | Рекламируемый канал | Динамика просмотров | Всего просмотров |
|---|---|---|---|---|
| 2026-06-30 21:41:40 | TokenTwin Checker: маленький Burp плагин для BAC/IDOR Посмотрел rootdr-backup/TokenTwin-Checker по коду, не только по README. Это Jython-расширение для Burp Suite: берёт выбранные запросы из контекстного меню, подставляет заголовки разных пользователей и сравнивает ответы по статусу и хэшу тела. Идея простая: быстро прогнать один и тот же endpoint от имени User A/User B/нескольких аккаунтов и подсветить возможный BAC/IDOR, если ответы совпали там, где должны различаться. Качество кода нормальное для однофайлового Burp расширения: поток анализа вынесен отдельно, UI не совсем блокируется, есть Stop, фильтр статических ресурсов, baseline/all-vs-all режимы, POC-viewer и merge cookie через OrderedDict. Но это всё ещё один файл на 1600+ строк с Swing/Jython-кодом, где UI, модель данных, сетевой прогон и экспорт смешаны. Лучше было бы разнести на несколько файлов Что бы я допилил первым: явную UTF-8 запись/чтение JSON и CSV вместо системной кодировки Java, лимит/очистку _msg_store, потому что сейчас полные req/resp могут раздувать размер проекта Burp на длинных сессиях + помним что Бурп всё ещё хреново работает с ОЗУ, валидацию импортируемого JSON и header names/values, чтобы не тащить мусор в buildHttpMessage(), и предкомпиляцию ignore-regex с видимой ошибкой пользователю вместо молчаливого except. Я пока его не потестил, но идея и реализация выглядит вполне рабоче и здраво Из ближайших аналогов могу предложить попробовать errorfiathck/IDOR-Forge или SKILL для ИИ агентов @poxek | @poxek_ai | MAX TokenTwin Checke… | — |
|
98 |
| 2026-06-30 13:35:54 | У многих ИБ-продуктов первая версия получается быстрее, чем первая системная продажа в энтерпрайз Технически команда уже умеет закрывать задачу: сканировать периметр, автоматизировать ИБ-процесс, защищать API, искать утечки или закрывать другой конкретный риск. Есть пилоты, первые клиенты, понятная боль рынка. А дальше начинается не код, а длинная взрослая часть: кто buyer, как пройти закупку, как объяснить риск бизнесу, как упаковать PoC, какие метрики показать ИБ-директору, как не утонуть в кастомных доработках. Поэтому логично, что ФРИИ и Metascan сделали отдельный инвестиционный трек именно для ИБ-команд с готовым B2B-продуктом. Там обещают не просто деньги от 5 до 100 млн рублей, а связку из акселерации, разбора продаж, юнит-экономики, позиционирования и отраслевой экспертизы Metascan. Если у вас уже есть продукт, пилоты или первые продажи, я бы использовал страницу трека как быстрый чек-лист зрелости: проходите ли вы по критериям, есть ли B2B-фокус, подтвержденный спрос и план масштабирования. Ссылка на критерии У многих ИБ-прод… | — |
|
116 |
| 2026-06-29 15:00:23 | Django, pickle и RCE через cache poisoning HackedAlert описал RCE-сценарий для Django 6.0.4: атакующий записывает в Redis/Memcached вредный pickle-объект под ключ сессии, затем отправляет запрос с нужным sessionid, и приложение само достает значение из кэша. Механика реальная: в RedisCache после неудачного int() вызывается pickle.loads(), а PyMemcacheCache по умолчанию использует pymemcache.serde.pickle_serde. Ограничение в другом: это не “любой Django 6.0.4 выполняет код по HTTP”. В официальных release notes 6.0.4 нет RCE по cache backend: там один moderate и четыре low security issue. Для эксплуатации нужен контроль над данными в cache backend: открытый Redis/Memcached, SSRF до внутреннего Redis, боковое перемещение или общий кэш между разными trust zone. Без возможности записать произвольное значение в кэш цепочка не складывается. Риск все равно практичный. Во многих продакшенах Redis считается внутренним сервисом и остается без ACL, TLS и жесткой сетевой изоляции. Тогда кэш перестает быть просто ускорителем: запись в него может стать выполнением кода в процессе Django-приложения. Проверять надо не только версию Django. Смотрите SESSION_ENGINE, CACHES, доступ к Redis/Memcached, разделение кэшей между сервисами и возможность заменить pickle на безопасный serializer для конкретных данных. Обновления нужны, но этот класс риска закрывается архитектурой: изоляцией cache backend, аутентификацией, ACL и запретом общих кэшей между разными уровнями доверия. @poxek | @poxek_ai | MAX Django, pickle и… | — |
|
135 |
| 2026-06-24 14:11:07 | SSTI ❤️ htmlspecialchars() Попался тут интересный проект, в котором нашлась Twig SSTI'ка, до которой, чтобы добраться, нужно обойти несколько ограничений: Удалось её обнаружить после того, как я решил поиграться с шаблонами для почты. Обычная нагрузка {{7*7}} давала по итогу 7*7. Подумав, что это может быть какой-то кривой патч, я вставил нагрузку {{{{7*7}}}} и получил в итоге 49 (никогда не думал, что встречу такой тупизм :D) ! Казалось бы, что это победа, однако если нагрузка сложнее математической операции, например, {{{{['id']|filter('system')}}}}, то ничего не отрабатывало. Поэтому я решил залезть в код и поискать эту чудо-функцию =) Ниже представлен ооочень отдалённый пример кода, чтобы был понятен контекст: <?php require_once 'vendor/autoload.php'; error_reporting(E_ERROR | E_PARSE); class User { public $username; public $secondname; public function __construct($username, $secondname) { $this->username = $username; $this->secondname = $secondname; } } $allowed = ['user.username']; function prepareVars(string $template, array $allowedKeys): string { return preg_replace_callback( '/\{\{(.*?)\}\}/i', //Регулярка для извлечения значения между {{...}} function ($matches) use ($allowedKeys) { $value = trim($matches[1] ?? ''); //Берётся наше значение if (in_array($value, $allowedKeys)) { //Оно скорее всего не подпадает под $allowedKeys return "{{ {$value} | raw }}"; } return htmlspecialchars($value, ENT_QUOTES, 'UTF-8'); //В итоге оно попадает сюда с ENT_QUOTES }, $template ); } $username = $_GET['username'] ?? 'John'; $secondname = $_GET['secondname'] ?? 'Doe'; $user = new User($username, $secondname); $templateInput = $_GET['template'] ?? 'Guest'; $fullTemplate = 'Hello ' . $templateInput; $processedTemplate = prepareVars($fullTemplate, $allowed); $loader = new \Twig\Loader\ArrayLoader([ 'index' => $processedTemplate, ]); $twig = new \Twig\Environment($loader); echo $twig->render('index', ['user' => $user]); Отсюда мы видим причину, почему приходилось использовать 2 пары фигурных скобок, а также новую проблему - htmlspecialchars с ENT_QUOTES. Некоторое время я думал, что с этим делать, так как большинство нагрузок для RCE требуют какие-либо кавычки, а потом до меня дошло: Мне для той же нагрузки {{['id']|filter('system')}} нужно передать именно соответствующие строки, необязательно их передавать в формате с кавычками, можно передать какую-либо доступную переменную, содержащую нужное значение. Например, мы тут видим, что можем использовать поля объекта класса User: через username передать id, а через secondname передать system. По итогу будет что-то типа такого - /?template={{{{[user.username]|filter(user.secondname)}}}}&username=ls&secondname=system. В моём случае приложение было на PHP Symfony, а данные о пользователе передавались не от меня. Ознакомившись с документацией, можно узнать, что нам достаточно проставить необходимые значения в поля пользователя(просто зайти в раздел профиля УЗ и установить нужные значения), а дальше использовать их через {{app.user.*}} уже в Twig в уязвимом разделе. Если же у вас только одно контролируемое значение(например subject), а нужно передать 2 строки в SSTI, то просто в subject пихаем 2 строки вместе: idsystem. А дальше извлекаем их посимвольно: {{{{[subject|slice(0,2)]|filter(subject|slice(-6))}}}} SSTI ❤️ htmlspec… | — |
|
134 |
| 2026-06-24 11:11:07 | SSTI ❤️ htmlspecialchars() Попался тут интересный проект, в котором нашлась Twig SSTI'ка, до которой, чтобы добраться, нужно обойти несколько ограничений: Удалось её обнаружить после того, как я решил поиграться с шаблонами для почты. Обычная нагрузка {{7*7}} давала по итогу 7*7. Подумав, что это может быть какой-то кривой патч, я вставил нагрузку {{{{7*7}}}} и получил в итоге 49 (никогда не думал, что встречу такой тупизм :D) ! Казалось бы, что это победа, однако если нагрузка сложнее математической операции, например, {{{{['id']|filter('system')}}}}, то ничего не отрабатывало. Поэтому я решил залезть в код и поискать эту чудо-функцию =) Ниже представлен ооочень отдалённый пример кода, чтобы был понятен контекст: <?php require_once 'vendor/autoload.php'; error_reporting(E_ERROR | E_PARSE); class User { public $username; public $secondname; public function __construct($username, $secondname) { $this->username = $username; $this->secondname = $secondname; } } $allowed = ['user.username']; function prepareVars(string $template, array $allowedKeys): string { return preg_replace_callback( '/\{\{(.*?)\}\}/i', //Регулярка для извлечения значения между {{...}} function ($matches) use ($allowedKeys) { $value = trim($matches[1] ?? ''); //Берётся наше значение if (in_array($value, $allowedKeys)) { //Оно скорее всего не подпадает под $allowedKeys return "{{ {$value} | raw }}"; } return htmlspecialchars($value, ENT_QUOTES, 'UTF-8'); //В итоге оно попадает сюда с ENT_QUOTES }, $template ); } $username = $_GET['username'] ?? 'John'; $secondname = $_GET['secondname'] ?? 'Doe'; $user = new User($username, $secondname); $templateInput = $_GET['template'] ?? 'Guest'; $fullTemplate = 'Hello ' . $templateInput; $processedTemplate = prepareVars($fullTemplate, $allowed); $loader = new \Twig\Loader\ArrayLoader([ 'index' => $processedTemplate, ]); $twig = new \Twig\Environment($loader); echo $twig->render('index', ['user' => $user]); Отсюда мы видим причину, почему приходилось использовать 2 пары фигурных скобок, а также новую проблему - htmlspecialchars с ENT_QUOTES. Некоторое время я думал, что с этим делать, так как большинство нагрузок для RCE требуют какие-либо кавычки, а потом до меня дошло: Мне для той же нагрузки {{['id']|filter('system')}} нужно передать именно соответствующие строки, необязательно их передавать в формате с кавычками, можно передать какую-либо доступную переменную, содержащую нужное значение. Например, мы тут видим, что можем использовать поля объекта класса User: через username передать id, а через secondname передать system. По итогу будет что-то типа такого - /?template={{{{[user.username]|filter(user.secondname)}}}}&username=ls&secondname=system. В моём случае приложение было на PHP Symfony, а данные о пользователе передавались не от меня. Ознакомившись с документацией, можно узнать, что нам достаточно проставить необходимые значения в поля пользователя(просто зайти в раздел профиля УЗ и установить нужные значения), а дальше использовать их через {{app.user.*}} уже в Twig в уязвимом разделе. Если же у вас только одно контролируемое значение(например subject), а нужно передать 2 строки в SSTI, то просто в subject пихаем 2 строки вместе: idsystem. А дальше извлекаем их посимвольно: {{{{[subject|slice(0,2)]|filter(subject|slice(-6))}}}} SSTI ❤️ htmlspec… | — |
|
116 |
| 2026-06-23 09:10:38 | Продолжение развития данного инструмента)) DeepSecrets 2.0: поиск секретов с контекстом кода DeepSecrets 2.0 — OSS-сканер секретов, который пытается закрыть типичную дыру regex-only подхода: инструмент ищет не просто похожие на ключи строки, а кандидаты в контексте кода. В README заявлены лексинг и парсинг для 500+ языков и форматов, semantic checks по переменным, context-aware entropy и отдельный HashedSecret Engine: можно передать хэши известных продакшен-секретов, а сканер будет искать их открытые значения в коде без хранения исходных секретов в правилах. По опубликованному разбору и README, на SecretBench v2.0 показал 93% recall, 69% precision и 8% false positive rate в scope бенчмарка. Это стоит читать аккуратно: SecretBench сам по себе большой, но любой бенчмарк секретов отражает конкретный корпус, правила разметки и типы утечек. Зато направление полезное: меньше слепого entropy по всему файлу, больше проверки того, что строка действительно похожа на значение опасной переменной или конфигурации. На фоне других OSS-инструментов позиционирование понятное. Gitleaks — зрелый и быстрый дефолт для git history, directory/stdin, pre-commit и SARIF/JSON-отчетов, но его модель в основном regex/entropy. TruffleHog шире по источникам: GitHub/GitLab, Docker, S3, CI, Postman, Jenkins, Hugging Face; его сильная сторона — классификация сотен типов секретов и проверка, живой ли ключ. Yelp detect-secrets удобен там, где нужен enterprise baseline: зафиксировать старый долг, блокировать только новые находки и вручную аудитить baseline. DeepSecrets выглядит как хороший кандидат для второго слоя в CI/CD: после дешевого pre-commit фильтра прогнать семантический скан по репозиторию и выгрузить SARIF в GitHub Security или DefectDojo. Но я бы не заменял им TruffleHog для live-validation и внешних источников: утечка в Docker image, старом форке или S3-бакете не становится менее реальной от того, что ее нет в текущем дереве кода. Источники: DeepSecrets - HackerNoon article @poxek | @poxek_ai | MAX Продолжение разв… | — |
|
204 |
Похожие каналы
Загрузка данных...
| Время | Контент | Подписчиков | Кто ссылался | Просмотры 48ч | Просмотры 24ч |
|---|