✨Секция для знатоков
В момент глубокого познания SOP, CORS и CSRF, у вас могут возникать теоретические трудности (проще говоря, "затупы") или логические зацикливания, когда вы пытаетесь объяснить самому себе или кому-то другому, почему конкретная полезная нагрузка проходит или, наоборот, не проходит. Я сам часто попадал в такие кроличьи дыры и часами мог смотреть на запрос и ответ перебирая теоретические обоснования. Если вы на этом этапе, вот несколько мыслей, которые вам помогут выбраться:
- 🔗Почему вообще классическая CSRF обходит SOP? - SOP был изобретен для того, чтобы запрещать cross-origin чтение. Он НЕ работает при отправке формы, так как в данном случае вы не делаете чтение данных, а отправляете их.
- 🔗Может ли отправка формы быть "сложным" запросом? - Нет. Отправка формы - это всегда простой запрос - вы просто не сможете отправить форму сложным запросом, потому что функционал отправки формы довольно ограничен и не позволяет этого - в нем есть атрибуты, которые возможно отправить только простым запросом.
- 🔗Уязвимость называется Cross Site Request Forgery. Так как определение site менее жесткое, чем определение origin, то очевидно, что оно обходит ограничения на уровне origin и возможно не только на уровне origin, но и на уровне site.
- 🔗Фан факт - на вебсокеты не действует SOP, значит через них возможно делать Cross-Origin чтение
- 🔗Вы не можете отправить JSON через отправку формы в чистом виде. Но! Много приложений позволит вам отправить json под видом text/plain или подобных "простых" типов
- 🔗SameSite: Strict и Lax возможно обойти
- 🔗Многие браузеры (например Google) автоматически навешивают SameSite: Lax на куку, если у нее не указан данный параметр в приложении, но только через 120 секунд после выпуска этой cookie.
🌟Влияние:
Выполнение запроса от лица жертвы.
🌟Как защититься?
- 🔗Использовать CSRF-токен (есть еще технология Double-Submit Cookie, но лично я считаю это просто вариацией токена)
- 🔗Использовать параметр SameSite для Cookie
- 🔗Анализировать значение заголовка Referrer
На все из способов защиты есть обходы при их недостаточной настройке (или наличии каких-то особенностей в других местах приложения) - и я считаю это одним из самых интересных полей для исследований в этой уязвимости.
В реальных приложениях можно встретить часто, но далеко не всегда от них можно получить реальный импакт и воздействие на целевую систему. В последних исследованиях часто вижу тенденцию использования csrf как звена цепочки высококритичной уязвимости. В ctf встречал данную штуку довольно редко. Если планируете более тесное знакомство с данной уязвимостью - обязательно углубитесь в методы обходов защиты - я прям получил много удовольствия от изучения этого материала.
#edu@hun7_0r_b3_hun73d #vuln@hun7_0r_b3_hun73d #web@hun7_0r_b3_hun73d #csrf@hun7_0r_b3_hun73d
Дискуссия