Чувствительность к ошибкам AMF и кросс-сайтов

Question

Я только что получил зачет по аудиту безопасности от 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-запросами/ответами, которые содержат поведение X12-типа . Конечно, можно создать корректный ответ XML, который получает , обработанный браузером как HTML, но проблема заключается в том, как отправить необработанный XML в междоменный объект HTTP. Это невозможно сделать с использованием стандартной HTML-формы, , чтобы злоумышленнику было необходимо найти другую клиентскую технологию или прикосновение браузера до . Исторически подобные вещи были возможны в разное время, , пока они не были исправлены поставщиками браузеров/плагинов. Я ничего не знаю , что позволило бы на данный момент.

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

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

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

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

--- подробнее об аудите ---

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

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 
..fluorine.I04165c8e-f878-447f-a19a-a08cbb7def2a.A.q..@............ 
.  DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes 
...[SNIP]... 

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

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

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

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

Answer 1

Вы, кажется, ответили на ваши собственные вопросы здесь.

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

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

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

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

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

Answer 2

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

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

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

Answer 3

1. Это не может быть инъекция JavaScript, как то, что в Flash Player интерпретирует JS? Вспышка была бы в восторге, если бы у нас была встроенная поддержка JS или даже поддержка json в проигрывателе. Нет никакой функции eval для actionscript, не говоря уже о javascript

2. Предположим, они имели в виду, что вы могли бы придать ей ActionScript. Протокол AMF не отправляет код, он отправляет модели данных в виде примитивных типов или общих или типизированных объектов. Самое худшее, что может случиться, это то, что они анализируют вашу модель и добавляют дополнительные данные. Это было бы невероятно сложно сделать, поскольку вы не смогли бы вводить данные, но должны были бы анализировать все данные, добавлять новые данные, анализировать их и хранить заголовки AMF.Поскольку AMF использует ссылки в своей сериализации данных, что означает, что при дублировании типов объектов вам пришлось бы видеть первый объект. Ссылка - это смещение, что означает небольшую вероятность добавления кода, но только изменение значений для существующих параметров.

3. Удаленный объект имеет обработчик ответа, который проверяет типы данных и рассчитывает привязать эти типы данных к компонентам ui или тому, что делает ваш код. Если эти типы данных ошибочны, вы получите сообщение об ошибке. Если номер последовательности ответов AMF ошибочен, вы получите сообщение об ошибке. Если что-то не совсем сформировано в дейтаграмме amf, вы получите сообщение об ошибке.

4. Удаленный объект автоматически повторяет попытку. Если код «инъекции» длится дольше, Flex переадресует сообщение и сделает недействительным тот, который занял много времени.

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

Wade Арнольд

Answer 4

Я не знаю, как можно это изменить данные в пределах АИФ поток ответа, но вы можете гарантировать, что ваши конечные точки не могут управляться через общение с браузером и/или JavaScript. Проверьте это article под кодом Вредоносные данные впрыска раздел.

Answer 5

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

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

Для того, чтобы это работало, следующий нужно держать верно -

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

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

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

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

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