Что такое CSRF? Как мы можем предотвратить CSRF?

В цифровую эпоху Интернет стал неотъемлемой частью нашей повседневной жизни. Мы перенесли множество активностей в онлайн, от покупок до общения на различных платформах и проведения банковских операций. По мере того как финансовые взаимодействия становятся все более распространенными, последствия проблем с сетевой безопасностью становятся все более ощутимыми. Одной из самых распространенных киберугроз в Интернете является CSRF (межсайтовая подделка запроса), и важно углубиться в ее особенности.

Что такое CSRF?

CSRF-атаки используют уязвимости в механизмах проверки запросов целевого веб-сайта. В определенных ситуациях пользователи, сами того не подозревая, выполняют вредоносные запросы, будучи авторизованными на целевом сайте. Злоумышленники обычно используют адреса, похожие на домен целевого сайта, чтобы заманить пользователей нажатием. Они внедряют вредоносный код, маскируя его под загрузку изображений или скрытые формы, инициируя запросы к целевому сайту и выполняя скрытые несанкционированные действия. Цели, такие как изменение паролей пользователей или инициирование несанкционированных банковских переводов, могут привести к значительным потерям для пользователей.

Пример из реальной жизни

Представьте сайт под названием e-bank.com, предлагающий услуги электронного банкинга, с страницей /transfer для отправки запросов на перевод. Когда пользователи заходят на страницу e-bank.com/transfer, им показывается форма с введенными данными. После заполнения и отправки формы отправляется HTTP POST-запрос на адрес страницы, содержащий параметры, такие как получатель и сумма, введенные пользователем.

На этом этапе злоумышленник может создать вредоносную страницу с невидимой формой, направляющей адрес отправки на e-bank.com/transfer. Злоумышленник заранее заполняет форму параметрами получателя и суммы. Когда пользователи обманом нажимают на эту вредоносную страницу, браузер выполняет JavaScript-код, отправляя форму.

Если пользователь не зарегистрирован или не авторизован на e-bank.com, запрос на перевод не может быть выполнен. Однако, если пользователь недавно использовал сервис и статус авторизации сохраняется, запрос на перевод может быть успешно выполнен.

Это и есть суть CSRF-атак — простых по принципу, но несущих огромный потенциальный вред. К счастью, существует множество зрелых методов для предотвращения таких атак. Давайте рассмотрим их ниже.

Как мы можем предотвратить CSRF?

Решение этой проблемы включает активные и пассивные меры.

Ограничение HTTP-методов и Referer

Как разработчики, мы можем наложить более строгие ограничения на чувствительные адреса в сервисе, например:

• Для адресов, требующих отправки данных, запретить использование HTTP GET-запросов, вынуждая использование POST-запросов. Это усложняет задачу злоумышленникам, пытающимся создать вредоносные страницы.

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

Это простая, активная защитная мера с низкой стоимостью, но все же с некоторой уязвимостью к атакам.

CSRF Token

CSRF Token — это широко распространенное решение, сочетающее механизмы сессий на стороне сервера для предотвращения CSRF-атак. Конкретно, серверная программа встраивает скрытое поле ввода на страницах, требующих защиты, с случайно сгенерированным CSRF Token в выходной форме. Одновременно на стороне сервера создается сессия, хранящая эту случайную строку с временем истечения.

Когда пользователь запрашивает страницу, сервер инициализирует сессию, сохраняя данные на стороне сервера и устанавливая cookie в браузере клиента, содержащую Session ID для ассоциации. CSRF Token хранится в сессии. При отправке формы CSRF Token отправляется. Серверная программа сравнивает этот токен с сохраненной частью в сессии. Успешная проверка приводит к выполнению последующей логики; в противном случае возвращается ошибка. Одновременно в форму вставляется новый CSRF Token для следующей отправки.

Это активная защитная мера, требующая некоторых усилий, но обеспечивающая надежную защиту.

Защита от межсайтовых запросов

Мы часто сталкиваемся с технологией под названием CORS (совместное использование ресурсов между источниками), спецификацией, указывающей, разрешают ли браузеры межсайтовые запросы. Современные браузеры поддерживают эту спецификацию. При инициировании Fetch/XHR-запроса на существующей странице браузер отправляет HTTP OPTIONS-запрос для предварительной проверки, разрешает ли целевой сервис запросы с текущего адреса источника. Сервер предоставит список response-headers, указывающий разрешенные источники, методы запросов и заголовки. Браузер следует этим указаниям, предотвращая запрещенные запросы на стороне клиента.

Это еще одна активная защитная мера, настраиваемая на стороне сервера, но обратите внимание, что хотя обычные пользователи вряд ли отключат эту функцию, это все же возможно на стороне клиента.

Блокировка сторонних куки

Сервисы, которые мы разрабатываем, иногда хранят Session ID пользователей в Cookies для поддержания статуса авторизации. Cookies поддерживают настройки SameSite, предотвращая отправку куки на межсайтовые сайты. Попытка CSRF-атак приводит к неавторизованному статусу на целевом сайте.

Кроме того, из-за злоупотребления механизмами HTTP Cookie для отслеживания клиентов, разработчики браузеров решили постепенно ограничивать и блокировать сторонние куки (Cookie Countdown). Когда страница на домене A пытается сделать вызов на домен B, даже если она проходит проверку правил CORS, браузер не отправит куки на этот межсайтовый сайт.

Итог

Как API-шлюзы, и Apache APISIX, и API7 Enterprise поддерживают CSRF Token и CORS — две защитные меры, упомянутые ранее, для предотвращения CSRF-атак.

В заключение, предотвращение CSRF-атак требует многогранного подхода, включающего различные техники на стороне сервера, браузера, HTTP-протокола и других для достижения комплексной защиты.