AMF и Перекрестный Сайт, пишущий сценарий беспорядка уязвимости

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

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

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

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

---От PortSwigger по проблеме---

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

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

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

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

Я действительно думаю, что Отрыжка должна отметить формат запроса 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. Сервисы. XXX'. Таким образом JS возвратился в сообщении об ошибке, но существует много вещей, которые должны были бы произойти для этого JS для получения где угодно близко к выполнению. Кажется косвенной угрозой в лучшем случае

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

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

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