CSRF

CSRF

межсайтовая подделка запроса

атака, при которой злоумышленник заставляет пользователя выполнять нежелательные действия в веб-приложении, в котором тот уже авторизован

CSRF - write-only атака

Историческая правка

В 2000 были представленны HTTP Cookie во всех основных браузерах, в начале 2000 была найдена уязвимость CSRF.

Громкие случаи

В 2008 году уязвимость CSRF была найдена в функционале Google Mail. Пользователи могли быть обмануты и отправлять письма с содержанием, указанным злоумышленником.
В 2015 году GitHub был подвержен CSRF-атаке, которая позволяла злоумышленникам получить доступ к конфиденциальным данным пользователей
В eBay была обнаружена уязвимость CSRF, которая позволяла злоумышленникам перенаправлять средства с одного счета на другой без ведома пользователя

Этапы атаки

1

Пользователь заходит в веб-приложение и авторизуется (например, в онлайн-банке)

2

Приложение создает сессию, и пользовательский браузер сохраняет cookies

3

Злоумышленник отправляет пользователю ссылку или включает вредоносный код на стороннем сайте

4

Браузер пользователя автоматически прикрепляет cookies к запросу, считая его легитимным

Почему это работает?

Cookie посылаются в запросе исходя из того на какой домен посылается запрос, а не с какого

Чтобы Cookie файлы послались должны совпасть следующие факторы

  • Протокол (http/https)
  • Домен (example.com)
  • Порт (80, если HTTP или 443, если HTTPS)

Пример атаки CSRF

Предположим, у пользователя есть учетная запись в онлайн-банке. После авторизации он оставил вкладку браузера открытой

Злоумышленник отправляет ему сообщение с ссылкой (или совершает XSS)

Главной целью на этом этапе является запуск вредоносного кода на стороне клиента

Браузер пользователя, будучи авторизованным, отправляет запрос на сервер банка, включая cookies сессии

Так как реквест направляется на https://bank.example.com, то соответственно все существующие куки, которые привязаны к сайту отправляются вместе с реквестом

Сервер банка обрабатывает запрос как легитимный и выполняет перевод 

flowchart TD
    A[Злоумышленник] --> B[ Вредоносный сайт ] --> C[ Браузер ] --> D[ Сервер ]

Пример payload'а через форму


...


...

Основные точки входа для атак

Ссылки

  • Вставка вредоносной ссылки в письмо, чат или веб-страницу
  • Пользователь переходит по ссылке, инициируя запрос

Формы

  • Использование скрытых форм для отправки данных
  • Форма автоматически отправляется при загрузке страницы

Изображения или теги скриптов

  • Вредоносный запрос может быть внедрен в элемент img или script (XSS)

Основные ошибки

  • Сервер принимает запросы на основе только cookies без дополнительной проверки
  • Отсутствие CSRF-токенов в формах
  • Использование GET-запросов для выполнения действий, изменяющих данные
  • Приложение не проверяет заголовки Origin или Referer

Принципы защиты от CSRF

Использование уникальных CSRF-токенов

Каждое изменение данных должно сопровождаться уникальным токеном, который генерируется на сервере и передается в форму или запрос.

CSRF-токенов

уникальные строки, которые генерируются сервером для каждого сеанса пользователя или формы
CSRF-токен передается пользователю на стадии загрузки страницы

Принципы защиты от CSRF

Проверка заголовков Origin и Referer

Сервер должен проверять заголовки Origin и Referer для каждого запроса, чтобы убедиться, что запрос пришел с доверенного источника 


if request.headers['Origin'] != 'https://trustedwebsite.com':
    abort(403)  # Запрещаем выполнение запроса

Принципы защиты от CSRF

Использование методов POST, а не GET

Для выполнения действий, изменяющих данные (например, переводы денег, удаление данных), следует использовать только метод POST 


@app.route('/delete_item', methods=['POST'])
def delete_item():
    # Логика удаления элемента
    pass

Принципы защиты от CSRF

Использование двухфакторной аутентификации (2FA)

для чувствительных операций, таких как переводы средств, изменение паролей и другие критичные действия.

Принципы защиты от CSRF

Использование CSP

Content Security Policy

механизм безопасности, который помогает предотвратить XSS-атаки, но также может быть полезен для защиты от CSRF

Как использовать CSP
  • Разрешать загрузку ресурсов только с доверенных источников
  • Использовать директиву default-src

Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' https://trusted-image-source.com;

Принципы защиты от CSRF

Использование CORS

Cross-Origin Resource Sharing

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

Как работает CORS
Запрос с http://example1.com на http://example2.com не будет работать, если CORS не настроен
HTTP заголовки CORS

Access-Control-Allow-Origin # домены, которые имеют доступ
Access-Control-Allow-Methods # Методы, которые разрешены (GET, POST...)
Access-Control-Allow-Headers # Заголовки, которые могут быть отправлены вместе с запросом
Access-Control-Allow-Credentials # Могут ли отправляться Cookies
                        

Access-Control-Allow-Origin: https://client-app.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Authorization