Краткий ответ: Flash Player имеет множество функций для предотвращения XSS-атак, но они встроены в сам плеер, поэтому нет никакой конкретной библиотеки, которую вам нужно использовать.Если вы не вызываете какие-либо API, связанные с безопасностью, и не размещаете файлы конфигурации на своем сервере, то с точки зрения безопасности вы уже используете самые ограниченные доступные параметры.(Предполагая, что вы также обращаете внимание на то, как вы используете пользовательский ввод.)
В целом, API, которые могут привести к уязвимостям XSS, как правило, отключаются в ситуациях XSS, если вы не активируете их активно.Например, если HTML-страница на вашем сайте загружается во флэш-файл с другого сайта, и этот флэш-контент пытается, скажем, сделать вызовы javascript на вашей странице, эти вызовы будут заблокированы по умолчанию, если вы их не разрешите.Точно так же, если флэш-контент на вашем сайте загружается в компоненты с другого сайта, эти компоненты не смогут самоанализировать их родителей, если вы не вызовете API, чтобы позволить им это сделать.Существуют также различные ограничения на то, что происходит, когда другой сайт пытается загрузить Flash-контент с вашего сайта без вашего разрешения.
Для всех деталей я настоятельно рекомендую этот превосходный обзор:
С учетом всего сказанного, поскольку вы также спрашивали о санации входных данных пользователей, стоит отметить, что, поскольку AS3 не имеет эквивалента eval команда никогда не вызывает вопроса о том, что пользовательский ввод выполняется как скрипт.Однако любой пользовательский ввод, который относится к загружаемому контенту, может быть вектором атаки XSS.(Например, если вы добавляете строку пользовательского ввода в URL-адрес, который вы затем загружаете, пользователь может заставить ваш сайт загружаться со своим вредоносным SWF-файлом.) Но такой случай ничем не отличается от ситуации, когда вы загружаете в 3-ий день.-партии SWF, а потом кто-то заменяет ее вредоносным контентом.Следовательно, в контексте Flash защита от XSS-атак заключается не столько в санации пользовательского ввода, сколько в том, чтобы убедиться, что внешне загруженному контенту не предоставлено разрешение на запуск, как если бы ему доверяли локально.
И далее, поскольку часто бывает полезно или необходимо ослабить ограничения по умолчанию, если вы хотите сделать что-то интересное со сторонним контентом (например, флеш-аватарами, компонентами или даже рекламными баннерами), в этих ситуациях важночтобы администратор сайта мог понять, что они разрешают и как не допустить, чтобы смягченные ограничения выявили уязвимость.