Безопасная эксплуатация apache, часть 3: атаки на основе создания межсайтовых запросов (xsrf)

Введение

Laravel позволяет легко защитить ваше приложение от атак с подделкой межсайтовых запросов (CSRF). Подделка межсайтовых запросов — тип атаки на сайты, при котором несанкционированные команды выполняются от имени аутентифицированного пользователя.


Laravel автоматически генерирует CSRF-токен для каждой активной пользовательской сессии в приложении. Этот токен используется для проверки того, что именно авторизованный пользователь делает запрос в приложение.

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

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

CSRF токены и JavaScript

При создании приложений, работающих на JavaScript, удобно, чтобы собственная JavaScript HTTP-библиотека автоматически прикрепляла CSRF-токен к каждому исходящему запросу. По умолчанию библиотека Axios настроена так, что передаёт заголовок , используя значение зашифрованной куки (см. файл ). Если вы не используете эту библиотеку, то вам нужно будет вручную настраивать это поведение для своего приложения.

Итак, как мне использовать куки для сохранения моих токенов OAuth 2.0?

Напомним, вот несколько способов хранения ваших токенов:

  • Вариант 1: Хранение Access Token в localStorage: но это выбор уязвим к XSS атакам.
  • Вариант 2: Хранение Access Token в cookie с httpOnly: но этот выбор будет уязвим к CSRF атакам, хотя его можно уменьшить, что лучше чем XSS.
  • Вариант 3: Хранение Refresh Token в cookie c httpOnly: это будет безопасно от CSRF атак, и немного лучше от XSS.

Мы рассмотрим, Вариант 3, так как он предлагает лучшие преимущества из трех вариантов.

Сохранять Access Token в памяти приложения а Refresh Token в cookie.

Шаг 1: Пользователь получает Access Token и Refresh Token когда проходит аутентификацию.

После аутентификации пользователя Сервер авторизации отдает пользователю access_token и refresh_token. Access_token может быть включен в тело ответа, refresh_token должен быть включен только в cookie.

Свойства токена в cookie:

  • Используйте флаг httpOnly, чтобы из JavaScript не было возможности прочитать его.
  • Используйте флаг secure = true, чтобы его можно было отправлять только через HTTPS.
  • По возможности используйте флаг SameSite = strict, чтобы предотвратить CSRF атаки. Но это можно использовать только в том случае, если у сервера авторизации тот же домен, что и у клиентского приложения. Если это не так, ваш Сервер авторизации должен установить нужные заголовки CORS в серверной части или использовать другие методы, чтобы гарантировать, что запрос на обновление токена может быть выполнен только авторизованными веб-сайтами.

Шаг 2: Сохраните Access Token в памяти

Хранение токена в памяти означает, что вы поместили этот токен доступа в соответствующую переменную в своем приложение. Да, это означает, что access token исчезнет, если пользователь переключит вкладки или обновит страницу. Вот зачем у нас есть refresh token.

Шаг 3: Обновляйте access token, используя refresh token

Когда access token token пропадет или срок его действия истечет, используйте серверное API для получения нового токена используя refresh token, который был сохранен в cookie в шаге 1, и будет включен в каждый запрос (то есть сервер получит его через cookie ). После получения нового access token сможете использовать его для своих запросов API.

Это означает, что ваш токен JWT может быть больше 4 КБ, и вы также можете поместить его в заголовок авторизации.

Лирическое отступление

Прежде всего, хотелось бы остановиться на основных заблуждениях связанных с CSRF:1. Подделка HTTP-запросов – новый тип уязвимостей. Это далеко не так. Теоретические размышления на тему подделки источника сообщений датированы 1988 годом (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), а практические примеры уязвимостей обсуждаются в Bugtraq как минимум с 2000 года (http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Сам термин введен Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) в 2001 году. 2. CSRF – это вариант Межсайтового выполнения сценариев (XSS). Единственное сходство между CSRF и XSS, это использование в качестве вектора атаки клиентов Web-приложений (Client-Side Attack в терминологии WASC http://www.webappsec.org/projects/threat/). Уязвимости типа CSRF могут эксплуатироваться совместно с XSS или «редиректорами» (http://www.securitylab.ru/analytics/283136.php), но представляют собой отдельный класс уязвимостей. 3. Уязвимость CSRF мало распространена и достаточно сложна в использовании. Данные, полученные компанией Positive Technologies в ходе работ по тестированию на проникновение и оценки защищенности Web-приложений показывают, что этой уязвимости подвержена большая часть Web-приложений. В отличие от других уязвимостей CSRF возникает не в результате ошибок программирования, а является нормальным поведением Web-сервера и браузера. Т.е. большинство сайтов, использующих стандартную архитектуру уязвимы «по умолчанию».

Защита

В примере выше атака использовала слабое звено авторизации.

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

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

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

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

Для каждого токена нужно дополнительное случайное значение, которое называют «соль» .

Формула вычисления токена:

Например:

  1. В сессии хранится , это значение создаётся один раз.
  2. Для нового токена сгенерируем , например пусть .
  3. .

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

Не зная , невозможно сгенерировать token, который сервер воспримет как правильный.


Далее, токен добавляется в качестве скрытого поля к каждой форме, генерируемой на сервере.

То есть, «честная» форма для отсылки сообщений, созданная на , будет выглядеть так:

При её отправке сервер проверит поле , удостоверится в правильности токена, и лишь после этого отошлёт сообщение.

«Злая страница» при всём желании не сможет сгенерировать подобную форму, так как не владеет , и токен будет неверным.

Такой токен также называют «подписью» формы, которая удостоверяет, что форма сгенерирована именно на сервере.

Подпись с полями формы

Эта подпись говорит о том, что автор формы – сервер, но ничего не гарантирует относительно её содержания.

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

При отправке формы сервер проверит подпись, подставив в неё известный ему и присланное значение . При несовпадении либо не тот (хакер), либо изменено.

Referer-based defenses against CSRF

Aside from defenses that employ CSRF tokens, some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application’s own domain. This approach is generally less effective and is often subject to bypasses.

Referer header

The HTTP Referer header (which is inadvertently misspelled in the HTTP specification) is an optional request header that contains the URL of the web page that linked to the resource that is being requested. It is generally added automatically by browsers when a user triggers an HTTP request, including by clicking a link or submitting a form. Various methods exist that allow the linking page to withhold or modify the value of the Referer header. This is often done for privacy reasons.

Validation of Referer depends on header being present

Some applications validate the Referer header when it is present in requests but skip the validation if the header is omitted.

In this situation, an attacker can craft their CSRF exploit in a way that causes the victim user’s browser to drop the Referer header in the resulting request. There are various ways to achieve this, but the easiest is using a META tag within the HTML page that hosts the CSRF attack:

LAB CSRF where Referer validation depends on header being present

Validation of Referer can be circumvented

Some applications validate the Referer header in a naive way that can be bypassed. For example, if the application simply validates that the Referer contains its own domain name, then the attacker can place the required value elsewhere in the URL:

If the application validates that the domain in the Referer starts with the expected value, then the attacker can place this as a subdomain of their own domain:

LAB CSRF with broken Referer validation

Related Security Activities

How to Prevent CSRF Vulnerabilities

See the CSRF Prevention Cheat Sheet for prevention measures.

Listen to the OWASP Top Ten CSRF Podcast.

Most frameworks have built-in CSRF support such as Joomla, Spring, Struts, , .NET and others.

Use OWASP CSRF Guard to add CSRF protection to your Java applications. You can use CSRFProtector Project to protect your php applications or any project deployed using Apache Server. There is a .Net CSRF Guard at OWASP as well, but it’s old and doesn’t look complete.

John Melton also has an excellent blog post describing how to use the native anti-CSRF functionality of the OWASP ESAPI.

Пробиваем периметр

В декабре прошлого года компания Symantec опубликовала отчет о «новой» атаке, под называнием «Drive-By Pharming», которая, по сути, является вариантом эксплуатации CSRF. Злоумышленник выполняет в браузере пользователя некий «волшебный» JavaScript, изменяющий настройки маршрутизатора, например устанавливающего новое значение DNS-сервера. Для выполнения этой атаки необходимо решить следующие задачи: — сканирование портов с помощью JavaScript; — определение типа Web-приложения (fingerprint); — подбор пароля и аутентификация с помощью CSRF; — изменение настроек узла с помощью атаки CSRF.

Техника сканирования определения доступности Web-сервера и его типа по с помощью JavaScript проработана достаточно хорошо и сводится к динамическому созданию HTML-объектов (например, img src=), указывающие на различные внутренние URL (например, http://192.168.0.1/pageerror.gif). Если «картинка» была успешно загружена, то по тестируемому адресу расположен Web-сервер на базе Microsoft IIS. Если в ответ было получена ошибка 404, то порт открыт и на нем работает Web-сервер. В случае если был превышен таймаут – сервер отсутствует в сети или порт заблокирован на межсетевом экране. Ну и в остальных ситуациях – порт закрыт, но хост доступен (сервер вернул RST-пакет и браузер вернул ошибку до истечения таймаута). В некоторых ситуациях подобное сканирование портов из браузера пользователя может проводиться без использования JavaScript (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html). После определения типа устройства злоумышленник может попробовать заставить браузер пользователя сразу послать запрос на изменение настроек. Но такой запрос будет успешен только в случае, если браузер пользователя уже имеет активную аутентифицированную сессию с устройства. Иметь под рукой открытую страницу управления маршрутизатором — дурная привычка многих «продвинутых» пользователей. Если же активной сессии с интерфейсом управления нет, злоумышленнику необходимо пройти аутентификацию. В случае если в устройстве реализована аутентификация на основе форм, никаких проблем не возникает. Используя CSRF в POST, серверу отправляются запрос на авторизацию, после чего с него загружается изображение (или страница) доступная только аутентифицированным пользователям. Если изображение было получено, то аутентификация прошла успешно, и можно приступать к дальнейшим действиям, в обратном случае – пробуем другой пароль. В случае если в атакуемом устройстве реализована аутентификация по методу Basic, задача усложняется. Браузер Internet Explorer не поддерживает возможность указать имя пользователя и пароль в URL (например, http://user:pass@test.ptsecurity.ru). В связи с этим для выполнения Basic-аутентификации может использоваться метод с добавлением HTTP-заголовков с помощью Flash, описанный в статье Amit Clein. Однако этот метод подходит только для старых версий Flash, которые встречаются все реже и реже. Но другие брузеры, например Firefox дают возможность указать имя пользователя и пароль в URL, и могут быть использованы для аутентификации на любом сервере, причем это можно сделать без генерации сообщения об ошибке в случае выбора неверного пароля. Пример сценария для «тихой» аутентификации по методу Basic, из блога Stefan Esser приведен ниже.

Firefox HTTP Auth Bruteforcing

Рис. 5. Аутентификация Basic в Firefox

В корпоративной среде, где зачастую используются механизмы SSO, например, на базе домена Active Directory и протоколов Kerberos и NTLM эксплуатация CSRF не требует дополнительных усилий. Браузер автоматически пройдет аутентификацию в контексте безопасности текущего пользователя. После того как аутентификация была пройдена, злоумышленник с помощью JavaScript передать запрос, изменяющий произвольные настройки маршрутизатора, например адрес DNS-сервера.

Conclusion

Cookies are intrinsically vulnerable to CSRF because they are automatically sent with each request. This allows attackers to easily craft malicious requests that lead to CSRF. Although the attacker cannot obtain the response body or the cookie itself, they can perform actions with the victim’s elevated rights. The impact of a CSRF vulnerability is related to the privileges of the victim. While sensitive information retrieval is not the main scope of a CSRF attack, state changes may have an adverse effect on the exploited web application.

Fortunately, it’s easy to test if your website or web application is vulnerable to CSRF and other vulnerabilities by running an automated web scan using the Acunetix vulnerability scanner, which includes a specialized CSRF scanner module. Take a demo and find out more about running CSRF scans against your website or web application.

How to Prevent Cross-site Request Forgery (CSRF) – Generic Tips

Cross-site Request Forgery (CSRF) vulnerabilities are dangerous partly because preventing them is not that easy. There are multiple methods that you can use to avoid them but not all are effective in all scenarios. In addition to two methods that are considered the most effective, there are certain general strategic principles that you should follow to keep your web application safe.

To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with CSRF vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page.

CSRF vulnerabilities do not apply to public content. They are only dangerous when authentication is required. Therefore, you can ignore this risk if you only have public content on your website. However, if you have a web application with user accounts, be extra vigilant. Treat CSRF as a major risk if you have an e-commerce application.

Anti-CSRF tokens are considered the most effective method of protecting against CSRF. Use a tested implementation such as CSRFGuard for Java or CSRFProtector for PHP to implement your anti-CSRF tokens. Develop your own mechanism only if there is no existing one for your environment.

Set the SameSite attribute of your cookies to Strict. If this would break your web application functionality, set the SameSite attribute to Lax but never to None. Not all browsers support SameSite cookies yet, but most do. Use this attribute as additional protection along with anti-CSRF tokens.

Step 5: Scan regularly (with Acunetix)

CSRF vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build.

Frequently asked questions

What is CSRF?

Cross-site Request Forgery (CSRF) vulnerabilities occur when a web server receives a malicious request from a trusted browser. An attacker can create a malicious link that lets them, for example, transfer money from a user’s online bank account to another account. The attacker can use social engineering to make the user click this link. Because the user is already logged in, the server executes the action using their account.

How common is CSRF?

According to our research, CSRF vulnerabilities are becoming less common but they are still present in one in every three tested websites and web applications. However, a year before they were present in one in every two, so the situation is clearly improving.

How dangerous is CSRF?

CSRF does not look dangerous at first glance because the attacker may only do what the user could do. However, the attacker may use this vulnerability to take over user accounts, for example, or to execute fraudulent transactions. Therefore, the potential impact of CSRF might be very serious.

How to detect CSRF?

The best way to detect CSRF is by using an automated web vulnerability scanner. Acunetix is fully able to detect all CSRF vulnerabilities, both in third-party software and in your own applications. It also does it much faster than any other product on the market.

How to protect against CSRF?

The most effective method of protecting against CSRF is by using anti-CSRF tokens. The developer should add such tokens to all forms that allow users to perform any state-changing operations. When an operation is submitted, the web application should then check for the presence of the correct token. The other effective method is the use of the SameSite attribute for cookies, but not all browsers support this method yet.

A CSRF Attack Example Using a GET Request

HTTP GET is by its very nature meant to be an idempotent request method. This means that this HTTP method should not be used to perform state changes. Sending a GET request should never cause any data to change. However, some web apps still use GET instead of the more appropriate POST to perform state changes for operations such as changing a password or adding a user.

When the victim clicks the link provided by the attacker using social engineering, the victim is directed to the attacker’s malicious site. This website executes a script that triggers the user’s web browser to send an unsolicited request. The victim is not aware that this unsolicited client-side request is being sent. However, server-side it appears as if the user sent the request because it includes cookies used to verify that the user is who they say they are.

Let’s imagine that www.example.com processes fund transfers using a GET request that includes two parameters: the amount that is to be transferred and the identifier of the person to receive the money transfer. The below example shows a legitimate URL, which will request that the web app transfers 100,000 units of the appropriate currency to Fred’s account.

The request includes a cookie that represents the authenticated user so there is no need to define the source account for the transfer. If a normal user accesses this URL, they need to authenticate so that the application knows the account from which funds are to be withdrawn. Using CSRF, we can trick a victim into sending the request that the attacker wants while authenticated as the victim.

If the exploited application expects a GET request, the attacker can include a malicious tag on their own website. Instead of linking to an image, this tag sends a request to the bank’s web app:

<img data-fr-src="http://example.com/transfer?amount=1000000&account=Fred" />

Under normal circumstances, the user’s browser automatically sends cookies that are related to that website. This causes the victim to perform a state change on behalf of the attacker. In this case, the state change is a transfer of funds.

Note that this example is very simple and it does not necessarily reflect the real-world but it shows very well how CSRF attacks work. However, similar vulnerabilities based on GET appeared in popular software in the past (read more about it on ).

How does CSRF work?

For a CSRF attack to be possible, three key conditions must be in place:

  • A relevant action. There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user’s own password).
  • Cookie-based session handling. Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
  • No unpredictable request parameters. The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.

This meets the conditions required for CSRF:

  • The action of changing the email address on a user’s account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user’s account.
  • The application uses a session cookie to identify which user issued the request. There are no other tokens or mechanisms in place to track user sessions.
  • The attacker can easily determine the values of the request parameters that are needed to perform the action.

With these conditions in place, the attacker can construct a web page containing the following HTML:

If a victim user visits the attacker’s web page, the following will happen:

  • The attacker’s page will trigger an HTTP request to the vulnerable web site.
  • If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used).
  • The vulnerable web site will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

Note

Although CSRF is normally described in relation to cookie-based session handling, it also arises in other contexts where the application automatically adds some user credentials to requests, such as HTTP Basic authentication and certificate-based authentication.

Методы защиты

Существует 3 метода использования токенов для защиты web-сервисов от CSRF атак:

  • (Statefull)
  • (Stateless)
  • (Stateless)

Synchronizer Tokens

Простой подход, использующийся повсеместно. Требует хранения токена на стороне сервера.

Суть:
  1. При старте сессии на стороне сервера генерируется токен.

  2. Токен кладется в хранилище данных сессии (т.е. сохраняется на стороне сервера для последующей проверки)

  3. В ответ на запрос (который стартовал сессию) клиенту возвращается токен.

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

    В случае, если ответ возвращается для JS приложения, токен можно передавать в header (часто для этого используют )

  4. При последующих запросах клиент обязан передать токен серверу для проверки.

    При рендере контента сервером токен принято возвращать внутри POST данных формы.

    JS приложения обычно присылают XHR запросы с header (), содержащим токен.

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

    Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:
  • Защита от CSRF на хорошем уровне

  • Токен обновляется только при пересоздании сессии, а это происходит, когда сессия истекает

    Во время жизни одной сессии все действия будут проверяться по одному токену.

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

  • Бесплатная поддержка multi-tab в браузере.

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

Double Submit Cookie

Этот подход не требует хранения данных на стороне сервера, а значит, является Stateless. Используется, если вы хотите уметь быстро и качественно масштабировать свой Web-сервис горизонтально. Идея в том, чтобы отдать токен клиенту двумя методами: в куках и в одном из параметров ответа (header или внутри HTML).

Суть:
  1. При запросе от клиента на стороне сервера генерируется токен. В ответе токен возвращается в cookie (например, ) и в одном из параметров ответа (в header или внутри HTML).

  2. В последующих запросах клиент обязан предоставлять оба полученных ранее токена. Один как cookie, другой либо как header, либо внутри POST данных формы.

  3. При получении запроса небезопасным методом (, , , ) сервер обязан проверить на идентичность токен из cookie и токен, который явно прислал клиент.

    Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:

  • Stateless CSRF защиту.

  • Необходимо учитывать, что поддомены могут читать cookie основного домена, если явно это не запрещать (т.е. если cookie установлена на , то её могут прочитать как , так и ).

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

  • Нюансы зависят от реализации

Encrypted Token

Так же как и Double Submit, является Stateless подходом. Основная — если вы зашифруете надежным алгоритмом какие-то данные и передадите их клиенту, то клиент не сможет их подделать, не зная ключа. Этот подход не требует использования cookie. Токен передаётся клиенту только в параметрах ответа.

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

Суть:
  1. При запросе от клиента на стороне сервера генерируется токен.

    Генерация токена состоит в зашифровке фактов, необходимых для валидации токена в дальнейшем.

    Минимально необходимые факты — это идентификатор пользователя и timestamp. В ответе токен возвращается в одном из параметров ответа (В header или внутри HTML).

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

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

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

    Если расшифровать не удалось либо факты не совпадают, считается, что запрос подвергся CSRF-Атаке.

На выходе имеем:
  • Stateless CSRF защиту

  • Нет необходимости хранить данные в cookie

  • Нет нюансов с поддоменами.

Same-Site Cookies

CSRF attacks are only possible because cookies are always sent with any requests that are sent to a particular origin related to that cookie (see the definition of the same-origin policy). You can set a flag for a cookie that turns it into a same-site cookie. A same-site cookie is a cookie that can only be sent if the request is being made from the origin related to the cookie (not cross-domain). The cookie and the request source are considered to have the same origin if the protocol, port (if applicable) and host (but not the IP address) are the same for both.

A current limitation of same-site cookies is that unlike for example Chrome or Firefox, not all current browsers support them and older browsers do not work with web apps that use same-site cookies ( for a list of supported browsers). At the moment, same-site cookies are better suited as an additional defense layer due to this limitation. Therefore, you should only use them along with other CSRF protection mechanisms.

Пример использования

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

Рис. 1. Отправка сообщения

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

Рис. 2. Атака CSRF

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

Рис. 3. Логика работы CSRF

Таким образом, атака с использованием CSRF заключается в использовании браузера пользователя для передачи HTTP-запросов произвольным сайтам, а уязвимость – в отсутствии проверки источника HTTP-запроса. Приведенное в примере приложение использует HTTP-метод GET для передачи параметров, что упрощает жизнь злоумышленнику. Однако не стоит думать, что использование метода POST автоматически устраняет возможность проведения атак с подделкой HTTP-запроса. Страница на сервере злоумышленника может содержать готовую HTML-форму, автоматически отправляемую при просмотре страницы.

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

В обзоре Billy Hoffman приведены различные методы сетевого взаимодействия с помощью Javascript. Все они, включая XmlHttxmpquest (в некоторых ситуациях), могут быть задействованы для реализации атак CSRF.

Надеюсь, что сейчас читателю уже понятно основное отличие CSRF от XSS. В случае с XSS злоумышленник получает возможность доступа к DOM (Document Object Model) уязвимой страницы, как на чтение, так и на запись. При выполнении CSRF атакущий имеет возможность передать запрос серверу с помощью браузера пользователя, но получить и проанализировать ответ сервера, а тем более его заголовок (например, Cookie) уже не сможет. Соответственно, «Подделка HTTP-запросов» позволяет работать с приложением в режиме «только на запись», чего впрочем, вполне достаточно для выполнения реальных атак.

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

Рис. 4. Пример эксплуатации CSRF в форуме

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


С этим читают