Час до начала, остальных пускать будем уже подпитых (шутка)



Или нет 🤣

💸 Как за $2 вскрыть дыру в кешбэке

В Июне одного Ибшника осенило -- "Почему бы не проверить одну бизнес-логику кешбэков и получить небольшую прибыль?" Ниже разбор уязвимости, которая в проекте "X" была скрыта за float64, асинхронным батчем и отсутствием блокировок.

🧠 Суть уязвимости

1. При реальном начислении кешбэка из суммы продукции amount используется math.Floor(pct*100)/100 (с учётом возможных артефактов двоичного представления), а остаток (< 0.01) накапливается в fractionBuffer;

2. Каждую ночь планировщик запускает FlushBuffer(), где применяется math.Round(buffer*100)/100 (округление до ближайшего цента) и деньги переводятся в основной баланс;

3. Пользователь может вручную проверить буфер через вызов RedeemBuffer(), где тоже используется math.Floor и вычитание из буфера без блокировки.

Если вызвать два RedeemBuffer() параллельно на одном и том же пользователе, оба прочтут один и тот же buffer, начислят floor(buffer) и вычтут только один раз, в результате integer-часть оказывается зачисленной дважды.

Опустил транзакции бд

Псевдокот 🥺 для понимания:

type UserAccount struct {
 ID             string
 Balance        float64 // основной баланс в долларах
 fractionBuffer float64 // накопленная дробная часть
}

// начисление кешбэк при покупке
func (ua *UserAccount) ProcessPurchase(amount float64, rate float64) {
 pct := amount * rate
 credited := math.Floor(pct*100) / 100
 ua.Balance += credited
 ua.fractionBuffer += pct - credited
}

func (ua *UserAccount) RedeemBuffer() {
 toCredit := math.Floor(ua.fractionBuffer*100) / 100
 ua.Balance += toCredit
 ua.fractionBuffer -= toCredit
}

func FlushBuffer(all []*UserAccount) {
 for _, ua := range all {
  toCredit := math.Round(ua.fractionBuffer*100) / 100
  ua.Balance += toCredit
  ua.fractionBuffer = 0
 }
}

😈 How to hack?

1. Подготовка тестового окружения
Регистрации фейкового пользователя и эмуляция 40 покупок по $1 при 2.5% кешбэка:
🔵 В результате Balance = $0.80, fractionBuffer = $0.20

2. Параллельный Redeem
Тут можно бурпом обойтись и его параллельной отправкой запросов

3. Сбор и анализ результатов
🔵 Оба запроса вернули успешный 200 OK с credited: 0.20
🔵 Баланс вырос на $0.40 вместо $0.20

4. Проверка остаточных данных
После вызова:
🔵 Balance = 0.80 + 2×0.20 = $1.20
🔵 fractionBuffer = 0.00

🖌 Исправление

Два пункта, которые назовёт любой вайбкодер middle разработчик:
🔵 Отказ от float64 и хранение всего в int64 центах;

Без учета микросервисов и передачи данных в битах по rpc

🔵Блокировка доступа к буферу при RedeemBuffer и FlushBuffer или иные бестпрактис решения

Исправляем псевдокот 🥺, чтоб понималось ещё лучше 💥

type UserAccount struct {
 ID            string
 mu            sync.Mutex
 BalanceCents  int64 // целые центы
 fractionCents int64 // накопленные центы < 100
}

func (ua *UserAccount) ProcessPurchase(amountCents int64, ratePermille int64) {
 ua.mu.Lock()
 defer ua.mu.Unlock()
 pct := amountCents * ratePermille / 1000
 creditedDollars := pct / 100
 ua.BalanceCents += creditedDollars * 100 // конвертация долларов в центы
 ua.fractionCents += pct % 100 // остаток в центах
}

func (ua *UserAccount) RedeemBuffer() {
 ua.mu.Lock()
 defer ua.mu.Unlock()
 toCredit := ua.fractionCents // начисляем все накопленные центы
 ua.BalanceCents += toCredit
 ua.fractionCents = 0 // обнуляем буфер
}

func FlushBuffer(all []*UserAccount) {
 for _, ua := range all {
  ua.mu.Lock()
  ua.BalanceCents += ua.fractionCents // начисляем все накопленные центы
  ua.fractionCents = 0 // обнуляем буфер
  ua.mu.Unlock()
 }
}

🍺 Итоги

Да, не самый классный баг, но всё ради "смари что можно сделать". На всё про всё ушло два доллара (на самом деле 229 рублей, но ради кликбейтного заголовка цены стали в долларах 😏) -- цена большого red bull в пятёрочке у дома (или чебупиццу), от которого и родилась идея пошатать бизнес-логику.

Пупупу x2. Без негатива 💥

💎 Как zero-shot модель помогает мне искать реальные утечки секретов

Всё чаще секреты утекают не из кода, а из внутренних систем типа Confluence, Jira, корпоративных вики и мессенджеров (НЕ МАКСА). Пароли, токены, приватные ключи могут "скрываться" в комментариях, конфигурациях или прошлых версиях страниц. На самом деле, удивительно наблюдать на старые версии страниц, которые не затирают и в которых очень много интересного, но сейчас не об этом. Сегодня пойдет речь не про сам самописный инструмент, т.к. я думаю такое есть уже у всех компаний, а про хайповую тему с ЛЛМ (надеюсь ещё хайповую 👀)

⚙️ Как работает стандартный инструмент

1. Сканирование контента
2. Эвристика/шаблоны/LSP
3. Результат

Но с чем мы сталкиваемся, разбирая выхлоп?

- С проблемами😎

Да, вот и появляется куча FP и структуры, которые нам совершенно не подходят. Вот тут и появляется идея сделать фильтрацию через ИИ. Но упс, а что нам теперь, скармливать все наши данные в нейронку, даже если локальную, то представьте сколько это данных и контекста. Тут нам и приходят на помощь zero-shot модели.

💩 Локальная zero-shot модель

🔵 Используется pipeline("zero-shot-classification") с моделью typeform/mobilebert-uncased-mnli. Я протестировал с 20 различных моделей и остановился на ней.

🤗Ссылка - ТЫК

🔵 Модель решает задачу бинарной классификации: _secret_ vs _non-secret_

🔵 Порог принятия устанавливаем на то, на сколько вы доверяете первоначальному сбору, лучше сделать сбор кучи лишних данных и завысить порог, что позволит нам регулировать баланс точности и полноты

🔵 Финальное решение
- Кандидат признаётся "секретом", если:
- сработало сильное правило или высокая уверенность эвристики, или/и
- zero-shot модель оценила вероятность ≥ порога.

🥲 Зачем добавлять zero-shot

Регулярки и энтропия дают точные, но ограниченные результаты, они видят только то, что явно похоже на известные токены (GitHub, Slack, AWS и т.п.).

Zero-shot модель добавляет гибкость и контекст. Она умеет распознавать скрытые или "словесно замаскированные" секреты, например, когда пароль указан в тексте без префиксов или когда он указан как тестовый (ага, те самые тестовые пароли, идущие в прод 🧠)

В итоге, снижается число ложных срабатываний, не теряя полноты и без проблем с ложным информированием о тестовых данных.

↗️ О точности и оценке
Рекомендация простая - создать небольшой «золотой» набор размеченных страниц и посчитать precision / recall / F1 до и после включения пост-верификации.

На практике zero-shot модель даёт заметный прирост точности без серьёзной потери полноты при корректной настройке порога (на тестах мне удалось достичь точности определения валидного секрета, с отсеиванием тестовых и фп в 98.4%)

🖌Практические советы, после болезненных тестов и бессоных ночей
🟢 Расширяйте сигнатуры - это улучшает охват.
🟢 Подбирайте пороги:
🔘 ⬆️ повышает точность
🔘 ⬇️ повышает полноту
🟢Для LLM-валидации держите temperature=0 и контролируйте JSON-ответ.
🟢 Сохраняйте результаты и метрики, чтобы отслеживать эффект изменений.

⚠️ Ограничения
🟣 Не работает с изображениями и вложениями.
🟣 Большие дампы требуют препроцессинга.
🟣 Высокоэнтропийные, но безопасные строки всё ещё могут вызывать ложные срабатывания, но с меньшей вероятностью (1.99%-5%)

Zero-shot классификация не заменяет ручной контроль, но превращает поиск утечек в управляемый и воспроизводимый процесс, а не в хаотичный ручной grep по страницам. А как итог, отмечу, что Вы можете достаточно быстро привести ранее затруднительные задачи в ML-powered AppSec и без использования "нанытой видеокарты".

Спасибо за внимание и буду рад, если накидаете моделей на тесты ❤️