Race Condition в веб-приложениях: три типа уязвимости и как их находить

Для начала разберёмся, что такое Race Condition и почему эта уязвимость заслуживает внимания. Race Condition — это класс уязвимостей, которые возникают из-за того, что сервер обрабатывает несколько запросов одновременно без должной синхронизации. Когда два или более запроса приходят на сервер в один и тот же момент и затрагивают одни и те же данные, между ними происходит коллизия. Результаты такой коллизии могут быть разными — от незначительных багов до критических уязвимостей, которые позволяют обойти проверки безопасности, списать средства дважды, получить доступ к чужому аккаунту или превысить установленные лимиты. Перейдём к тому, какие виды этой уязвимости вообще бывают. Можно выделить 3 вида:

https://habr.com/ru/articles/1044830/

#Race_Condition #гонка_состояний #TOCTOU #веббезопасность #bug_bounty #Burp_Suite #Turbo_Intruder #singlepacket_attack #account_takeover #уязвимости

Реализация Statefull команд в Telegram API

Java Telegram API обманывает разработчиков дубликатами запросов при отключении интернета? Мы команда разработки телеграмм ботов, которая смогла придумать решение для работы с дубликатами в Statefull командах Telegram API используя REST. Прошли путь от наивного решения до работающего продукта.

https://habr.com/ru/articles/1042246/

#telegram_api #telegram_api_manual #telegram_api_request #stateless #statefull #race_condition #идемпотентность #идемпотентность_запросов

Кэширование в Symfony: как мы сломали авторизацию и починили ее через Lock

Привет, Хабр! На связи команда «Исходного Кода». Когда бэкенд на Symfony начинает тормозить, одним из первых инструментов оптимизации почти всегда становится кэширование. И это логично: правильно настроенный кэш круто снижает нагрузку на базу данных, режет latency API и убирает лишние ресурсоемкие операции внутри приложения. Но на практике мы редко ограничиваемся простым cache->get() и базовым TTL, особенно когда приложение крутится не на одном сервере, а в Kubernetes-кластере с пачкой внешних API и жесткой конкуренцией запросов. В таких условиях кэш - это уже не только про скорость, но и про синхронизацию состояния между процессами и pod'ами.

https://habr.com/ru/articles/1040522/

#Symfony_Lock #Symfony_Cache #JWT_кэширование #race_condition #distributed_lock #Memcached #401_Unauthorized #doublecheck

Idempotency keys: 5 граблей, которые мы поймали на проде

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку. Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

https://habr.com/ru/articles/1039860/

#идемпотентность #idempotency #платежи #распределённые_системы #NET #C# #API #intentkey #race_condition #грабли

Reactive Programming не спасёт вас. Если вы не решили эти 5 проблем — у вас просто медленный монолит с Flux

Нагрузочный тест. 10 000 событий в секунду, три инстанса сервиса, Spring WebFlux, Project Reactor — всё как по учебнику. Смотрю на метрики. Event loop завис на 800 миллисекунд. В хранилище — данные за более позднее время перезаписаны более ранними. WebSocket-сессия потеряла сообщения под нагрузкой. Два из трёх инстансов не получают события. Код написан на WebFlux. Но реактивности в нём не было. Я строил сервис потоковой доставки данных в реальном времени: тысячи источников → обработка → тысячи WebSocket-подписчиков. Каждая из пяти проблем ниже была невидима на демо. Каждая проявилась под нагрузкой. И каждая из них — не баг фреймворка. Это паттерны которые нужно знать заранее. Узнать личный опыт

https://habr.com/ru/articles/1039618/

#webflux #websocket #java #latency #deadlocks #race_condition #flux #redis #kafka_apache #async

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

https://habr.com/ru/articles/1031010/

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

https://habr.com/ru/articles/1024868/

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

https://habr.com/ru/articles/1013866/

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Когда ошибка становится наставником: почему баги прошлого нередко полезнее любого чек-листа

Каждый разработчик хотя бы раз в жизни сталкивался с ситуацией, когда баг, который вроде бы уже исправлен, неожиданно возвращался в продакшен. В этой статье я расскажу о тех случаях, когда ошибки служили для меня не провалом, а очень настойчивым, но полезным учителем. Да, иногда именно они объясняют архитектуру, принцип работы систем или забытый corner case лучше самых толстых документаций. Эта статья не учит идеализму — наоборот, она про то, как ценить несовершенство.

https://habr.com/ru/articles/972944/

#ошибка #баг #отладка #архитектура #опыт_разработчика #race_condition #обработка_данных #очереди #продакшен #надежность