Уязвимость путаницы AMF и Cross Site

Я только что получил удар по аудиту безопасности от Deloitte от имени SFDC. В основном мы используем flex и общаться через AMF. Для этого мы используем FluorineFX (в отличие от LCDS и Blaze). Нам говорят, что, поскольку AMF-ответ не закодирован и кто-то может манипулировать параметрами AMF и вставить Javascript, это уязвимость XSS. Я изо всех сил пытаюсь понять, как ответ AMF назад, который мог бы повторить переданный в JS в сообщении об ошибке, может быть выполнен браузером или что-то еще в этом отношении. Я довольно опытен с XSS с HTML и JS, но, увидев, что его отметили AMF, было немного сюрпризом. Я общаюсь с командой FluorineFx, и они тоже озадачены.

Я был бы удивлен, увидев, что библиотека AMF кодирует данные ответа, Фтор не уверен. Похоже, что такие приложения безопасности, как PortSwigger и IBM AppScan, включают этот тип теста в сундук для инструментов. Вы столкнулись с этой уязвимостью с AMF и можете ли вы объяснить, как может возникнуть проблема XSS? Просто любопытно. Мне нужно либо аргументировать свой выход из этого, если существует аргумент, либо исправить дыру. Учитывая использование AMF с помощью Flex, я подумал, что у вас может быть некоторое понимание.

Дополнительная информация...

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

--- От PortSwigger по вопросу ---

Спасибо за ваше сообщение. Я думаю, что ответ заключается в том, что это потенциально уязвимость, но не является тривиальной для использования.

Вы правы, проблема не возникнет, когда ответ будет потреблен Клиент AMF (если он не делает что-то немое), а скорее, если злоумышленник может спроектируйте ситуацию, когда ответ потребляется браузером. Наиболее браузеры будут игнорировать заголовок HTTP Content-Type и будут смотреть на фактический контент ответа, и если он будет выглядеть так, как HTML, обрабатывать его как таковой. Исторически сложилось, что многочисленные нападения существовали там, где люди встраивать содержимое HTML/JS в другие форматы ответов (XML, изображения, другие содержимое приложения), и это выполняется браузером как таковым.

Таким образом, проблема заключается не столько в формате ответа, сколько в формат запроса, требуемого для его изготовления. Это не тривиально для атакующему, чтобы спроектировать кросс-доменный запрос, содержащий действительное сообщение AMF. Аналогичная ситуация возникает с XML-запросами/ответами, которые содержат XSS-подобные поведение. Это, безусловно, возможно для создания действительного XML-ответа, который получает обработанный браузером как HTML, но проблема в том, как отправить необработанный XML в междоменная область HTTP-объекта. Это невозможно сделать, используя стандартную HTML-форму, поэтому злоумышленнику необходимо найти другую клиентскую технологию или сделай это. Исторически подобные вещи были возможны в разное время, пока они не будут исправлены поставщиками браузеров/плагинов. Я ничего не знаю что позволило бы в данный момент.

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

Я действительно думаю, что Burp должен помечать формат запроса AMF в качестве смягчения для этот вопрос, и понизите влияние на низкое - я исправлю это.

Надеюсь, что это поможет.

Приветствия PortSwigger

--- больше информации об аудите ---

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

HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
P3P: CP="CAO PSA OUR"
Content-Type: application/x-amf
Vary: Accept-Encoding
Expires: Tue, 06 Apr 2010 18:02:10 GMT
Date: Tue, 06 Apr 2010 18:02:10 GMT
Connection: keep-alive
Content-Length: 2595

......../7/onStatus.......
.SIflex.messaging.messages.ErrorMessage.faultCode.faultString
.faultDetail.rootCause.extendedData.correlationId.clientId.destination
.messageId.timestamp.timeToLive    body.headers.#Server.Processing..kFailed 
to locate the requested type 
com.Analytics.ca.Services.XXX5c2ce<script>alert(1)</script>9ccff0bda62..
....I506E8A27-8CD0-598D-FF6E-D4490E3DA69F.Id95ab281-d83b-4beb-abff-c668b9fd42d5
[email protected]...
.        DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes
...[SNIP]...

обратите внимание на "alert" script там... то, что они сделали, было добавлено в какой-то script закрытый JS к одному из передаваемых параметров, содержащему метод для вызова именно "com.Analytics.ca.Services. XXX". Таким образом, JS вернулась в сообщение об ошибке, но есть много вещей, которые должны произойти для этого JS, чтобы добраться где-нибудь близко к выполнению. В лучшем случае представляется косвенной угрозой.

- Последняя точка зрения аудитора безопасности -

Я обсуждал с более крупной командой, и мы все считаем его действительной атакой. Как отмечает PortSwigger в своем первом абзаце, теоретически, поскольку вы установили контент-тип в x-amf и надеетесь, что он не будет отображаться в браузере, большинство браузеров будут игнорировать этот запрос и в любом случае отображать его. Я думаю, что поставщики в значительной степени полагаются на то, что задан тип контента; однако популярные браузеры, такие как IE и некоторые версии Safari, будут игнорировать это.

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

Ответ 1

Кажется, вы ответили на свои собственные запросы.

Итак, у вас есть реализация на стороне сервера, которая принимает аргументы для вызова функции amf и включает входные данные где-то в возвращаемом выходе.

Я ценю, что это в значительной степени теоретическая атака, поскольку она включает в себя получение полезной нагрузки браузером, а не клиентом amf. Другие уязвимости в браузерах/плагинах могут потребоваться даже для включения этого сценария. Возможно, сообщение CSRF с помощью таких файлов, как gateway.php или аналогичное, сделало бы это довольно легко злоупотреблять, если браузер обработал вывод как html/js.

Однако, если вам не нужно, чтобы вызывающий абонент получал сквозные угловые скобки в ответ, просто html-encode или strip, и этот сценарий атаки исчезает.

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

Это во многом напоминает мне, что кросс-протокольная инъекция может использоваться для злоупотребления возможностями отражения протоколов, таких как smtp, для достижения XSS в браузере. См. http://i8jesus.com/?p=75

Ответ 2

Это не может быть инъекция JavaScript, как то, что в Flash Player интерпретирует JS? Вспышка была бы в восторге, если бы у нас была встроенная поддержка JS или даже поддержка json в проигрывателе. Нет функции eval для actionscript, не говоря уже о javascript
Предположим, они имели в виду, что вы могли бы вставить его с помощью ActionScript. Протокол AMF не отправляет код, он отправляет модели данных в виде примитивных типов или общих или типизированных объектов. Самое худшее, что может случиться, это то, что они анализируют вашу модель и добавляют дополнительные данные. Это было бы невероятно сложно сделать, поскольку вы не смогли бы вводить данные, но должны были бы анализировать все данные, добавлять новые данные, анализировать их и хранить заголовки AMF. Поскольку AMF использует в себе ссылки на сериализацию данных, что означает, что при дублировании типов объектов вам пришлось бы видеть первый объект. Ссылка - это смещение, что означает небольшую вероятность добавления кода, но только изменение значений для существующих параметров.
У удаленного объекта есть обработчик ответа, который проверяет типы данных и рассчитывает привязать эти типы данных к компонентам ui или тому, что делает ваш код. Если эти типы данных ошибочны, вы получите сообщение об ошибке. Если номер последовательности ответов AMF ошибочен, вы получите сообщение об ошибке. Если что-то не так хорошо сформировано в дейтаграмме amf, вы получите сообщение об ошибке.
Удаленный объект автоматически повторяет попытку. Если код "инъекции" длится дольше, Flex переадресует сообщение и сделает недействительным тот, который занял много времени.

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

Уэйд Арнольд

Ответ 3

Я не могу объяснить, как кто-то воспользуется этой "уязвимостью".

Но можете ли вы решить проблему с их удовлетворением, передав данные по HTTPS-соединению вместо прямого HTTP? Предполагая, что на вашем сервере установлен SSL-сертификат и включен HTTPS, это должно быть незначительное изменение в файле services-config.xml, который вы компилируете в ваше приложение Flex.

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

Ответ 4

Я думаю, что это действительный сценарий атаки. Связанная атака GIFAR, где JVM обманывается, чтобы рассматривать gif файл как банку. Кроме того, я не думаю, что выходное кодирование является правильным способом решения проблемы.

Предпосылка атаки заключается в том, чтобы обмануть браузер, думая, что AMF-ответ - HTML или Javascript. Это возможно из-за функции MIME Type Detection, которая по сути является браузером: "Разработчики могут не знать о типах контента, я буду играйте бога и (возможно, неправильно) выясните тип MIME".

Чтобы это сработало, необходимо сохранить true -

Злоумышленник должен иметь возможность выполнить запрос GET или POST на ваш сервер AMF с использованием методов HTML, таких как <script> или <frame> или тег <a>. Такие методы, как XmlHttpRequest или Flash или Silverlight, не учитываются.
Злоумышленник должен иметь возможность вставлять вредоносный контент в первые 256 или около того байтов ответа. Кроме того, этот вредоносный контент должен иметь возможность обмануть браузер, считая, что остальная часть ответа действительно javascript или html.

Итак, как вы его предотвращаете?

Лучше всего гарантировать, что злоумышленник не может сделать запрос в первую очередь. Очень простой и эффективный способ состоит в том, чтобы добавить заголовок HTTP-запроса при выполнении запроса AMF, проверить его существование на сервере и отклонить запрос, если он отсутствует. Значение может быть жестко закодированным значением и не обязательно быть секретным. Это работает, потому что нет известного метода добавления заголовка пользовательского запроса с помощью стандартных html-методов. Вы можете сделать это через XmlHttpRequest или flash или silverlight, но тогда браузер не будет интерпретировать контентный тип для вас, так что все в порядке.

Теперь я мало знаю о AMF, но если он уже добавляет заголовок запроса - тогда этот сценарий атаки невозможен. Если это не так, его тривиально добавить один.

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

Ответ 5

Я не знаю, насколько возможно изменить данные в потоке ответов AMF, но вы можете захотеть убедиться, что ваши конечные точки нельзя манипулировать посредством связи с браузером и/или JavaScript. Ознакомьтесь с этой статьей в разделе Вредоносных инъекций.