Введение в практическую безопасность (2019)/Атаки на клиента веб-приложения - CSRF & XSS: различия между версиями

Материал из SecSem Wiki
Перейти к навигации Перейти к поиску
(Новая страница: «При атаке на клиента атакующий пытается вынудить '''браузер''' клиента ('''жертвы''' атаки) в…»)
(нет различий)

Версия 21:06, 17 марта 2019

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

Аутентификация

Существуют различные способы, которыми сервер может отличать, от какого клиента пришёл запрос.

Сессии на основе Cookie

Наиболее часто используемый способ аутентификации в современный веб-приложениях - это cookie (википедия, MDN). Работает это очень просто: в HTTP-ответе сервер отправляет заголовок Set-Cookie: SOMEUNIQUEVALUE, где SOMEUNIQUEVALUE - какое-то значение, уникальное для этой сессии. Получив это значение, браузер запомнит его и будет отправлять на этот сайт с каждым последующим запросом в заголовке Cookie (кстати, что именно значит "на этот сайт" очень интересно - кука будет отправлена если обращаться на другой TCP, порт а также по дефолту на все поддомены. В доке MDN есть про это). По тому что в запросе в заголовке Cookie будет это уникальное значение сервер будет понимать, что этот запрос относится к этой сессии, в том числе, если эта сессия принадлежит какому-то клиенту, что этот запрос от этого клиента. Для примера можно залогиниться на http://pwnitter.stands.course.secsem.ru/ (для этого надо сначала зарегиться). При логине на сервер отправится такой запрос

POST /login HTTP/1.1
Host: pwnitter.stands.course.secsem.ru
...
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
...

login=test&password=test

В ответ сервер присылает заголовок Set-Cookie: session=eyJ1c2VyIjoidGVzdCIsInVzZXJfaWQiOjN9.D3Az7g.wEXp46Qb6OpIPnwIYspV_cIUgug; Path=/. Все последующие запросы клиента содержат заголовок с этим значением Cookie: session=eyJ1c2VyIjoidGVzdCIsInVzZXJfaWQiOjN9.D3Az7g.wEXp46Qb6OpIPnwIYspV_cIUgug. В качестве эксперимента можно убрать этот загловок или изменить его (скажем, удалить половину) и посмотреть, как изменится ответ сервера при запросе относящихся к конкретному пользователю ресурсов (к примеру GET /api/get).

Также можно попробовать залогиниться на каком-нибудь реальном сайте (скажем, vk.com или mail.ru) и посмотреть (например через Burp) на заголовки HTTP-запросов и ответов.

Другие варианты аутентификации

Протокол HTTP сам по себе поддерживает несколько вариантов аутентификации через заголовок Authorization, также при использовании HTTPS возможна аутентификация по клиентскому сертификату, наконец, возможны более простые варианты, например, по IP-адресу.

Все перечисленные варианты обладают одним общим свойством - любой запрос, отправленный аутентифицированным браузером на сайт, будет автоматически обладать аутентифицирующим признаком (например содержать аутентифицирующий токен - куку/учетные данные/...) и будет считаться сервером как сделанный от имени этого клиента. Это удобно, но это может помочь атакующему, если тот сможет вынудить браузер жертвы отправить запрос. (Кстати, таким свойством обладает не любой способ аутентификации. К примеру, если аутентифицировать запросы по кастомному заголовку или кастомному параметру запроса, то их браузер автоматически не пошлёт - правда, в случае кастомного заголовка всё взаимодействие с сервером придётся осуществлять через JavaScript, в целом, программирование сайта будет несколько сложнее).