FLAX Systematic Discovery of Client-side Validation Vulnerabilities in Rich Web Applications-NDSS 阅读笔记
1、攻击情景描述
作者发现了几种由于客户端的应用程序没有合理使用不安全数据而造成的代码注入、命令注入以及错误判断网络域名等攻击，并取名为：CSV (Client-side vulnerability)。文章以现实中广泛应用的跨域通信为背景，对其中存在的安全隐患进行了详细的分析。
接下来我将以CNN网页对Facebook的引用为实例来对CSV涉及到的几类漏洞进行描述。下图是一个实例截屏，Facebook中的用户在CNN浏览新闻时随时记录下自己对感兴趣新闻的体会并同步更新到自己的Facebook主页中去。此类应用在现今得到了广泛的应用，像国外著名的twitter社区、YouTube社区以及国内的校内网和开心网都包含有此类应用。此类应用包含有大量的JavaScript代码以及丰富的跨领域交互，由于这两点，客户端应用程序极容易因对不可信输入未进行充分验证而导致相关的攻击。
Facebook网站使用了HTML教程5的跨文档消息传输(Cross Document Messaging)的功能，此功能用postMessage支持基于web的实时消息传递，使得Facebook用户可以同CNN用户进行聊天。作者所举出的实例模拟了Facebook的这一场景，下面的描述中将把作者在文中所举的实例映射到现实存在的网站中。
两个来自不同域的用户(Facebook & CNN)可以在Fingure 1 的场景下进行自由聊天，其消息通过postMessage进行传输并且双方在接收到对方发送过来的消息时都会对消息的来源以及消息本身进行验证。假设来自Facebook的用户是A ,他是发送一方，A使用sendChatData()函数将信息发送出去。代码如下：
|
1: var chatURL = "http://www.facebook.com/";
2: chatURL += "chat_child.html";
3:…
4: ...
5: function sendChatData (msg) {
6: var StrData = "{\"username\": \"QQ\", \"message\": \"" Hi "\"}";
7: popup.postMessage(StrData, chatURL);
} |
再假设来自CNN的用户是B，她现在是接收方，B使用的应用程序将对发送方的域名进行验证，验证通过后将在用户B的聊天窗口中显示用户A发送过来的消息，同时用户B会向Facebook发送一条确认信息。B的验证代码如下：
|
1:function ParseOriginURL (url) {
2: var re=/(.*?):\/\/(.*?)\.com/;
3: var matches = re.exec(url);
4: return matches;
5:}
6:
7:function ValidateOriginURL (matches)
8:{
9: if(!matches) return false;
10: if(!/http?/.test(matches[1]))
11: return false;
12: var checkDomRegExp = /facebook/;
13: if(!checkDomRegExp.test (matches[2])) {
14: return false; }
15: return true; // All Checks Ok
16:}
|
17:// Parse JSON into an array object
18:function ParseData (DataStr) {
19: eval（DataStr);
20:}
21:function receiveMessage(event) {
22: var O = ParseOriginURL(event.origin);
23: if (ValidateOriginURL (O)) {
24: var DataStr = ’var new_msg =(’ +
25: event.data + ’);’;
26: ParseData(DataStr);
27: display_message(new_msg);
29: var backserv = new XMLHttpRequest(); ...;
30: backserv.open("GET","http://www.facebook.com/srv.php?
call=confirmrcv&msg="+new_msg["message"]);
31: backserv.send();} ... } ...
32: window.addEventListener("message",
receiveMessage,...); |
首先,此应用程序代码存在对阈名的不完全检测,在ParseOriginURL()函数中，函数同时允许任何域名为www.evilfacebook.com的域名通过验证。在本文作者为这种不完全验证的的漏洞起名为Origin Mis-attribution。接下来应用程序处理输入消息时使用eval（)函数为new_msg赋值。但是因为eval函数在执行时对数据没有进行充分的验证，所以这样就极易引起DOM-bassd XXS攻击。作者在本文管这种攻击叫做Code injection。此类漏洞还可以因此Cookie信息泄露等常规漏洞。在最后(Line29-31)应用程序利用XMLHttpRequest()动态创建了与Facebook通信的URL，这种URL可以被Facebook段的脚本进行检测并执行相应命令，但如果此时用户B被攻击者控制，攻击者则可以通过命令注入(Command injection)的方法进行破坏。
2、检测方法描述
本文中作者提出了检测的几大关键步骤，它们分别为：动态污点检测(Dynamic taint analysis)、程序片构建(Acceptor Slice)以及sink-aware fuzzing。
上图是作者给出的一个Flax的一个框架结构图，灰色框架左侧是Flax的输入部分，它包括一个初始的良性输入(如何确定？)和应用程序本身。接下来Flax将在相同的程序路径中探索与初始的良性输入等价的其他输入来寻找输入进critical sink的未经充分验证的数据流。
在第一步，作者使用初始输入执行应用程序并且在字符级 (什么是字符级？还有其他什么级别？区别是什么？) 来进行动态污点检测(此时算不算动态检测？)。动态污点检测分析辨别出所有使用不可信数据的critical sink. 这步的分析主要辨认出了每个潜在的危险的数据流的两类信息：critical sink的类型以及影响critical sink的部分输入输入。特别的，作者还提取出了输入数据的范围，在此范围的输入数据是怎样的数据参数可以直接影响一个sink操作。所有对数据操作的状态信息都直接依赖于圈定范围内的数据，包括path conditions，都被抽取入一个源程序的可执行片(slice)中(程序切片技术？)。作者之所以创建这样的一个独立的程序片是因为此时每个程序片是独立于源程序的但是却可以接受与源程序等价的输入数据以及它的执行空间与源程序是相同的。
在第二步，作者对每个程序片分别进行fuzzing来发现能够引起bug的输入。作者对不同的sink设计了不同的测试实例
3、场景模拟
实验模拟了利用postMessage进行消息传递的过程，窗口A向窗口B通过postMessage()发送的消息被窗口B解析后引起的DOM-based XSS攻击。经过调研目前只有Internet Explorer 8, Firefox 3, Opera 9, 和 Safari nightly支持这一功能。
实验通过构建两个来自不同域名的iframe嵌套在一个页面来进行CSV实验模拟，两个iframe分别为A、B。实验过程为当用户将鼠标移动到B区域中时，iframe B将向iframe A 通过postMessage函数一个消息。A接收到消息后利用eval（)函数分析传递过来的消息，在此时eval（)函数执行了消息中的” alert(\'DDDDDDDDDDDDDDD\”,造成了一个Code injection漏洞。同时，还可以引起Cookie泄露等安全隐患。
此实验验证了作者提出的Code injection和Cookie-sink vulnerability漏洞。
4、总结
本文最主要贡献之处在于作者设计了一个可以化简JavaScript代码的框架程序以及提出了对于XMLHttpResponse此类具有返回流的操作的检测方法。
