Можно ли получить flash src после редиректа или элемент внутри тега embed/object/iframe (кросс-доменный)?

Содержание

Вопрос или проблема
Ответ или решение
Сценарий
Как это может произойти
Защита от кражи токена

Вопрос или проблема

URL example.com/auth автоматически перенаправит пользователя (HTTP 302) на example.com/signed_in.SWF?token=SENSITIVE.

Может ли злоумышленник украсть токен, используя javascript или flash, в следующем примере? Как?

<!DOCTYPE html>
<html>
    <body>
         <embed id="foo" src="https://example.com/auth"></embed>
         <!-- Помните, что example.com/auth будет автоматически перенаправлен на example.com/signed_in.SWF?token=SENSITIVE -->

         <!-- Код для кражи значения токена должен быть здесь -->

    </body>
</html>

Имейте в виду:

Вышеупомянутое .html размещено на cross-domain.com, так же как и любые другие файлы, участвующие в “решении” (.swf, .js, .html, .css и т.д.);
У вас нет контроля над example.com;
У вас нет контроля над signed_in.SWF;
Вы можете изменить тег <embed> на <object> или
<iframe>;

Если пользователь аутентифицирован и злоумышленник сумеет использовать какую-либо уязвимость для внедрения javascript (или flash) на страницу, то да, злоумышленник сможет украсть секретный токен. Он просто отправляет запрос с помощью AJAX к конечной точке /auth и считывает URL перенаправления, который возвращается. Это стало возможным благодаря добавлению параметра responseURL к запросам XHR.
После этого они могут делать с токеном все, что захотят.

Чтобы избежать этого, вы могли бы использовать какой-нибудь метод возврата токена, к которому javascript и flash не могут получить доступ (например, установка HTTPOnly cookie). Таким образом, злоумышленник может отправлять запросы на конечную точку, сколько угодно, но не сможет получить доступ к cookie с помощью javascript.

Если вам нужно, чтобы токен был читаем вашим javascript, то у вас возникнет более сложная проблема.

Ответ или решение

Да, возможна кража токена после редиректа или извлечение элемента внутри тега <embed>, <object> или <iframe> в условиях кросс-домена. Давайте рассмотрим ситуацию более подробно.

Сценарий

В вашем примере URL example.com/auth автоматически перенаправляет пользователя (HTTP 302) на example.com/signed_in.SWF?token=SENSITIVE. Если злоумышленник пытается извлечь токен из этого файла с помощью JavaScript или Flash, это возможно при наличии определённых условий.

Обратите внимание на следующее:

Кросс-доменные запросы: В обычных условиях браузер блокирует кросс-доменные запросы из-за политики одноместоного источника (Same-Origin Policy). Однако если злоумышленник использует уязвимость, чтобы внедрить код на страницу или воспользоваться устаревшими механизмами, это может открыть доступ к содержимому.
Возможность получения URL переадресации: Использование XMLHttpRequest (XHR) с поддержкой свойства responseURL позволяет получить финальный URL, на который произошёл редирект. Если злоумышленник сможет сделать AJAX-запрос к /auth, он сможет увидеть редирект и, соответственно, получить доступ к токену.

Как это может произойти

Вложение внешнего ресурса: Использование тега <embed>, <object> или <iframe> для встраивания редиректированного контента.
```
<embed id="foo" src="https://example.com/auth"></embed>
```
Использование вредоносного JavaScript: Если злоумышленник воспользуется уязвимостью на стороне клиента, он может внедрить JavaScript, который делает AJAX-запрос, чтобы получить результирующий URL.
```
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://example.com/auth', true);
xhr.onload = function() {
   if (xhr.status === 200) {
       console.log(xhr.responseURL); // Получаем URL после редиректа
       // Здесь можно извлекать токен
   }
};
xhr.send();
```

Защита от кражи токена

Чтобы предотвратить кражу токена, рекомендуется использовать следующие подходы:

HTTPOnly куки: Установите токен в виде HTTPOnly куки, что сделает его недоступным для JS. Это защитит токен от кражи с помощью JavaScript, даже если злоумышленник может выполнять код на странице.
Сигналы и токены: Реализуйте использование короткоживущих токенов или одноразовых токенов, которые действуют только в течение ограниченного времени или одного сеанса.
CORS: Настройте политики кросс-доменных ресурсов на сервере (CORS), чтобы ограничить доступ из ненадежных источников. Вы можете разрешить только определённые домены для обращения к вашему ресурсу.
Тайм-ауты сессий: Установите короткие тайм-ауты для сессий пользователей и токенов для минимизации вероятности злоупотреблений.

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