Что возможно с XSS с Flashvars? Как это предотвратить?

Question

В последнее время клиент был обеспокоен тем, что его SWF-файл "небезопасен", потому что XML-путь исходил от Flashvars. Мне кажется, это не является проблемой, так как SWF отображает только изображения / текст и несколько ссылок на кнопки. Я могу понять, как кто-то может найти путь к swf и добавить удаленный путь XML, чтобы добавить javascript к целям URL url, но на самом деле какой ущерб это может сделать? Например. они могут измениться

http://mysite.com/theflash.swf?xmlpath=xml/thedata.xml

к этому

 http://mysite.com/theflash.swf?xmlpath=http://dodgysite.com/thechangeddata.xml

Очевидно, что они могли бы создать поддельный HTML-файл обертки вокруг этого, но я до сих пор не понимаю, как они могли бы сделать что-нибудь вредное с этим. Я что-то упустил?

Мой следующий вопрос: как лучше всего предотвратить это?
До сих пор в моем классе проверки XSS:

• удалить строку и удалить все пробелы или переносы строк (\ t, \ n, \ r)
• проверить строку для любого из следующее (asfunction :, javascript :, event :, vbscript:)
• проверка абсолютного или относительного пути в поисках (http или https)
• если абсолютное значение, проверьте, что домен так же, как основной фильм.

Большая часть этого процесса я обнаружил в этой статье: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_02.html

Есть ли лучший способ, чем этот?
Что еще можно сделать, чтобы предотвратить XSS во флэш-памяти?

Answer 1

Я думаю, вы уже хорошо поработали!

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

Например: если XML содержит пути к изображениям, вы можете убедиться, что файлы заканчиваются на .jpg / .png и загружены из правильного каталога.

Answer 2

Черный список - ужасное решение.Неявное предположение состоит в том, что «я смогу отлавливать все атаки, если буду искать эти подстроки»;это часто неправильно:

1. Вы добавляете на свой сайт функцию «загрузки» (wiki / bug tracker / что угодно), которая вставляет загруженные файлы в / userUploads /.С этим связано множество проблем с безопасностью, но, скажем, вам удается отфильтровать «небезопасные» файлы (HTML, содержащий JavaScript и т. Д.).Отлично.
2. Атакующий загружает файл XML.Ваш скрипт загрузки считает его «безопасным», потому что он не HTML и не содержит тегов.
3. Злоумышленник отправляет кого-то на http://example.com/theflash.swf?xmlpath=../../../../userUploads/innocent.xml.

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

I думаю потенциально безопасный вариант - убедиться, что путь начинается с "xml /" и нене содержит "/../", но это все еще ужасное "решение".

Лучшим вариантом является белый список: имя файла может содержать только [a-z0-9_-].Вы генерируете путь с помощью «xml / $ filename.xml».Это работает при условии, что вы не создаете «test.xml».

Еще лучше - просто поддерживать отображение имен на пути, например, «data» сопоставляется с «xml / data.xml»,но «эксплойт» не имеет сопоставления, поэтому возвращает ошибку.Это означает, что вы не можете добавлять файлы так же легко, но также означает, что пользователь не может указать произвольные пути.

РЕДАКТИРОВАТЬ: Подобные проблемы с безопасностью возникают из-за неожиданного взаимодействия между различными частямисистема («все файлы в файловой системе могут быть доверенными») или неверные предположения («разрешение URL даст URL-адрес под одним и тем же« каталогом »», «пути объединения не могут перемещаться вверх по иерархии каталогов», «все имена файлов нормальные"," проверка, существует ли каталог, не может его создать ").Я привел пример;без сомнения, есть и другие.

Если вам нужно изменить конфигурацию для каждого развертывания, тогда ... используйте конфигурацию!foo.swf может получить config.xml, который содержит список разрешенных путей.Лучше сделать так, чтобы config.xml отображал имя страницы на путь XML.

В общем случае раскрытие деталей реализации, таких как «все пути совпадают xml/.*\.xml», является неприглядным, нарушением наслоения и выглядит как очень похоже на плохая безопасность.