Сегодня CSRF-атаки предстают перед нами в числе уязвимостей, которые разработчики веб-приложений не воспринимают всерьез. Это упущение ежегодно приносит серьезные убытки всем, начиная от рядового пользователя сети Интернет, заканчивая крупнейшими IT-корпорациями мира. Я расскажу вам, как сделать свое веб-приложение более стойким по отношению к CSRF-атакам. Стоит отметить, что эта научная работа рассчитана на читателя, знакомого с организацией клиент-серверного взаимодействия.
В 2015 году CSRF-атаки вошли в OWASP топ-10 и заняли почетное 8 место. Однако, уже в 2017 году в очередной топ уязвимостей веб-приложений этот тип атаки уже не попал. Данный факт создает ложное ощущение того, что эта уязвимость осталась в прошлом, но это серьезное заблуждение. Информация, полученные компанией Positive Technologies в ходе проведения мероприятий по пен-тесту и оценки защищенности веб-приложений показывают, что CSRF-атаке подвержена большая часть веб-приложений. Когда другие уязвимости возникают в результате ошибок программирования, CSRF является нормальным поведением веб-сервера и браузера. Подавляющее большинство сайтов, использующих архитектуру, мало отличимую от стандартной, уязвимы по умолчанию.
Что такое CSRF-атака и как злоумышленник способен ее осуществить?
CSRF (Сross Site Request Forgery) дословно означает — подделка межсайтовых запросов. Работает данный тип атак с помощью так называемых Cookie или куки. Этот тип атак появился относительно давно, в 1988 году. Первые же уязвимости были обнаружены уже в 2000 году. А термин CSRF ввел Питер Уоткинс в 2001 году.
Куки — это элемент потока данных клиент-серверного взаимодействия, который веб-сервер отправляет клиенту в формализованном виде. Браузер начинает хранить этот элемент на компьютере пользователя, при необходимости пересылая этот фрагмент данных веб-серверу в заголовке HTTP-запроса.
При открытии пользователем ссылки, заранее подготовленной злоумышленником, от его лица тайно отправляется запрос на сервер, вследствие чего выполняется вредоносная операция. Но есть один нюанс, пользователь должен быть авторизован на том сервере, на который был отправлен запрос, а также последний не должен требовать подтверждения со стороны пользователя, которое последний не может проигнорировать или которое не может быть подделано атакующим скриптом.
Эта атака кажется немного похожей на классическую XSS, в которой злоумышленнику необходимо было вынудить жертву перейти по некоторой ссылке на уязвимую страницу. Браузер пользователя совершает некий запрос и так далее. Однако единственное сходство между ними заключается в использовании в качестве вектора атаки пользователей веб-приложений. CSRF уязвимости могут быть эксплуатированы совместно с XSS или так называемыми «редиректорами», но уже будут представлять собой обособленный класс уязвимостей веб-приложений.
Если представить весь процесс CSRF-атаки в виде схемы, то это будет выглядеть следующим образом:
Главная опасность CSRF-атак заключается в том, что такое поведение браузеров и самого протокола HTTP не вызывает никаких подозрений и является абсолютно нормальным. Например, нормально то, что веб-приложение может на своих страницах содержать картинки с другого сайта. А браузеру заранее неизвестно, что именно пытаются заставить его загрузить, картинку, или под видом данной загрузки будет тайно выполнено какое-либо вредоносное действие на целевом сайте.
Как защититься от CSRF-атак
Наиболее эффективным и оптимальным на сегодня способом защиты от CSRF-атак является токен. Токен — случайный набор байт, который сервер передает клиенту, а клиент в последствии возвращает серверу. Вся защита сводится к проверке токена, который сгенерировал сервер, и токена, который был прислан со стороны пользователя.
Токен имеет ряд обязательных требований:
– ограниченное время жизни
– должен быть сгенерирован криптографически стойким генератором псевдослучайных чисел
– действует только один раз
– для каждой операции свой, отличимый от другого, токен
Также имеются требования к самому веб-приложению и окружению:
– отсутствие XSS уязвимостей
– отсутствие вирусов на устройстве пользователя
Всего существует 3 основных способа применения токенов для защиты от CSRF:
– Synchronizer Tokens
– Double Submit Cookie
– Encrypted Token
Synchronizer Tokens
- При старте сессии на клиентской стороне генерируется токен.
- Токен помещается в специальное хранилище данных сессии.
- Ответом на запрос, что стартовал сессию, пользователю возвращается токен
- При дальнейших запросах клиент обязан передать токен серверу для проверки.
- При получении запроса одним из небезопасных методов сервер обязан проверить токен из данных сессии и токен, которых прислал клиент. Если оба токена совпадают, то запрос можно считать легитимным, в противном случает — запрос отклоняется, а событие логируется.
Double Submit Cookie
- При запросе от клиента, на стороне сервера происходит генерация токена. В ответном фрагменте данных токен возвращается в cookie и в одном из параметров ответа
- В дальнейших запросах клиент обязан предоставлять оба полученных ранее токена.
- При получении запроса одним из небезопасных методов сервер обязан проверить токен из cookie и токен, который был явно прислан клиентом. Если оба токена совпадают, то запрос можно считать легитимным. В противном случае запрос отклоняется и происходит его логирование.
Encrypted Token
- При запросе от клиента на стороне сервера генерируется токен. Процесс генерации состоит в зашифровке фактов, которые необходимы для валидации токена в дальнейшем.
- В последующих запросах клиент обязан предоставить полученный ранее токен.
- При получении запроса одним из небезопасных методов сервер обязан валидировать токен, полученный со стороны клиента. Процесс валидации заключается в расшифровке токена и сравнении фактов, полученных после расшифровки, с реальными.
Все вышеописанные методы имеют различные способы реализации и особенности в организации и построении процесса защиты. Стоит отметить, что токен — это обязательная защита от CSRF-атак. В противном случае Вы рискуете стать жертвой злоумышленника. Также стоит сказать о том, что не нужно передавать токены в URL, а защищать следует все запросы, не важно, каким методом HTTP протокола и с какой целью он был сделан. Так мы получаем токен, который постоянно меняется. Важно также ограничивать время жизни cookie, которое содержит токен, значением, например, 30 минут. Использование криптографического протокола защищенного обмена данными между клиентом и сервером — TLS только укрепит безопасность вашего веб-приложения. Размер же токена желательно задавать не менее 32 байт, что обеспечит его стойкость к подбору на время, максимально необходимое для смены токена.
Same Site
Сегодня идет работа над спецификацией атрибута «Same-Site» у cookies. Такой атрибут даст возмож возможность разработчикам веб-приложений явно указывать, что cookie не нужно передавать, если запрос идет с сайта, отличного от того, на котором cookie была установлена. А, значит, у нас появится возможность защищать ресурсы от CSRF без использования дополнительных инструментов.
Вывод
Всегда нужно относиться с должной степенью серьезности к любым уязвимостям или возможным атакам на ваше веб-приложение. Ведь пренебрежение безопасностью может легко заставить Вас понести колоссальные убытки, даже такая, всеми недооцененная уязвимость, как CSRF-атака. Для более глубокого практического описания методов защиты веб-приложений от атаки подделки межсайтового запроса и ее реализации в условиях информационного противоборства формата одной статьи будет недостаточно, поэтому я уже пишу более масштабную научную работу по этому вопросу. Призываю Вас приложить максимум усилий, чтобы обеспечивать свой веб-сервис и вместе с этим его пользователей безопасностью, хотя бы в рамках вашего проекта. Такими маленькими шажками мы совместными усилиями сделаем Интернет немного безопаснее.
Литература:
- Олифер В. Компьютерные сети. Принципы, технологии, протоколы [Текст]: учебник для вузов. 5-е издание / В.Олифер, Н.Олифер.-СПб: Питер, 2016. — 992 с.
- Хоффман Э. Безопасность веб-приложений [Текст] / Э.Хоффман — СПб.: Питер, 2021. — 336 с.
- Борисенков О. Межсайтовая подделка запроса: защита от CSRF атак [электронный ресурс] / О.Борисенков. — Электронные текстовые данные. — Москва: [б.и.], 2021. — Режим доступа: https://tproger.ru/articles/mezhsajtovaja-poddelka-zaprosa-zashhita-ot-csrf-atak/, свободный.
