Что такое CSRF? И как это работает?

Подделка межсайтовых запросов (CSRF / XSRF), также известная как Sea Surf или Session Riding, — это уязвимость веб-безопасности, которая заставляет веб-браузер выполнить нежелательное действие. Соответственно, злоумышленник злоупотребляет доверием веб-приложения к браузеру жертвы. Это позволяет злоумышленнику частично обойти политику одного и того же происхождения, которая предназначена для предотвращения взаимодействия разных веб-сайтов друг с другом.

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

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

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

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

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

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

Что такое токены CSRF?
Маркер CSRF — это уникальное, непредсказуемое секретное значение, генерируемое серверным приложением и отправляемое клиенту для включения в последующие HTTP-запросы, выдаваемые клиентом. После выпуска токена, когда клиент делает запрос, сервер проверяет, содержит ли запрос ожидаемый токен, и отклоняет его, если токен отсутствует или недействителен. Токены CSRF могут предотвратить атаки CSRF, поскольку они не позволяют злоумышленникам формировать полностью действительные HTTP-запросы, которые они могут передать жертве. Злоумышленник не может определить или предсказать значение токена CSRF пользователя, поэтому любой запрос, который он генерирует, не должен приниматься приложением. Распространенные уязвимости CSRF: слабые места в реализациях токенов CSRF
Некоторые из наиболее распространенных уязвимостей CSRF вызваны ошибками в процессе проверки токена CSRF. Убедитесь, что ваш процесс CSRF не имеет ни одной из этих слабых сторон. Проверка зависит от наличия токена В некоторых приложениях процесс проверки пропускается, если токен не существует. Это означает, что злоумышленнику нужно только найти код, содержащий информацию о токене, и удалить его, а проверка токена не выполняется приложением. Токен CSRF не связан с пользовательским сеансом Некоторые приложения поддерживают пул токенов, и пока используется токен из пула, он принимается. Однако приложение не связывает определенные токены с конкретными пользователями. Злоумышленнику достаточно получить хотя бы один токен из пула, и он может использовать его для выдачи себя за любого пользователя. Изменения проверки токена с помощью метода HTTP В некоторых приложениях использование метода GET вместо метода POST приведет к неправильной работе проверки CSRF. Злоумышленнику просто нужно переключиться с POST на GET и легко обойти процесс проверки. Токен CSRF копируется в cookie Некоторые приложения не ведут учет уже используемых токенов. Вместо этого они копируют параметры запроса, связанные с каждым токеном, в файл cookie пользователя. В этой настройке злоумышленник может создать файл cookie, содержащий токен, используя ожидаемый формат приложения, поместить его в браузер пользователя, а затем выполнить CSRF-атаку. Запрос, отправленный браузером пользователя, будет проверен, поскольку он будет соответствовать вредоносному файлу cookie, предоставленному злоумышленником. Предотвращение CSRF: помимо токенов CSRF
Основной способ предотвратить CSRF — реализовать токены CSRF, избегая при этом слабых мест, описанных в предыдущем разделе. Вот дополнительные способы предотвращения атак CSRF. Используйте расширенные методы проверки, чтобы уменьшить CSRF
Злоумышленник может инициировать CSRF-атаку, когда определены все параметры, используемые в форме. Следовательно, чтобы предотвратить атаку CSRF, вы можете добавить дополнительный параметр с дополнительным значением, о котором злоумышленник не знает, но сервер требует проверки. Наиболее широко используемый метод предотвращения атак CSRF известен как токен анти-CSRF или токен синхронизатора. Когда пользователь делает какой-либо аутентифицированный запрос, отправляя форму, в этот запрос должен быть включен случайный токен. Затем веб-сайт проверит наличие этого токена перед обработкой отправленного запроса, и если токен отсутствует или значение неверно, запрос будет отклонен, и злоумышленник не сможет запустить CSRF-атаку.


Атрибут файла cookie SameSite
SameSiteАтрибут печенья, который определен в RFC 6265 бис , попытки уменьшить CSRF атак. Атрибут сообщает браузеру, когда можно отправлять файлы cookie с межсайтовыми запросами. SameSiteАтрибут печенья поставляется с тремя возможными значениями — Strict, Laxили None.
Большинство мобильных браузеров и все настольные браузеры поддерживают этот атрибут. Strict Значение может сказать браузеру , чтобы не посылать кук на сайт во время сеанса просмотра межсайтового. Это включает сеанс, который следует по обычной ссылке. Например, когда пользователь входит в GitHub и просматривает частный проект GitHub, размещенный корпорацией, браузер не отправляет cookie сеанса в GitHub, ограничивая доступ к проекту. Если нет необходимости разрешать внешним сайтам ссылаться на страницы транзакций, вы можете использовать этот Strict флаг . Однако, если вам нужно создать баланс между удобством использования и безопасностью, позволяя пользователям, направленным по внешним ссылкам, поддерживать сеансы входа в систему, вам следует использовать Lax значение по умолчанию . Обычно межсайтовые запросы, предоставленные в режиме Lax, считаются безопасными методами HTTP. Вот два примера файлов cookie, использующих атрибут cookie SameSite: Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax Защита CSRF на основе взаимодействия с пользователем
Как правило, механизмы защиты, требующие вмешательства пользователя, могут негативно повлиять на взаимодействие с пользователем. Однако в некоторых случаях, таких как финансовые транзакции, уместно и требуется реализовать этот тип техники. Например, вы можете добавить CAPTCHA, который помогает подтвердить, что это действительно человек, а не робот. Одноразовый токен также может гарантировать, что это пользователь, а не злоумышленник, использующий сеанс входа в систему. Токен обычно отправляется на адрес электронной почты или номер телефона пользователя, подтверждая информацию, ранее предоставленную пользователем. Кроме того, вы можете ввести повторную аутентификацию, которая поможет отличить сеанс CSRF от реального пользователя. Войти в CSRF
Многие разработчики игнорируют уязвимости CSRF в форме входа в приложение. Это связано с тем, что пользователь еще не аутентифицирован на этом этапе, поэтому разработчики предполагают, что риск CSRF отсутствует. Однако это предположение не всегда верно. Злоумышленники могут выполнять атаки CSRF при входе, которые могут иметь разное влияние в зависимости от приложения. Атаки CSRF входа в систему можно смягчить, создав предварительный сеанс (запуск сеанса перед аутентификацией пользователя) и запрос токена в форме входа в систему. Трудно смягчить CSRF входа в систему, если вы не можете доверять поддоменам (например, если вы разрешаете своим пользователям определять свои собственные поддомены). В этих случаях вы можете использовать строгую проверку заголовка реферера на уровне субдомена и пути, чтобы снизить риск CSRF в формах входа. Регулярно проводите тесты безопасности веб-приложений для выявления CSRF
Даже если уязвимости в веб-приложениях с атаками CSRF будут успешно устранены, обновления приложений и изменения кода могут сделать ваше приложение уязвимым для CSRF в будущем. Тестирование безопасности веб-приложений помогает вам постоянно сканировать и тестировать потенциальные слабые места безопасности в веб-приложениях, включая уязвимости CSRF. Nexploit от NeuraLegion помогает автоматизировать обнаружение и устранение многих уязвимостей, включая CSRF, на ранних этапах процесса разработки в веб-приложениях и API. Смещая DAST-сканирование влево и интегрируя их в SDLC, разработчики и специалисты по безопасности приложений могут обнаруживать уязвимости на раннем этапе и устранять их до того, как они появятся в рабочей среде. Nexploit выполняет сканирование за считанные минуты и обеспечивает нулевое количество ложных срабатываний, автоматически проверяя каждую уязвимость. Это позволяет разработчикам адаптировать решение и использовать его на протяжении всего жизненного цикла разработки

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *