Double submit что это

Информационная безопасность

SQL-инъекция — это атака, направленная на веб-приложение, в ходе которой конструируется SQL-выражение из пользовательского ввода путем простой конкантенации, например: $query=»SELECT * FROM users WHERE > В случае успеха атакующий может изменить логику выполнения SQL-запроса так, как это ему нужно. Чаще всего он выполняет простой fingerprinting СУБД, а также извлекает таблицы с наиболее «интересными» именами (например «users»). После этого, в зависимости от привилегий, с которыми запущено уязвимое приложение, он может обратиться к защищенным частям бэк-энда веб-приложения (например, прочитать файлы на стороне хоста или выполнить произвольные команды)

Защита:

• Данные подставляем в запрос только через плейсхолдеры (подготовленные выражения). Также имеются серверные плейсхолдеры. В их случае выполнение подготавливаемого запроса проводится в два этапа: подготовка и исполнение. На этапе подготовки на сервер посылается шаблон запроса. Сервер выполняет синтаксическую проверку этого шаблона, строит план выполнения запроса и выделяет под него ресурсы. За подготовкой идет выполнение. Во время запуска запроса клиент привязывает к псевдопеременным реальные значения и посылает их на сервер. Сервер, в свою очередь, подставляет их в шаблон и запускает уже готовый запрос на выполнение.
• идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.

Экранирование не является надежным способом защиты от SQL. Так как рано или поздно кто-нибудь забудет проэкранировать входящие данные + возможны sql атаки и без кавычек, например мы можем вставить вместо какого-то скалярного значения вложенный запрос.

• https://habr.com/post/148701/

XSS

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода(который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. Является разновидностью атаки «внедрение кода[en]».

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

Защита:

Экранируем входные и выходные данные. Или санитизируем(тупо удаляем всё лишнее)

Также стоит включать session.cookie_httponly — запретить чтение и модификацию кук для JS. Это позволит избежать основной проблемы при XSS — угона пользовательской сессии.

CSRF

CSRF (англ. Cross Site Request Forgery — «межсайтовая подделка запроса») — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки жертва должна быть аутентифицирована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом.

Защита:

CSRF token

• Для каждой пользовательской сессии генерируется уникальный и высокоэнтропийный токен.
• Токен вставляется в DOM HTML страницы или отдается пользователю через API.
• Пользователь с каждым запросом, связанным с какими-либо изменениями, должен отправить токен в параметре или в HTTP-заголовке запроса.
• Так как атакующий не знает токен, то классическая CSRF-атака не работает.

Double submit cookie

• Опять генерируется уникальный и высокоэнтропийный токен для каждой пользовательской сессии, но он помещается в куки.
• Пользователь должен в запросе передать одинаковые значения в куках и в параметре запроса.
• Если эти два значения совпадают в куках и в параметре, то считается, что это легитимный запрос.
• Так как атакующий просто так не может изменить куки в браузере пользователя, то классическая CSRF-атака не работает.

Content-Type based protection

• Пользователь должен отправить запрос с определенным заголовком Content-Type, например, application/json.
• Так как в браузере через HTML форму или XHR API невозможно отправить произвольный Content-Type cross-origin, то классическая CSRF-атака опять не работает.

Referer-based protection

• Пользователь должен отправить запрос с определенным значением заголовка Referer. Бэкенд его проверяет, если он неверный, то считается, что это CSRF-атака.
• Так как браузер не может отправить произвольный Referer через HTML форму или XHR API, то классическая CSRF-атака не работает.

Password confirmation / websudo

• Пользователь должен подтверждать действие с помощью пароля (или секрета).
• Так как атакующий его не знает, то классическая CSRF-атака не работает.

SameSite Cookies в Chrome, Opera

Это новая технология, которая призвана защитить от CSRF. В данный момент она работает только в двух браузерах (Chrome, Opera).

• У куки устанавливается дополнительный атрибут — samesite, который может иметь два значения: lax или strict.
• Суть технологии в том, что браузер не отправляет куки, если запрос осуществляется с другого домена, например, с сайта атакующего. Таким образом это опять защищает от классической CSRF-атаки.

• CSRF-уязвимости все еще актуальны
• Методы защиты от CSRF-атаки

OWSAP

1. Инъекции, они же “Внедрение кода”.
2. Некорректная аутентификация
3. Раскрытие чувствительной информации
4. Внедрение внешних XML-сущностей (XXE)
5. Нарушенный контроль доступа
6. Security Misconfiguration – Ошибки в конфигурировании
7. Межсайтовый скриптинг (XSS)
8. Небезопасная десериализация
9. Использование компонентов с известными уязвимостями
10. Недостаточное логирование и мониторинг

Базовая защита данных на JavaScript

Последние пару лет защита личных данных пользователей стала камнем преткновения для многих компаний. Сбербанк, Skyeng, Delivery Club и ещё десятки крупных компаний в России и мире страдают от утечек данных каждый год. В этой статье специалисты MediaSoft собрали рекомендации, как базово защитить личные данные пользователей от утечек.

Разберёмся, как можно воздействовать на данные пользователя извне, и как это предотвратить.

МЕЖСАЙТОВЫЙ СКРИПТИНГ, XSS

XSS — это внедрение вредоносного кода на страницы атакуемого сервера. В браузере клиента будет выполнен произвольный JavaScript-код, который позволит злоумышленнику украсть пользовательскую сессию.

Чтобы качественно защититься от XSS-атак, стоит разобраться в их видах. Уязвимости XSS делятся на отражённые и хранимые. Это зависит от того, как сайт возвращает внедрённый код в браузер.

• Отражённая XSS-уязвимость возникает, когда контент пользователя, передаваемый на сервер, немедленно и без изменений возвращается для отображения в браузере. Любой скрипт в исходном пользовательском контенте запустится при загрузке новой страницы. Злоумышленник может создать поисковую ссылку, которая будет содержать вредоносный скрипт в качестве параметра (например: http://mysite.com?q=beer) и переслать его другому пользователю по электронной почте.
• Хранимая уязвимость XSS возникает, когда вредоносный скрипт хранится на сайте, а затем снова отображается без изменений.

КАК ЗАЩИТИТЬСЯ ОТ XSS-АТАК?

Инструменты санитизации. Санитизация — это «очистка» кода от подозрительных или вредоносных участков кода.

Функцию очистки можно написать самостоятельно, но для продакшна такой вариант недостаточен. Рекомендуем воспользоваться специальной библиотекой-санитайзером. Например, DOM Purify. Подобные библиотеки могут отсечь код, который считают небезопасным.

Экранирование — это замена специальных символов, которые браузер может посчитать за теги, безопасными.
При экранировании запись превратится в <script>alert('XSS!');</script>. Такую запись браузер не распознает как тег или скрипт.

Для реализации экранирования пользовательского контента в JavaScript необходимо использовать:
encodeURI — чтобы кодировать URI-адрес
encodeURIComponent — кодировать часть URI-адреса, например, searchQuery,
специальные библиотеки для замены , ‘,» и других специальных символов.

Content Security Policy (CSP) — один из самых мощных способов защиты. Это «белый» список того, что можно использовать в работе. Каждая из директив CSP отвечает за тип источника:
script-src — список источников, откуда могут подгружаться скрипты;
style-src — стили;
img-src — ресурс для загрузки картинок.
Content Security Policy — хороший инструмент защиты, который даёт большой простор для работы из-за обилия возможных настроек. Весь список директив и настроек здесь.

SQL-ИНЪЕКЦИИ, SQL-INJECTION

SQL-инъекции — это один из видов XSS. Суть этой атаки заключается в доступе к данным атакуемого сервиса или их изменению.

Когда пользователь отправляет данные на веб-сайте, они попадают в веб-приложение, которое, в свою очередь, использует эти данные при доступе ко всей базе данных. Для обращения к данным в реляционных БД используется SQL (Structured Query Language). Этот язык стандартизирован, и основные его команды одинаковы для разных производителей системы управления базами данных — Microsoft, Oracle, MySQL, PostgreSQL и других.

КАК ЗАЩИТИТЬСЯ ОТ SQL-ИНЪЕКЦИЙ?

Используйте параметризацию. Данные, присылаемые пользователем, не должны участвовать в формировании текста SQL-запроса. По крайней мере, напрямую. Это достигается использованием подготовленных запросов.

В этом случае какой бы текст пользователь не ввёл, приложение будет искать текст только в заданных категориях.
Используйте хранимые процедуры. В некоторых запросах невозможно использовать параметризацию. В таком случае необходимо ограничить список допустимых значений — создать «белый список» для значений, приходящих от пользователя.

Давайте меньше привилегий. Системная учетная запись должна иметь как можно меньше привилегий. Не нужно давать возможность читать и создавать файлы, не относящиеся к приложению, и производить другие критические с точки зрения безопасности действия.

МЕЖСЕТЕВАЯ ПОДДЕЛКА ЗАПРОСА, CSRF

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

Для выполнения CSRF необходимы определённые условия:

• на уязвимом сайте есть действие, которое злоумышленник может выполнить от имени жертвы (например, перевести деньги);
• злоумышленник заранее знает все параметры запроса;
• действие полагается только на файлы cookies для верификации пользователя и выполняется с помощью HTTP-запросов.

КАК ЗАЩИТИТЬСЯ ОТ CSRF-АТАК?

Выбирайте защищённые фреймворки. Это те фреймворки, которые имеют встроенную защиту против CSRF. Кроме того, уделите внимание правильной настройке фреймворка. Если ваш фреймворк не имеет защиты, то можно использовать CSRF токены.

CSRF токены. Сервер генерирует уникальный проверочный токен, который передается на сторону клиента в виде скрытого поля или параметра URL. Затем клиентская сторона возвращает этот токен как часть формы или URL, а сервер проверяет действительность токена. Токен обычно генерируется для каждого пользователя на одну сессию.

В отличие от cookies, которые передаются браузером вместе с соответствующим запросом, независимо от происхождения запроса, токены защищены same-origin policy. Они являются непосредственной частью страницы.

Условия, которым должен удовлетворять токен:

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

Double submit cookie. В этом случае так же генерируется уникальные токен для каждой сессии, но он помещается в cookies. Пользователь должен передать одинаковые значения в cookies и в запросе. Если они совпадают, значит запрос отправляет реальный пользователь, а если нет — хакер. Атакующий не может изменить cookies в браузере пользователя, поэтому классическая CSRF-атака не сработает.

SOP или same-origin policy. Такая политика определяет, как скрипт или документ будет взаимодействовать с ресурсом, загруженным из другого источника. У двух страниц одинаковый источник, если host, port и протокол (http/https) совпадают. Запись вида scheme/host/port tuple позволяет изолировать документы, которые могут нанести вред.

Same-Site Cookies. Этот метод помечает cookies для одного доменного имени атрибутом samesite, который может иметь два значения: lax или strict. Суть заключается в том, что браузер не отправляет cookies, если запрос происходит с другого домена.

Также с помощью Same-Site Cookies можно выставить cookies так, чтобы они были видны только для сервиса, который их выставил:
Set-Cookie: key=value; SameSite=Strict

Также, если с куками не должны работать клиентские скрипты, их можно спрятать:
Set-Cookie: key=value; HttpOnly

Это сделает cookies видимой только для сервера и браузера.

Подтверждение действий от пользователя. Для изменения каких-либо данных, перевода денег и т.д. добавить дополнительное подтверждающее действие — хорошая практика. Например, можно попросить пользователя ввести капчу или нажать на кнопку на сайте.

BRUTEFORCE ATTACK

Bruteforce attack – это атака, при которой злоумышленник получает данные для входа в систему перебором. Самый простой пример — попытка угадать пароль.

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

КАК ЗАЩИТИТЬСЯ ОТ BRUTEFORCE-АТАК?

Ограничение частоты обращений. Хакеру может потребоваться огромное количество попыток, чтобы угадать пароль, а вот владельцу аккаунта достаточно 10-15, чтобы его вспомнить. Кроме того, ограничение частоты поможет регулировать входящий и исходящий трафик.

reCAPTCHA. Это одно из классических решений, которое работает только для форм авторизации/регистрации и не даёт атакующему отправлять случайные запросы.

Надёжные пароли. Принципиально отвергайте слабые пароли, требуйте надежных и сложных паролей и периодической смены паролей.

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

Высокий уровень шифрования. Чем выше степень шифрования, тем сложнее перебрать пароль.

Рандомизированные хэши паролей. В пароль вводятся дополнительные случайные строки символов, которые делают хэш рандомным.

ВЫВОД

В статье вместе с экспертами MediaSoft мы разобрались, как можно воздействовать на данные извне. Разобрались в базовых методах защиты пользовательских данных. Помните, что веб-приложение не может доверять никаким данным из веб-браузера. Все пользовательские данные должны быть очищены перед отображением или использованием в SQL-запросах и вызовах файловой системы.

Если вам стала интересна эта тема, и вы хотите углубиться в тему безопасности, то рекомендуем обратить внимание на ссылки в разделе дополнительные материалы.

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

ДОПОЛНИТЕЛЬНЫЕ МАТЕРИАЛЫ

XSS Game — игра от Google для оттачивания хакерских навыков.
Сайт для тренировки основных видов атак веб-приложений.
Безопасность: уязвимости вашего приложения — доклад с HolyJS.
Лекция об угрозах из списка OWASP Top 10.
Онлайн-тренажеры по HTML, CSS, JS и React для начинающих

Методы защиты веб-приложений от CSRF-атак

Прачёв, И. С. Методы защиты веб-приложений от CSRF-атак / И. С. Прачёв. — Текст : непосредственный // Молодой ученый. — 2022. — № 8 (403). — С. 4-7. — URL: https://moluch.ru/archive/403/89068/ (дата обращения: 08.01.2024).

Сегодня 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:

– Double Submit Cookie

1. При старте сессии на клиентской стороне генерируется токен.
2. Токен помещается в специальное хранилище данных сессии.
3. Ответом на запрос, что стартовал сессию, пользователю возвращается токен
4. При дальнейших запросах клиент обязан передать токен серверу для проверки.
5. При получении запроса одним из небезопасных методов сервер обязан проверить токен из данных сессии и токен, которых прислал клиент. Если оба токена совпадают, то запрос можно считать легитимным, в противном случает — запрос отклоняется, а событие логируется.

Double Submit Cookie

1. При запросе от клиента, на стороне сервера происходит генерация токена. В ответном фрагменте данных токен возвращается в cookie и в одном из параметров ответа
2. В дальнейших запросах клиент обязан предоставлять оба полученных ранее токена.
3. При получении запроса одним из небезопасных методов сервер обязан проверить токен из cookie и токен, который был явно прислан клиентом. Если оба токена совпадают, то запрос можно считать легитимным. В противном случае запрос отклоняется и происходит его логирование.

1. При запросе от клиента на стороне сервера генерируется токен. Процесс генерации состоит в зашифровке фактов, которые необходимы для валидации токена в дальнейшем.
2. В последующих запросах клиент обязан предоставить полученный ранее токен.
3. При получении запроса одним из небезопасных методов сервер обязан валидировать токен, полученный со стороны клиента. Процесс валидации заключается в расшифровке токена и сравнении фактов, полученных после расшифровки, с реальными.

Все вышеописанные методы имеют различные способы реализации и особенности в организации и построении процесса защиты. Стоит отметить, что токен — это обязательная защита от CSRF-атак. В противном случае Вы рискуете стать жертвой злоумышленника. Также стоит сказать о том, что не нужно передавать токены в URL, а защищать следует все запросы, не важно, каким методом HTTP протокола и с какой целью он был сделан. Так мы получаем токен, который постоянно меняется. Важно также ограничивать время жизни cookie, которое содержит токен, значением, например, 30 минут. Использование криптографического протокола защищенного обмена данными между клиентом и сервером — TLS только укрепит безопасность вашего веб-приложения. Размер же токена желательно задавать не менее 32 байт, что обеспечит его стойкость к подбору на время, максимально необходимое для смены токена.

Сегодня идет работа над спецификацией атрибута «Same-Site» у cookies. Такой атрибут даст возмож возможность разработчикам веб-приложений явно указывать, что cookie не нужно передавать, если запрос идет с сайта, отличного от того, на котором cookie была установлена. А, значит, у нас появится возможность защищать ресурсы от CSRF без использования дополнительных инструментов.

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

1. Олифер В. Компьютерные сети. Принципы, технологии, протоколы [Текст]: учебник для вузов. 5-е издание / В.Олифер, Н.Олифер.-СПб: Питер, 2016. — 992 с.
2. Хоффман Э. Безопасность веб-приложений [Текст] / Э.Хоффман — СПб.: Питер, 2021. — 336 с.
3. Борисенков О. Межсайтовая подделка запроса: защита от CSRF атак [электронный ресурс] / О.Борисенков. — Электронные текстовые данные. — Москва: [б.и.], 2021. — Режим доступа: https://tproger.ru/articles/mezhsajtovaja-poddelka-zaprosa-zashhita-ot-csrf-atak/, свободный.

Основные термины (генерируются автоматически): CSRF, XSS, запрос, HTTP, клиент, получение запроса, сервер, ваше веб-приложение, клиент-серверное взаимодействие, противный случай.

Слепые атаки: понимание CSRF (подделка межсайтовых запросов)

Недавно я занялся исследованием веб-безопасности, когда писал [Понимание асинхронного JavaScript] (https://asyncjs.today) — я хотел убедиться, что мои рекомендации безопасны, и я не окажу своим студентам медвежью услугу своими рекомендациями. .

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

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

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

Два вида CSRF-атак

Существует два вида CSRF-атак:

Сначала мы обсудим обычную CSRF-атаку, а затем логин CSRF.

Что такое CSRF-атака

Атака CSRF — это атака, которая обманом заставляет жертву отправить вредоносный запрос — запрос, который они не собирались делать — на веб-сайт, где они аутентифицированы (вошли в систему).

Запрос должен исходить от другого веб-сайта, который называется «Кросс-сайт». Этот запрос также выдает себя за аутентифицированного пользователя, что дает ему имя «Подделка запроса».

CSRF-атаки слепые — это означает, что злоумышленник не видит, что происходит после отправки запроса жертвой. Атаки CSRF часто нацелены на изменение состояния сервера.

Что такое изменение состояния? По сути, все, что изменяет базу данных, является изменением состояния.

Примеры изменений состояния включают:

• Изменить имя пользователя и пароль

• Отправка денег на счет

• Отправка поддельных сообщений из учетной записи пользователя

• Обмен неприемлемыми изображениями или видео из учетной записи пользователя

Атаки CSRF используют тот факт, что браузеры автоматически отправляют файлы cookie на сервер при каждом запросе. Без какой-либо защиты CSRF сервер может предположить, что запрос действителен, когда присутствует файл cookie аутентификации.

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

Предпосылки для работы CSRF-атак

Для успешной атаки CSRF необходимы четыре предварительных условия.

1. На сервер отправляется запрос любого метода.

1. Пользователь должен пройти аутентификацию.

1. Сервер должен хранить информацию об аутентификации в файлах cookie.

1. На сервере не реализованы методы предотвращения CSRF (о которых будет сказано ниже).

Как работают CSRF-атаки

Прежде чем злоумышленник сможет запустить CSRF-атаку, ему необходимо найти последовательный запрос, на который он может нацелиться. Они бы знали, что делает запрос. Это может быть любой запрос — GET, POST, PUT или DELETE.

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

Наконец, они должны обманом заставить пользователя отправить запрос. В большинстве случаев это означает:

1. Найдите способ отправить запрос автоматически без ведома пользователя. Наиболее распространенные подходы — это использование тегов изображений и автоматическая отправка формы JavaScript.

1. Искажение ссылки (или кнопки), которая заставляет пользователя щелкнуть ее. (AKA Социальная инженерия).

Атаки через GET-запрос

Атаки CSRF с запросом GET работают только в том случае, если сервер позволяет пользователю изменять состояние с помощью запросов GET. Вам не нужно беспокоиться об этом типе атаки CSRF, если ваши запросы GET доступны только для чтения.

Но допустим, у нас есть сервер, который не следует передовым методам программирования и позволяет изменять состояние с помощью запроса GET. Если они сделают это, у них будут проблемы — огромные проблемы.

Например, предположим, что есть банк, который позволяет вам переводить деньги со следующей конечной точкой. Вам просто нужно ввести «счет» и «сумма» в запросе GET, чтобы отправить деньги человеку следующим образом:

Злоумышленник может сгенерировать ссылку, которая отправляет деньги на его счет.

Отправляет 9999 на аккаунт злоумышленника

На этом этапе злоумышленник может найти способ автоматически активировать ссылку без ведома пользователя.

Один из способов — включить ссылку в изображение 0x0 на веб-странице или в электронном письме. Если пользователь посещает эту веб-страницу или электронную почту, запрос GET запускается автоматически, поскольку браузеры и электронные письма настроены на автоматическую загрузку изображений.

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

Другой способ — исказить то, что делает ссылка. Это работает, потому что люди не проверяют ссылки, прежде чем перейти по ним. Если человек щелкнет ссылку, он отправит запрос GET для злоумышленника, не зная об этом.

Если пользователь аутентифицирован, сервер получит файл cookie аутентификации, который позволяет ему поверить, что запрос действителен. Если сервер не использовал никаких механизмов защиты от CSRF, деньги будут отправлены злоумышленнику.

Примеры GET CSRF-атак:

• uTorrent подвергся CSRF-атаке еще в [2008] (https://en.wikipedia.org/wiki/Cross-site_request_forgery/), и он позволял изменять состояние с помощью запросов GET.

• Ранее в 2008 на YouTube была обнаружена уязвимость в системе безопасности, которая позволяла злоумышленнику выполнять практически все действия, возможные для пользователя, включая отправку сообщений, добавление в список друзей и т. д.

Если вы нажмете на ссылки выше. Вы сможете найти примеры реальных GET-запросов, которые создают такую ​​CSRF-атаку. (Не волнуйтесь, здесь нет странных ссылок ��).

CSRF-атаки с POST-запросами

CSRF-атаки с POST-запросами следуют той же схеме, но они не могут быть отправлены через ссылки или теги изображений. Их нужно отправить через форму или через JavaScript.

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

Злоумышленник может создать форму и скрыть от пользователя значения «счет» и «сумма». Люди, которые нажимают на эту искаженную форму, отправляют запрос POST без их ведома.

Вы никогда не сможете выполнить CSRF-атаку через HTML.

А теперь интересное: как люди отправляют запросы PUT и DELETE через форму, если HTML этого не позволяет? После некоторых исследований я обнаружил, что большинство фреймворков позволяют отправлять запрос POST с параметром _method.

Вы можете выполнить CSRF-атаку «PUT» через JavaScript, но механизм предотвращения по умолчанию в современных браузерах и серверах делает эти атаки очень сложными — вы должны намеренно ослабить защиту, чтобы это произошло. Вот почему.

Чтобы выполнить CSRF-атаку «PUT», вам необходимо отправить запрос Fetch с методом «put». Вам также необходимо включить опцию «credentials».

константная форма = document.querySelector(‘form’)

// Отправляет запрос автоматически

// Перехватывает отправку формы и использует Fetch для отправки запроса AJAX.

Credentiials: ‘include’ // Включает куки в запрос

Это не сработает по трем причинам.

Во-первых, этот запрос НЕ будет выполняться браузерами автоматически из-за CORS. Если, конечно, сервер не создаст уязвимость, разрешив запросы от кого угодно со следующим заголовком:

Во-вторых, даже если вы разрешаете всем источникам доступ к вашему серверу, вам все равно нужна опция «Access-Control-Allow-Credentials», чтобы браузеры могли отправлять файлы cookie на сервер.

В-третьих, даже если вы разрешите отправку файлов cookie на сервер, браузеры будут отправлять файлы cookie только с атрибутом sameSite , установленным на none . (Они также называются сторонними файлами cookie).

Если вы понятия не имеете, о чем я говорю в отношении третьего пункта, вы в безопасности — вы действительно должны быть злонамеренным разработчиком, который хочет испортить ваш сервер, если вы отправляете файлы cookie аутентификации как сторонние файлы cookie.

Этот раздел огромен. Я создал еще несколько статей, чтобы помочь вам понять, что именно происходит — и почему так чертовски невероятно сложно подвергнуть себя CSRF-атаке PUT:

• [Общие сведения о файлах cookie sameSite] (https://zellwk.com/blog/samesite-cookies/)

• [Понимание учетных данных Fetch] (https://zellwk.com/blog/handling-cookies-with-fetchs-credentials/)

Короче говоря, вам нужно беспокоиться только о CSRF-атаках POST, если вы действительно не облажались со своим сервером.

Методы предотвращения CSRF

Наиболее распространенными методами профилактики CSRF на сегодняшний день являются:

• Двойной шаблон отправки файлов cookie

• Метод заголовка файлов cookie

Оба метода следуют одной и той же формуле.

Когда пользователь посещает ваш веб-сайт, ваш сервер должен создать токен CSRF и поместить его в файлы cookie браузера. Общие имена для этого токена:

Используйте любое имя токена, которое вы предпочитаете. Все они работают.

Важно то, что токен CSRF должен быть случайно сгенерированной криптографически стойкой строкой. Если вы используете Node, вы можете сгенерировать строку с помощью crypto .

импортировать крипто из ‘crypto’

функция csrfToken (req, res, next)

Если вы используете Express, вы можете поместить этот токен CSRF в свои файлы cookie следующим образом. При этом я рекомендую также использовать строгую опцию sameSite . (Мы немного поговорим о sameSite ).

импортировать cookieParser из «cookie-parser»

// Используйте это для чтения файлов cookie

// Установка токена CSRF для всех конечных точек

// Устанавливает токен, если пользователь посещает эту страницу впервые в этой сессии

То, как вы используете токен CSRF, меняется в зависимости от того, поддерживаете ли вы шаблон отправки Double cookie или метод Cookie to header (или оба).

Шаблон файла cookie с двойной отправкой

Название этого шаблона немного вводит в заблуждение, потому что оно, похоже, означает отправку файла cookie дважды с помощью «Double Submit Cookie».

Что это означает:

1. Вы можете отправить токен CSRF в файле cookie

1. Вы визуализируете с токеном CSRF, который будет включен в отправку формы.

(Отсюда двойное подчинение).

Если вы используете Express, вы можете передать токен CSRF в HTML следующим образом:

app.get(‘/some-url’, (req, res) =>

// Рендерим с помощью Nunjucks.

// Замените Nunjucks любым другим механизмом шаблонов, который вы используете

Затем вы можете использовать форму CSRF_TOKEN следующим образом:

Затем сервер может проверить действительность сеанса, сравнив два токена CSRF. Если они совпадают, это означает, что запрос не подделан, потому что злоумышленник не может угадать значение токена CSRF на другом веб-сайте.

// Проверяем действительность токена CSRF

app.post(‘/login’, (req, res) =>

// Вы также можете выдать ошибку, если хотите

если (CSRF_TOKEN !== csrf) вернуть

Метод Cookie to Header

Метод cookie для заголовка аналогичен, за исключением того, что он выполняется с помощью JavaScript. В этом случае токен CSRF должен быть включен как в файл cookie, так и в заголовок запроса.

В этом случае нам необходимо:

1. Установите «учетные данные» на «включить» или «тот же источник», чтобы включить файлы cookie.

1. Возьмите токен CSRF из document.cookies и добавьте его в качестве заголовка запроса.

Вот пример запроса:

// Получает значение именованного файла cookie

const match = document.cookie.match(new RegExp(‘(^| )’ + name + ‘=([^;]+)’))

если (совпадение) возвратить совпадение[2]

fetch(‘/login’, (req, res) =>

учетные данные: «включить»,

Сервер может проверить действительность токена CSRF следующим образом:

// Проверяем действительность токена CSRF

app.post(‘/login’, (req, res) =>

// Вы также можете выдать ошибку, если хотите

если (CSRF_TOKEN !== csrf) вернуть

Сделайте все это проще с библиотекой

Я показал вам, как вручную создавать и тестировать токены CSRF, потому что хотел дать вам представление о процессе.

Этот процесс уже решался много раз, поэтому нам не следует выполнять его вручную (если только вы не учитесь, как это сделал я здесь).

Если вы используете Express, я рекомендую использовать библиотеку csurf, поскольку она более надежна и гибка по сравнению с тем, что я мог показать в этом примере выше.

Атрибут файла cookie SameSite

Установка для sameSite значения strict в приведенном выше примере гарантирует, что файл cookie токена CSRF будет отправлен на сервер только в том случае, если запрос исходит с того же веб-сайта. Это гарантирует, что токен CSRF никогда не попадет на внешние страницы.

Вы можете — необязательно, но рекомендуется — установить для атрибута sameSite значение strict , когда вы устанавливаете файл cookie для аутентификации. Это гарантирует, что никакие CSRF-атаки не могут быть проведены, поскольку файлы cookie аутентификации больше не будут включаться в межсайтовые запросы.

Нужна ли вам защита токена CSRF, если вы установили для sameSite значение strict для своего файла cookie аутентификации?

В большинстве случаев я бы сказал нет, потому что sameSite уже защищает сервер от межсайтовых запросов. Нам по-прежнему нужен токен CSRF для защиты от одного конкретного типа CSRF: Логин CSRF.

Вы можете узнать больше о файлах cookie sameSite в этой статье.

Войти CSRF

Логин CSRF полностью отличается от обычных CSRF-атак с точки зрения намерений.

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

Они также могут автоматически активировать форму с помощью JavaScript.

константная форма = document.querySelector(‘form’)

// Отправляет запрос автоматически

Если пользователь не понимает, что он вошел в учетную запись злоумышленника, он может добавить личные данные, такие как данные кредитной карты или историю поиска, в учетную запись. Затем злоумышленники могут снова войти в свои учетные записи, чтобы просмотреть эти данные.

Google был уязвим для CSRF-атак [в прошлом] (https://seclab.stanford.edu/websec/csrf/csrf.pdf).

Мы можем предотвратить вход CSRF с помощью шаблона Double Submit Cookie, упомянутого выше — злоумышленники не смогут угадать токен CSRF, что означает, что они не могут запустить атаку входа CSRF.

Подведение итогов

CSRF означает подделку запросов сайта. Существует два вида CSRF-атак:

В обычном CSRF злоумышленник стремится создать изменение состояния с помощью запроса.

В Login CSRF злоумышленник стремится обманом заставить пользователя войти в учетную запись злоумышленника и, надеюсь, извлечь выгоду из действий пользователя, если он не знает.

Вы можете предотвратить оба типа CSRF-атак с помощью шаблона Double Submit Cookie и метода Cookie to header. Установка для sameSite значения strict предотвращает обычный CSRF, но не CSRF входа.

Спасибо за чтение. Подпишитесь на мой информационный бюллетень, если хотите больше статей, которые помогут вам стать лучшим разработчиком интерфейса.