180к MAU, 43% детей и „филькина грамота“: как я искал уязвимости, а нашёл бизнес-схему

Страницы:  1

Ответить
 

Professor Seleznov


или Матрица: Мнимая Безопасность, где Нео — я, а агент Смит — разраб
-
TL;DR
За 2 дня исследований я нашёл критические уязвимости в российском дейтинг-боте Mimolet, которые позволили собрать 12 340 анкет без особых усилий. Всего выкачано 23 999 медиафайлов (22 415 фото + 1 584 видео) общим объёмом 7 GB.
Я в этой истории — Нео (0xItsss, TG), разраб — Мистер Смит (его TG: @kuroplas2). Пока он писал в своём канале «Мамен хакер или их несколько спамили запросами…», я спокойно выкачивал базу через IDOR и отрицательные оффсеты.
-
Оглавление
  • Вступление: Neo vs Mr. Smith
  • Первая находка: IDOR и профили без авторизации
  • Токены лайков: Хэш проверяется, но это не спасает
  • Премиум-иллюзия: обход подписки через profile_view.php
  • PHPSESSID: Работает даже для забаненных
  • S3 бакеты: Фото всех и каждого
  • Скрейпим 12к профилей за 2 дня
  • Разраб паникует: «Хакер нас дудосит!»
  • Костыли: abuse_ban и почему они не работают
  • Архитектура: ISP Manager и test.php
  • Бизнес-схема: 180k MAU vs ? реальных
  • Несовершеннолетние: 43% базы — дети
  • Технический анализ: CVSS и бизнес-импакт
  • Выводы: Что делать Мистеру Смиту
  • Disclaimer и этика

-
1. Вступление: Neo vs Mr. Smith
«I know kung fu… and IDOR too» — 0xItsss
Всё началось как в Матрице: пришло сообщение от друга с ссылкой на бота, я зашел, увидел косяки и понял — «что-то здесь не так». Регистрируюсь, смотрю запросы через DevTools.
Буквально через 5 минут после регистрации я уже вижу три красных флага: профили доступны в обход ленты (чистый IDOR), токены действий проверяют хэш, но это не мешает эксплуатации, а PHPSESSID работает даже для забаненных аккаунтов. Может ли все быть здесь настолько плохим? Как выяснилось — может!
-
2. Первая находка: IDOR и профили без авторизации
Что такое IDOR? Простыми словами: ты просто идешь по коридору отеля и пробуешь повернуть ручки всех дверей подряд. Если дверь открылась лишь потому, что ты на нее «нажал» (ввел ID) — это и есть IDOR. Как в Матрице: «There is no spoon», а тут «There is no auth».
Изначально эндпойнт /back/profile/profile_view.php?tg_id=N предназначался для показа анкет из «Топа», но если подставить туда tg_id анкеты, которой нет в топе, то — о, чудо! Мы получили нужную нам анкету.
GET https://mimoletbot.ru/back/profile/profile_view.php?tg_id=8475284832
Response: 200 OK — полный профиль с фото, именем, возрастом
pic
Получаем любую анкету по ее ID
Запрос работает без токенов, без рейт-лимита, нужна лишь валидная сессия (PHPSESSID). Любой, кто знает Telegram ID, может посмотреть профиль любого пользователя. А если ID можно перебрать? Значит, можно собрать базу всех анкет за пару дней. Использовать для сталкинга, сбора данных или просто развлечения.
Какая же это «администрация» у сервиса, если через profile_view.php?tg_id=N пользователь видит все? «Юзернейм Telegram передается только в случае совпадения интересов (матча)» — именно так сказано в Политике Конфиденциальности сервиса. Вопрос Мистеру Смиту: чем же отличается юзернейм от tg_id? Бумажная угроза вместо защиты в коде: первый звоночек того, как здесь относятся к безопасности. Возникает мысль: а что если этот сервис — иллюзия надежности, где документы пишутся для галочки, а в реальности все по-другому?
Но это только начало — дальше интереснее.
-
3. Токены лайков: хэш проверяется, но это не спасает
Структура токена действия: base64(v1|my_id|user_id|ts+2h).sha256_hash. Изначально казалось, что action_token — это защита. Важно: он нужен только для действий (лайк/дизлайк/жалоба), для просмотра профилей не требуется. На деле же: хэш проверяется на сервере, токен не вечен, но для IDOR через profile_view.php?tg_id=N токен не нужен вовсе.
В боте «присутствует» ограничение на просмотр анкет, пользователь «может» посмотреть лишь 60 анкет в день. Но выяснилось следующее: просмотры безлимитны, а действия «ограничены». Впрочем, у меня получилось совершить 98 действий путем race condition. О чудесном стеке без Redis’а вы узнаете позже.
pic
Запросы уходят за лимиты
Внезапно приходит осознание: ранее я считал, что action_token обязателен для лайков. Но на самом деле, лайки можно ставить и через ранее выявленный IDOR profile_view.php БЕЗ action_token.
# Лайки идут мимо токена, и даже мимо анкет в ленте:
POST /back/profile/profile_view.php?tg_id=TARGET_ID
- Content-Type: multipart/form-data
- body: ajax=1&action=like&profile_id=TARGET_ID
- Cookie: PHPSESSID=valid_session # action_token НЕ нужен!
Токены для действий действительно проверяются в feed_classic_api.php, но это не мешает эксплуатации других эндпоинтов. Ведь PHPSESSID — это отдельная история.
-
4. Премиум-иллюзия: обход подписки через profile_view.php
В интерфейсе бота стоит жесткий барьер: нельзя ответить лайком пользователям, которые тебя лайкнули — это функция лишь для премиум-подписки. А работает ли это ограничение на уровне API, а не только JS в интерфейсе?
При попытке лайкнуть пользователя из вкладки “Кто меня лайкнул” без подписки, UI бота навязывает премиум-подписку… Но Charles Proxy показал ранее, что запросы на лайк можно отправить на эндпоинт profile_view.php, а не на feed_classic_api.php. Если этот эндпоинт принимает лайки напрямую, значит система проверки наличия подписки работает только на клиенте. Блюр фото в лайках реализован смешным образом на фронте, а ID пользователя доступен из ссылки на S3.
pic
Получаем ID лайкнувшего пользователя
POST /back/profile/profile_view.php?tg_id=8475284832 HTTP/1.1
Host: mimoletbot.ru
Content-Type: multipart/form-data; boundary=----FormBoundary
Multipart:
ajax: 1
action: like
profile_id: 8475284832
Как видим вновь — никакого action_token не требуется! Получается, action_token — это действительно бесполезная вещь. Разраб думал, что защитил действия токенами, но лайки/дизлайки можно отправить через profile_view.php без токенов.
Почему разраб считал токены защитой, если критические действия проходят без них? Проверка action_token реализована только в feed_classic_api.php, но лайки аналогично обрабатываются и в profile_view.php, где токен вообще не нужен. Это классическая ошибка — дублирование логики действий на разных эндпоинтах с разным уровнем безопасности. Система безопасности тут имитируется, создавая иллюзию защиты.
Разраб даже не видит эти запросы в логах, для него это «продвижение сервиса», а для нас — бесплатный обход премиум-подписки. Закрадывается подозрение, что весь бизнес построен на иллюзии: иллюзия защиты, иллюзия контроля, иллюзия премиум-функций. Если пользователи платят за то, что можно обойти одним POST-запросом — это не бизнес-модель, это сбор денег с наивных пользователей.
-
5. PHPSESSID: Работает даже для забаненных
Сессия PHPSESSID работает даже если аккаунт забанен! Эксперимент простой: получаю бан на свой акк, но сессия остается валидной и продолжает работать в profile_view.php и feed API. Тесты подтверждают — нужна только валидная сессия:
s = requests.Session()
s.cookies.set("PHPSESSID", "valid_or_banned_session_id")
# Работает даже если аккаунт забанен:
# 1. Просмотр профилей через profile_view.php?tg_id=N
# 2. Получение карточек через feed API (bootstrap/next_card)
# 3. Отправка сообщений
При бане анкеты сервер все равно выполняет авторизацию через Telegram, выдает сессию, и позже отправляет пользователя на ban.php (который всегда возвращает HTTP 500). В запросе содержится сессия. Валидная сессия. Выходит, бан фиктивный.
pic
Сессия все еще валидна
Небольшой трюк с Charles Proxy: открываешь TMA 5 раз, перехватываешь запросы и получаешь 5 разных валидных PHPSESSID, при этом все пять работают одновременно !
Все сессии не привязаны к IP! Если бы они реализовывали базовую защиту, сессия PHPSESSID должна была бы проверять $_SERVER['REMOTE_ADDR']. Но нет — сессия жива даже после бана анкеты, и IP не имеет никакого значения.
Это серьезная уязвимость. Сессия — это ключ ко всему сервису, и если она не привязана к чему-то уникальному (IP, User-Agent, device fingerprint), то любой, у кого есть этот ключ, может войти. Представьте, что ваш дом открывается любым ключом, который когда-либо подходил к двери — это и есть PHPSESSID в Mimolet. Разраб явно не читал OWASP Top 10.
Как это исправить? Нужна регенерация сессии при бане и привязка к IP:
session_regenerate_id(true);
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
if ($_SESSION['ip'] !== $_SERVER['REMOTE_ADDR']) {
session_destroy();
http_response_code(403);
}
// + флаги безопасности: lifetime 30 мин, secure и пр.!
Реакция разраба на мои трюки в его сервисе? Позже он добавил abuse_ban, который представляет собой rate-limit с запретом получения новой сессии. Но это костыль: сессия все еще жива некоторое время, можно позже сгенерировать новую через TMA, а оффсет-трюк (читайте дальше!) все равно работает.
-
6. S3 бакеты: Фото всех и каждого
Исследуя структуру фронта, я наткнулся на предсказуемый шаблон: https://s3.regru.cloud/mimoletpublic/photos/{telegram_id}/{telegram_id}_{hash}.jpg. А если перебрать tg_id, можно получить все ссылки на фото этих ID? Бакет оказался публичным — никакой авторизации, никаких presigned URLs. Доступны все фото и видео без ограничений.
Статистика из дампа впечатляет: 23 999 медиафайлов. И что самое страшное — эти ссылки встречаются в лайках, которые я перехватывал через Charles Proxy. Получается, зная tg_id из лайка, можно сразу качать медиа.
Публичный S3 — это очередная уязвимость. Фотографии пользователей, включая несовершеннолетних, лежат в открытом доступе с постоянными ссылками. Любой, кто знает tg_id (а их можно перебрать через IDOR), может скачать всё. Это нарушение не только ФЗ-152, но и базового доверия пользователей. Почему разраб выбрал regru.cloud и не настроил права доступа? Скорее всего, экономия на безопасности ради снижения затрат — стандартная ошибка стартапов, которые ставят скорость разработки выше безопасности данных.
-
7. Скрейпим 12к профилей за 2 дня
Логика скрейпинга проста: используем action=bootstrap в feed_classic_api.php (оффсет 0) для первой загрузки, а потом декремент оффсета (-1, -2, -3…) через action=next_card. Это и есть тот самый «оффсет-трюк», который разраб не заметил.
pic
API отлично принимает отрицальные оффсеты
Скрипт mimolet_scrapper.py. Пример (ваш сессия вставляется в YOUR_SESSION_ID_HERE):
#!/usr/bin/env python3
import json, time, requests
from tqdm import tqdm
BASE_URL = "https://mimoletbot.ru"
session = requests.Session()
session.cookies.set("PHPSESSID", "YOUR_SESSION_ID_HERE")
def fetch_next(offset: int) -> dict:
payload = {"action": "next_card", "swipe_offset": offset}
r = session.post(f"{BASE_URL}/back/api/feed_classic_api.php",
data=payload, timeout=10)
if r.status_code != 200:
raise RuntimeError(f"Bad status {r.status_code}")
return r.json()
def scrape(limit: int = 13000) -> list:
profiles = []
offset = 0
pbar = tqdm(total=limit, desc="Scraping")
while len(profiles) < limit:
try:
batch = fetch_next(offset)
except Exception as e:
print("[!] error:", e)
break
if not batch.get("cards"):
break
profiles.extend(batch["cards"])
offset -= len(batch["cards"]) # отрицательный трюк
pbar.update(len(batch["cards"]))
time.sleep(0.08)
pbar.close()
return profiles[:limit]
if __name__ == "__main__":
data = scrape(limit=1000)
with open("dump.json", "w", encoding="utf-8") as f:
json.dump(data, f, ensure_ascii=False, indent=2)
print(f"\n✅ Сохранено {len(data)} профилей в dump.json")
Результат говорит сам за себя: из файла dumpSummary.txt мы видим 12 340 анкет, 22 415 фото, 1 584 видео. Всего 23 999 медиафайлов на 7 GB. Цифры пугающие, особенно на фоне того, что разраб считал это DDoS-атакой.
Скрейпинг показал полную доступность базы. Каждый профиль, каждое фото — все доступно за пару дней работы одного человека. Возникает вопрос: а сколько ещё таких «исследователей» уже скачали эту базу? Если я смог это сделать за 2 дня, то кто-то с большими ресурсами мог собрать все за несколько часов. И самое страшное: 43% этой базы — дети, чьи данные теперь гуляют по сети. Разраб, наверное, думает, что если он не видит атаки в логах, то ее нет, но реальность такова, что данные уже утекли.
-
8. Разраб паникует: «Хакер нас дудосит!»
Пока я методично собирал базу, разраб начал замечать странности.
Timeline его паники — классический:
  • День 0 — я направил репорт в поддержку.
  • День 1 — я пробую качать анкеты.
  • День 2 — он заметил нагрузку и подумал DDoS. Вечером 2-го Дня в канале появляется пост Mr. Smith: «Мамен хакер или их несколько спамили запросами…».
  • День 3 — я продолжал качать, а он забанил мне IP.
pic
Нас дудосят
Но все просто: это был не DDoS, а обычный скрейпинг через IDOR и оффсеты. Сервер не выдержал 1000 запросов в минуту только потому, что нет rate limiting. К слову, в чате канала Мистера Смита постоянно мелькают комментарии «Мимолет не работает» и пр. Если сервер падает от нормального скрейпинга, значит, в нем нет базовых защитных слоёв. Костыли тут уже не помогут.
-
9. Костыли: abuse_ban и почему они не работают
Разраб попытался лечить симптомы, а не болезнь. Добавил abuse_ban, который отзывает PHPSESSID при бане. Оффсет-трюк всё ещё работает — можно получать профили через swipe_offset=-N. IDOR жив — профили доступны каждому. S3 бакет всё ещё публичный, фото доступны всем. Полноценный rate limiting так и не внедрили.
pic
Костыль abuse_ban
Итог печальный: костыль закрыл одну дыру, но оставил остальные. Как в Матрице: «Система несовершенна, Нео». А что же там с архитектурой вообще?
-
10. Архитектура: ISP Manager и test.php
Заглянув поглубже в инфраструктуру через nmap и gobuster, я увидел две панельки: ISP Manager (основная) и Plesk Obsidian на другом сервере. Разраб смотрит запросы через дашборд, но явно не понимает уязвимости — если бы понял про отрицательные оффсеты, наверное, статьи бы не было…
Но самое интересное — файл test.php (Mimolet media dependency test), который разраб забыл удалить. Этот файл диагностики раскрывает серверные детали: PHP 8.3.6, путь /var/www/www-root/data/www/mimoletbot.ru/, установленные пакеты aws-sdk-php 3.371.3, ffmpeg 6.1.1 и пр. + наличие shell_exec(). В самом файле даже есть примечание: “Delete this file after checking the VPS, because public diagnostics reveal server details.”
Файл сохранен в архив, желающие изучить детальнее могут найти ссылку в конце статьи.
Ирония в том, что именно благодаря test.php я восстановил архитектуру за 30 минут. «Но в чем заключается бизнес разраба?» — переходим к следующему этапу.
-
11. Бизнес-схема: 180k MAU vs X реальных
Глядя на лендинг mimolet.site (домен которого стоит смешные 200 руб/год для проекта с 180k MAU), сразу возникает мысль: «А где подвох?». Политики конфиденциальности нет, только «заметка о данных» в стиле ChatGPT.
Копаем глубже: платежный агрегатор — ООО «Дейтинг», контора зарегистрирована в Орле. Разраб живёт в Москве, официально не трудоустроен в ООО. Деньги от рекламодателей идут «мимо кассы», а рекламодателям показывают 180k MAU. В боте же максимум 40k профилей!
При онбординге в боте требуется подписаться на канал разработчика. В канале разработчика всего 42k подписчиков. Откуда же 180k MAU в описании бота?!
Вывод очевиден: вероятен обман рекламодателей через фейковую статистику. Сначала накручивают цифры MAU, потом привлекают рекламодателей, получают деньги на «левые» счета и специально игнорируют безопасность: она мешает всей схеме.
Использование ООО «Дейтинг» в Орле при разработке в Москве — это не юридическая тонкость, это способ уйти от налогов и ответственности. Если проект в Москве, а юрлицо в Орле, то проверки Роскомнадзора и ФНС будут идти по ложному следу. Разраб прекрасно понимает это, поэтому документы пишутся «для галочки». Безопасность здесь не просто игнорируется, она намеренно ослабляется, чтобы данные были доступны для «продвижения сервиса», то есть для продажи рекламодателям под видом «активных пользователей».
-
12. Несовершеннолетние: 43% базы — дети
Статистика из dumpSummary.txt шокирует: 1 324 ребёнка 10-14 лет и 6 684 подростка 15-19 лет. Посчитав, выходит ~5 382 (43.6%) пользователей младше 18 лет! На сайте заявлено «18+», в документах «только для 16+», а по факту — почти половина базы дети. Верификации возраста — нет, проверки паспорта — тоже нет.
Это уже не опечатка, это преступная халатность. Платформа, которая позиционирует себя как dating-сервис для взрослых, на 43% состоит из детей. Реальный кейс: 14-летняя девочка регистрируется, загружает фото в бикини — и 30-летний мужик видит её через IDOR. Где ответственность платформы, которая не проверяет возраст, но собирает данные детей?
pic
Статистика дампа
Вектор атаки на несовершеннолетнего примитивен до безобразия. Сначала получаем tg_id через IDOR-перебор или через вкладку «Лайки» — перехват запросов через Charles Proxy показывает ссылки на S3-медиа вида https://s3.regru.cloud/mimoletpublic/photos/{tg_id}/{tg_id}_{hash}.jpg. Зная tg_id, через funstat или telelog мгновенно получаем username жертвы. Дальше злоумышленник пишет напрямую в Telegram, а жертва даже не подозревает об утечке через данный сервис.
Самое аморальное, что разраб об этом знает. Если бы он проверял базу, он бы увидел возраст пользователей. Но ему выгодно, чтобы база была большой — для рекламодателей 180k MAU выглядят круче, чем ~40k реальных, из которых 43% дети. Безопасность детей не приоритетна, приоритет — цифры для инвесторов.
-
13. Технический анализ: CVSS и бизнес-импакт
Сводная таблица уязвимостей показывает масштаб беды. IDOR (7.5 High) даёт доступ к профилям и утечку ПД. Public S3 Bucket (8.9 High) — это нарушение ФЗ-152 с утечкой фото несовершеннолетних. No Rate Limiting плюс отрицательные оффсеты (8.1 High) приводят к росту трафика и отключению сервиса. Session Fixation (8.1 High) позволяет иметь доступ к базе даже для забаненных.
# Уязвимость CVSS v3.1 Severity Пример бизнес-ущерба
1 IDOR — доступ к профилям 7.5 High Утечка ПД, репутационный риск
2 Public S3 Bucket 8.9 High Нарушение ФЗ-152, утечка фото несовершеннолетних
3 No Rate Limiting + отрицательные оффсеты 8.1 High Рост трафика → отключение сервиса
4 Session Fixation (PHPSESSID жив после бана) 8.1 High Доступ к базе даже для забаненных

Бизнес-импакт изумляет.
  • Репутация: 🔴 Critical — СМИ напишут о «детских фото в открытом доступе», пользователи массово уйдут.
  • Юридическая: 🔴 Critical — штрафы по ФЗ-152, возможно уголовное дело (ст. 242 УК РФ).
  • Финансы: 🟠 High — потеря рекламодателей и блокировка платежных шлюзов.
  • Техническая часть: 🟡 Medium — частично реализован rate-limiting и abuse_ban, но работают некорректно.
  • Операционная: 🟡 Medium — команду надо переобучать, внедрять процесс security-review.
Что делать Мистеру Смиту?
-
14. Выводы: Что делать Мистеру Смиту
Срочно, пока крах Матрицы не наступил окончательно, нужно закрывать дыры. Самое критичное — IDOR: проверяйте в profile_view.php, что tg_id принадлежит списку Топов, иначе любой пользователь будет смотреть чужие анкеты. Код проверки прост, но его отсутствие — критично.
Дальше — закрывайте лайки без токена. Нужно запретить обработку action в profile_view.php и перенести только в feed_classic_api.php с полноценной проверкой action_token, о которой разраб так мечтал, но забыл реализовать везде.
Третий шаг — приватный S3: используйте UUID + presigned URLs с TTL ≤ 5 минут, чтобы фотки не валялись в открытом доступе. Ссылка не должна содержать чувствительную информацию.
Четвёртое — rate limiting. Ограничьте запросы (макс. 30 req/мин/IP), иначе любой школьник положит сервер скрейпингом, а разраб снова побежит писать в канал про DDoS.
Пятое — валидация оффсетов: отрицательные swipe_offset — это не фича, это баг, который позволяет мотать ленту в обратную сторону. И шестое — верификация возраста: проверка паспорта для <18 должна быть обязательной, иначе 43% базы — это мины замедленного действия, готовые рвануть по статье 242 УК РФ.
В долгосрочной перспективе — удалите test.php, он раскрывает серверные детали. Наймите security-инженера (или хотя бы почитайте OWASP Top 10). Сделайте нормальную политику конфиденциальности (сами, а не через текстогенератор), внедрите CI/CD с SAST/DAST (GitLab CI, SonarQube) и запустите приватный bug-bounty (минимум $500 за CVE-рекомендацию). От себя советую перейти на TDD, тем более если пользуетесь ИИ. Не давайте говнокоду дойти до прода, как уже случилось. Используйте fwknop на серверах, и закройте лишние порты.
И самое главное — приведите документы в соответствие с реальностью. Сейчас это не просто бумажные ошибки, а преднамеренное введение пользователей в заблуждение. Если вы пишете «данные на защищенных серверах», а храните их в публичном S3 — это обман. Если заявляете «16+», а половина базы — дети: это преступная халатность.
Документы здесь не для защиты пользователей, а для юридического прикрытия. Когда придут проверяющие из Роскомнадзора, разраб сможет сослаться на «наличие политики конфиденциальности» и формально закрыть вопрос, но реальная защита данных от этого не появится. Чтобы исправить ситуацию, нужно менять не тексты документов, а саму культуру разработки: перестать создавать иллюзию безопасности и начать реализовывать защиту на всех уровнях.
Если в child-safety.php написано «сервис только для 16+», то очистите базу от 43% детей (5 382 чел.). Не ждите, пока случится трагедия с участием несовершеннолетних — это ваша прямая ответственность как владельца сервиса. Если в privacy.html пишете «данные хранятся на защищенных серверах», то немедленно закройте публичный S3 бакет mimoletpublic и перейдите на presigned URLs + UUID ссылки.
Система несовершенна, Мистер Смит, но её можно починить — если вы действительно этого хотите.
-
15. Disclaimer и этика
«Все исследования проводились через публичные интерфейсы. Я не использовал эксплойты, не удалял данные и не шантажировал разраба. Просто показал, как плохая безопасность может разрушить бизнес.»
Ответственное раскрытие — это основа этичного хакинга. Ещё 24.04.2026 я отправил первый репорт об IDOR и публичном S3 в поддержку — без ответа. 26.04.2026 — второй репорт про PHPSESSID и отрицательные оффсеты на почту, снова игнор. 28.04.2026 — третий репорт про обход премиум-подписки через profile_view.php, проигнорирован.
Ни одна запись в базе не менялась и не удалялась. Данные не передавались третьим лицам. В статье только обобщенная статистика, персональные данные (TG ID, ссылки на медиа) не публиковались.
Этика мною соблюдена:
  • ✅ Уведомил разраба (через репорты, которые он игнорировал)
  • ✅ Не публиковал персональные данные
  • ✅ Не использовал украденные данные в корыстных целях
Доказательства: Все ссылки на документы сохранены через Wayback Machine (web.archive.org): Кроме Wayback Machine, весь набор запросов и ответов, приведенных в статье, был зашифрован и подписан с помощью GPG. К файлу создан OpenTimestamp. Он выложен в репозиторий - github. Пароль будет доступен через 3 дня после публикации.
Для пользователей единственный совет: удалите свои данные из Mimolet, не загружайте реальные фото и не доверяйте свои данные сервисам из рекламы, не изучив документы.
-
Автор
0xItsss — Security Researcher
Telegram DM Telegram Channel
Поддержать автора
Если ценишь подобные разборы реальных уязвимостей:
BTC: bc1qnvn2fwkptfw5n7q033gkd38atlntp08s5d2vuh
TRC20: TVNPzo91J7cPv2tZnvHfKyH8HMGzwXQg44
P.S. Mr. Smith, если читаешь это — пиши в личку, помогу исправить другие баги, о которых здесь не написано.-Источник
 
Loading...
Error