Flash應用安全規范
責編：admin ｜2015-02-09 17:57:56前言
flash作為一款瀏覽器的第三方插件，是對瀏覽器功能的延伸，已經是web必不可少的元素。但是這種延伸必然帶來不安全的因素，相比于安全性已經得到磨 練的瀏覽器來說，flash絕對是客戶端安全的一個軟肋（包括在比較神秘的漏洞挖掘領域，也是這個觀點），同樣flash在頁面展示時所含有的豐富功能， 在某些情況下你甚至可以認為它等同于javascript，甚至更為危險。瀏覽器所貫徹的域安全策略被flash所打破，客戶端所做的種種過濾也同樣被 flash所打破（只要你還使用flash）。但是flash也已經感覺到了這個問題，并且時時在改進，在設計上也引入了一些比較好的安全機制，恰當的使 用這些安全機制可以避免你的應用程序遭到攻擊。80sec將從實際的一些經驗總結出一些供參考的flash使用規范，規范將從服務端應用程序的安全設計和 客戶端的flash安全使用兩個角度來說明這個問題。
安全的服務端flash安全策略
應用程序安全設計的時候應該秉承最小化原則，在flash的大部分應用中，由于功能需求就經常需要跨域獲取數據。域安全是瀏覽器安全的基本策 略，flash作為瀏覽器的擴展允許跨域獲取數據就從根本上打破了瀏覽器的安全性。flash以flash文件存儲域名作為它的當前域，如果需要獲取其他 服務器上的數據就會發生跨域行為，而且該跨域行為會繼承用戶瀏覽器里的認證信息，限制不嚴格時將導致安全漏洞，打破我們的整個客戶端安全模型。flash 在跨域時唯一的限制策略就是crossdomain.xml文件，該文件限制了flash是否可以跨域獲取數據以及允許從什么地方跨域獲取數據。通過嚴格 控制該策略文件我們就可以為應用程序安全和功能上尋找到一個平衡點。
典型的crossdomain.xml文件策略
1.<？xml version="1.0"？>
2.<cross-domain-policy>
3.<allow-access-from domain="*.80sec.com" />
4.</cross-domain-policy>
其中最主要的策略是allow-access-from表示允許來自哪些域的跨域請求，早期的flash允許從其他位置載入自定義的策略文件，目前最新版 的flash在接受自定義的策略文件之前會去檢查主目錄的crossdomain.xml來判斷是否接受自定義策略文件。該選項由
<site-control permitted-cross-domain-policies="by-content-type"/>
節點控制，不加該選項時，默認情況下flash不加載除主策略文件之外的其他策略文件，即只接受根目錄里的/crossdomain.xml。這對于防止 利用上傳文件來定義自己策略文件的攻擊非常有效。為了在某些條件下需要啟用其他策略文件，我們需要設置permitted-cross-domain- policies，設置為by-content-type時將會只允許http頭為text/x-cross-domain-policy的策略文件，當 為all時則允許所有的text/xml等格式的策略文件。
應用程序在設計的時候按照最小化原則
1.將文件上傳和應用的域名分開，防止通過上傳flash文件直接獲得域操作的權限。
2.對于不需要使用flash的應用嚴禁在域名目錄下部署flash策略文件。
3.對于有功能需求的應用遵循最小化原則將域名限制到最小的范圍，有安全需求的應用應該明確允許跨域請求的域，禁止直接使用*通配符，這將導致跨域訪問權限的擴散。
4.##譬如http：//sns.80sec.com/crossdomain.xml
就對權限設置過泛，可能導致其他安全策略的繞過（如繞過csrf等等）
5.對于有高安全需求的應用，在限制域名的前提下，將需要被flash訪問的應用限制到指定目錄，并且在flash內指定策略文件到該目錄以將所有訪問權限限制到單一目錄。
如果login.80sec.com中的某個功能如login需要對所有域名開放，如果配置根目錄crossdomain.xml
1.<？xml version="1.0"？>
2.<cross-domain-policy>
3.<allow-access-from domain="*" />
4.</cross-domain-policy>
不是一個好的策略因為他不只會開放login同時會開放如chgpassword等其他的服務給用戶，我們需要配置主策略文件
1.<？xml version="1.0"？>
2.<cross-domain-policy>
3.<site-control permitted-cross-domain-policies="all"/>
4.</cross-domain-policy>
然后自定義策略文件到一個目錄如/flash/crossdomain.xml
1.<？xml version="1.0"？>
2.<cross-domain-policy>
3.<allow-access-from domain="*" />
4.</cross-domain-policy>
并且將login應用部署到/flash/目錄，用戶的訪問將被限制到/flash/下面，無法對其他功能進行操作。
安全的客戶端flash安全規范
控制好flash安全策略并不是安全的全部，這樣只能保證服務端的安全。由于一些功能上的原因，譬如為了追求良好的用戶體驗，為了讓無聊的用戶可以在頁面 共享各種flash，為了把頁面做得華麗麗的，我們往往需要在頁面內容里嵌入flash，這個時候安全性就會被拋到一邊（我們還是建議如果不需要的話還是 少用這種動態的東西）。我們在一個頁面引入一個flash時，一般的做法是下面這種形式：
1.<object classid="clsid：d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http：//fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8，0，0，0" name="Main" width="1000" height="600" align="middle" id="Main">
2.<embed flashvars="site=&sitename=" src='Loading.swf？user=453156346&key=df57546b-c68c-4fd7-9f9c-2d105905f132&v=10950&rand=633927610302991250' width="1000" height="600" align="middle" quality="high" name="Main" allowscriptaccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http：//www.macromedia.com/go/getflashplayer" />
3.</object>
由于flash的強大，并且在頁面元素里基本等同于script這種危險的標簽，對于這點，flash已經有所考慮，在引入flash的時候flash提 供了控制屬性，其中與安全最為關鍵的是AllowScriptAccess屬性和allowNetworking屬性。其中 AllowScriptAccess控制flash與html頁面的通訊，可選的值有：
1.always //對與html的通訊也就是執行javascript不做任何限制
2.sameDomain //只允許來自于本域的flash與html通訊，這是默認值
3.never //絕對禁止flash與頁面的通訊
默認情況下的選項是sameDomain，這個時候某些場景下看起來也是足夠安全了，但是我們還是能看到經常有程序允許將這個選項設置為always，而 即使是sameDomain也不是在所有場景下都安全的，考慮如論壇這樣的程序，上傳和展現都是在同一個域的情況下，就不存在任何安全性可言了，我們強烈 建議該選項為never，如果你選擇sameDomain或者always我也希望你清楚自己在做什么。
allowNetworking控制flash與外部的網絡通訊，可選的值包括：
1.all //允許使用所有的網絡通訊，也是默認值
2.internal //flash不能與瀏覽器通訊如navigateToURL，但是可以調用其他的API
3.none //禁止任何的網絡通訊
但是最近更新的flash客戶端貌似是只要AllowScriptAccess被設置那么包括navigateToURL都不能使用，在官方文檔上也只看 到簡簡單單的一句道歉，但是這樣的確從某些程度上提高了嵌入flash的安全性。但是即使不跳轉，我們還是能做很多事情，當我們將flash直接嵌入到頁 面又沒有設置allowNetworking時，我們就可以做csrf之類猥瑣的事情，更要命的是這種形式的csrf支持POST請求，referer來 源為swf文件所在地址或者為空，同時發送所有cookie而不像圖片那些只能發送session cookie，而且基本沒有任何的痕跡，基本秒殺那些沒有做token保護的csrf防范了，之前的開心網犯的就是這個錯誤，我們強烈建議該選項為 none，如果你不選擇這個建議你也要清楚自己在做什么。
flash安全的checklist
檢查自己的網站的根目錄的crossdomain.xml
##好孩子：
1.http：//mail.google.com/crossdomain.xml
2.http：//youa.baidu.com/crossdomain.xml
3.http：//www.adobe.com/crossdomain.xml
##壞孩子：
1.http：//www.youku.com/crossdomain.xml
2.http：//www.renren.com/crossdomain.xml
3.http：//www.taobao.com/crossdomain.xml
我承認所有的利用都離不開場景，有的時候如果實在沒有辦法修改這個crossdomain.xml（這個情況的確存在，譬如某些變態功能的需要），那么就 可以考慮在應用程序獲取數據時對提交的數據做校驗，譬如當請求的頭里包括x-flash-version時，就可以判定來源是flash而不予響應，但這 的確不是一種優美的解決辦法。
##檢查自己網站引入flash的代碼
有AllowScriptAccess和allowNetworking么？如果沒有，那是不是我這個應用設計已經很安全足夠抵御各種攻擊了？
如果想針對安全問題做測試，fly_flash是方便的攻擊客戶端的好伙伴（參見開心網蠕蟲），如果想針對第一種錯誤的策略文件突破csrf等做測試就還得自己寫源碼了。另外，良好的設計的最大敵人就是壞的實現，原因也是各個程序之間天然的心之壁壘，猜猜
1.<embed allowscriptaccess="always" allowscriptaccess="never" height=384 width=454 src=http：//www.80sec.com/fly_flash.swf？sec80=http：//www.80sec.com/fly_flash.txt&x.swf wmode="transparent" loop="false" autostart="false">
這段代碼的結果是什么？
1.EMail： jianxin#80sec.com
2.Site： http：//www.80sec.com
3.Date： 2009-07-25
下一篇：數據庫安全的三個層面