AMF и межсайтовый скриптинг путаница из-за уязвимости

Question

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

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

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

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

--- От 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
..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

1. Это не может быть инъекция JavaScript, поскольку что в Flash Player будет интерпретировать JS?Флэш-сообщество было бы в восторге, если бы в плеере была встроенная поддержка JS или даже json.Для ActionScript не существует функции eval, не говоря уже о javascript

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

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

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

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

Уэйд Арнольд

Answer 2

Вы, похоже, ответили здесь на свои вопросы.

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

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

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

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

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

Answer 3

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

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

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

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

Итак, как вы можете предотвратить это?

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

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

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

Answer 4

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

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

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

Answer 5

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