Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>CSRF - это уязвимость, при которой злоумышленник вынуждает браузер пользователя отправить запрос на сайт, где он уже авторизован. Внешне всё выглядит так, будто действие выполняет сам пользователь, хотя инициатором является посторонний источник. Механизм принципиально отличается от XSS: здесь вредоносный код<em>не внедряется</em>в страницу, а используется доверие браузера к сохраненной сессии.</p>

2 <h2>Определение и суть механизма</h2>

3 <p>Полное название -<em>cross-site request forgery</em>. Смысл уязвимости в том, что браузер автоматически подставляет cookie, токены сессии и другие данные авторизации при обращении к привычному домену. Если человек одновременно открыт на нескольких сайтах, можно сформировать скрытый запрос к ресурсу, где он уже вошёл в аккаунт.</p>

4 <p>Пример: пользователь аутентифицирован в онлайн-банке, открывает сторонний сайт, а встроенный элемент (например, изображение или невидимая форма) незаметно отправляет запрос на перевод средств.</p>

5 <p>Ключевое условие - пользователь должен быть авторизован, а браузер должен автоматически подставить данные доступа.</p>

6 <h2>Примеры злоумышленного использования</h2>

7 <h3>Подмена форм</h3>

8 <p>Сторонний сайт может незаметно загрузить HTML-форму, которая отправляется автоматически. Пользователь ничего не нажимает, но операция выполняется.</p>

9 <h3>Использование cookie-сессии</h3>

10 <p>Поскольку браузер доверяет домену, он автоматически прикрепляет сессионные файлы. Это позволяет выполнить нежелательное действие: изменить настройки профиля, отправить сообщение, добавить новый адрес доставки и т. д.</p>

11 <h3>Реальные кейсы</h3>

12 <ul><li>попытка изменить email в профиле без ведома хозяина аккаунта;</li>

13 <li>создание публикации или комментария на площадке, где пользователь авторизован;</li>

14 <li>активация действий в панели администратора при работе в нескольких вкладках.</li>

15 </ul><p>Такие ситуации происходили в блог-платформах, старых движках интернет-магазинов, сервисах с откровенно слабой защитой.</p>

16 <h2>Механизмы защиты</h2>

17 <p>Современные сайты используют сразу несколько уровней защиты - они дополняют друг друга, минимизируя риск несанкционированного запроса.</p>

18 <h3>CSRF-токены</h3>

19 <p>Каждая форма или важный запрос получает уникальный одноразовый маркер. Он сохраняется в сессии пользователя и передается вместе с запросом. Если маркер не совпадает, действие блокируется.</p>

20 <h3>Double Submit Cookies</h3>

21 <p>Принцип в том, что токен хранится одновременно в cookie и в теле запроса. Сторонний сайт не может прочитать cookie из-за ограничения доменов, поэтому не может корректно сгенерировать пару значений.</p>

22 <h3>SameSite</h3>

23 <p>Атрибут cookie, который ограничивает автоматическую отправку файлов авторизации. Режимы:</p>

24 <ul><li><strong>Strict</strong>- cookie передаются только при переходе внутри одного домена;</li>

25 <li><strong>Lax</strong>- работает в большинстве безопасных сценариев;</li>

26 <li><strong>None</strong>- требует HTTPS, используется для кросс-доменных приложений.</li>

27 </ul><h3>Проверка метода</h3>

28 <p>Многие серверы допускают важные операции только в POST/PUT/DELETE, а GET разрешён только для безопасных действий.</p>

29 <h2>Ошибки при реализации защиты</h2>

30 <p>Даже при наличии встроенных механизмов сайты могут оставаться уязвимыми - чаще всего из-за неправильной настройки или устаревших подходов.</p>

31 <h3>Неполная проверка токена</h3>

32 <p>Иногда маркер передаётся, но сервер не сверяет его со значением из сессии. Это делает защиту формальной.</p>

33 <h3>Устаревшие браузерные политики</h3>

34 <p>Старые версии браузеров игнорировали атрибуты безопасности cookie. Если проект ориентирован на широкую аудиторию, необходимо учитывать совместимость, правильно выбирать режим SameSite.</p>

35 <h3>Проблемы с шифрованием</h3>

36 <p>Некорректная генерация токена или использование предсказуемых значений снижает эффективность механизма. Маркер должен быть случайным, трудно угадываемым, одноразовым.</p>

37 <h3>Разрешение критичных действий через GET</h3>

38 <p>Если изменение данных возможно обычной ссылкой, сторонний сайт может заставить браузер перейти по адресу автоматически (через изображение, iframe, редирект). Это грубая ошибка, которую нужно исключать на уровне серверной логики.</p>

39 <h2>Современные подходы</h2>

40 <p>Современная веб-безопасность использует более комплексный подход, чем просто токены.</p>

41 <h3>Рекомендации OWASP</h3>

42 <p>Проект OWASP описывает несколько обязательных практик:</p>

43 <ul><li>уникальные маркеры для всех критичных операций;</li>

44 <li>обязательная проверка метода запроса;</li>

45 <li>запрет на выполнение чувствительных действий без повторного подтверждения (например, смена пароля);</li>

46 <li>использование HTTPS;</li>

47 <li>корректная настройка cookie.</li>

48 </ul><h3>Работа с JWT</h3>

49 <p>JSON Web Token сам по себе не защищает от подмены запроса. Однако при правильной конфигурации можно уменьшить риск:</p>

50 <ul><li>хранить маркер не в cookie, а в памяти приложения;</li>

51 <li>использовать защищённые refresh-токены;</li>

52 <li>комбинировать JWT с SameSite, а также дополнительными механизмами подтверждения действий.</li>

53 </ul><h3>Использование дополнительных проверок</h3>

54 <p>Например:</p>

55 <ul><li>контроль происхождения запроса (Origin/Referer с корректными исключениями);</li>

56 <li>двойное подтверждение важных операций;</li>

57 <li>временные ограничения на чувствительные действия.</li>

58 </ul><h2>Инструменты для тестирования</h2>

59 <p>Исследование CSRF-уязвимостей - важная часть пентестов и проверки безопасности.</p>

60 <h3>Burp Suite</h3>

61 <p>Позволяет генерировать вредоносные запросы, перехватывать трафик, изменять параметры и анализировать поведение сайта.</p>

62 <h3>Postman</h3>

63 <p>Помогает вручную формировать запросы, проверять обработку токенов и работу SameSite/cookie.</p>

64 <h3>Скрипты и утилиты</h3>

65 <p>Инструменты на Python или JavaScript упрощают автоматическую генерацию тестовых сценариев, а также проверку устойчивости API к подмене запросов.</p>

66 <h2>Актуальные тренды</h2>

67 <p>Развитие клиентских технологий меняет подход к защите.</p>

68 <h3>Безопасность в SPA</h3>

69 <p>Одностраничные приложения (React, Vue, Angular) часто хранят учетные данные в памяти, а не в cookie. Это снижает риск автоматической подстановки, но требует защиты API:</p>

70 <ul><li>CORS-политики,</li>

71 <li>корректная обработка токенов,</li>

72 <li>проверка происхождения запроса.</li>

73 </ul><h3>Мобильные приложения</h3>

74 <p>Мобильные клиенты редко используют cookie, но API, которым они пользуются, остается уязвимым. Поэтому на бэкенде применяются те же меры: токены, защищенные методы, строгая проверка источника.</p>

75 <h3>Дополнительные уровни защиты</h3>

76 <p>Появляются новые способы фильтрации: модели машинного обучения анализируют аномальное поведение, а серверы отслеживают подозрительные последовательности запросов.</p>

77 <h2>Заключение</h2>

78 <p>CSRF - одна из ключевых уязвимостей веб-приложений. Она использует доверие браузера к сохраненной сессии, может привести к выполнению нежелательных действий от имени пользователя. Надежная защита строится на комбинации методов: токенах, корректной настройке cookie, ограничении методов запросов, анализе происхождения обращения. Понимание современных рекомендаций помогает проектировать приложения, которые устойчивы к подмене запросов, что сохраняет безопасность пользователя.</p>