💩 Race conditions, также известные как состояние гонки - распространенный тип уязвимости, тесно связанный с недостатками бизнес-логики. Они возникают, когда веб-сайты обрабатывают запросы одновременно без надлежащих мер предосторожности. Это может привести к тому, что несколько разных потоков одновременно взаимодействуют с одними и теми же совместно используемыми данными, в результате чего происходит "столкновение", вызывающее непреднамеренное поведение приложения. Атака на состояние гонки использует тщательно рассчитанные по времени запросы, чтобы вызвать преднамеренные коллизии и использовать это непреднамеренное поведение в целях атакующего.
💩Тип:
Web, Server-Side.
В целом можно поделить на:
- 💩Классические - используются в приложениях, работающих на HTTP первой версии. Одна из наиболее популярных технологий здесь - Last-Byte Sync (некая синхронизация запросов, чтобы они выполнились одновременно). Трудновыполнимо и практически неэксплуатируемо в современных приложениях.
- 💩HTTP/2 Race Condition - используются в приложениях, работающих на HTTP второй версии. Относительно новая технология, опубликованная Portswigger почти год назад. В свое время произвела революцию в атаках такого типа, сделав возможным эксплуатацию практически любого приложения, работающего на HTTP/2. Основная фишка в том, что ввиду особенности протокола несколько запросов отправляются в рамках одного пакета. Вполне встречаемо и экслуатируемо в реальных приложениях.
💩Влияние:
Самое разнообразное, сильно зависит от логики приложения. В наиболее интересных (но крайне редких) кейсах может привести к удаленному исполнению кода (RCE). Чаще всего может использоваться для обхода блокировок и логики (например, множественный перевод денег с карты банка).
💩Как защититься?
Единственного правильного ответа, думаю, что нет - отследить и поправить все места довольно сложно, однако, есть несколько практик разработки, которые могут помочь:
- 💩Избегать смешивания данных из разных источников
- 💩Использовать атомарные изменения состояний для чувствительных конечных точек (меньше параллелизма)
- 💩Использовать ограничения уникальности в БД
- 💩Использовать безопасные фреймворки, поддерживающие согласованность данных
- 💩Если позволяет архитектура, полностью отказаться от состояния на стороне сервера
💩Пример уязвимого кода:
session['userid'] = user.userid
if user.mfa_enabled:
session['enforce_mfa'] = True
# generate and send MFA code to user
# redirect browser to MFA code entry form
Пояснение:
В коде выше присутствует небольшая задержка перед тем, как проверится наличие многофакторной аутентификации у пользователя. В это время будет считаться, что второй фактор не требуется. В таком случае, можно успеть выполнить валидный запрос внутрь приложения, пока необходимость введения второго фактора не будет установлена приложением.
После публикации исследования, упомянутого выше, возможности и частота данных атак сильно возрасли, причем, обоих типов (одна из последних, которую я видел была на HTTP/1.1). Тем не менее, бывает сложно добиться сильного влияния на реальное веб-приложение - для этого может потребоваться много сил и времени (как часто бывает с логическими уязвимостями). Так что, довольно хороший кандидат чтобы находить, защищаться и получать money.
#edu #vuln #web #race
Дискуссия