首先我們要說的是，這個XSLT應該這么斷句：XSL-T。XSL指的是EXtensible Stylesheet Language，中文被很直白地翻譯成擴展樣式表語言。這種語言和xml有莫大關系：XSL之于XML相當于CSS之于HTML。HTML的每個元素都是預定義好的，比如<table>用來定義表格，瀏覽器也知道怎么識別這個標簽，此時CSS就能輕松地告訴瀏覽器該怎么顯示這個表格，然而由于XML里面的任何標簽都可以由程序員自己定義，所以需要一種XSL語言來描述如何顯示xml文檔。 這是一篇web安全文章，所以我們還是討論web相關的xsl安全，而支持在web上調用的是xslt v1，所以我們只討論version1發生的故事。
XSL包括三個部分：XSLT,XPath，XSL-FO。在安全領域，Xpath已經有前人的研究 (xpath injection)，而其他兩個幾乎無人問津。去年black hat黑客大會，終于有安全組織(IOActive)共享出自己的研究成果Abusing XSLT。 XSLT顧名思義，就是用來將XML轉換成XHTML或者是其他XML文檔。
當用XML來生成其他文檔時(e.g. xhtml)，XSL可以作為XML的引用。同時，XSL能夠內嵌到XML中發揮作用。
既然談XSLT安全，就得考慮他們的應用場景，這篇文章我們將從客戶端和服務端兩個方面分析XSLT實現的脆弱性。為了簡化討論，我們討論這幾個vendor的安全問題：
XSL對數學有自己的一套"獨特"的理解.我們先討論下它對大整數的處理：
比如
以及它的樣式
在諸如Xsltproc, Php, Perl, Ruby, Python, Safari, Chrome和Opera的libxslt系的處理軟件上，都會將上面這段xml解釋成這樣(chrome)：
問題很明顯了。
IOActive給出了他們研究調查的結果
同樣的，xsl的某些vendor對于隨機數的生成也是相當寫意的。而這個粗糙的vendor竟然還是應用最廣泛的libxslt，由于這個庫在生成隨機數的時候根本就沒有IV，所以每一次生成的隨機數，都是根本不變的。
讓我們將這個和PRG一起hi起來。。。
Safari的同源策略同樣可能被這個xml的樣式語言被破壞。
前面提到過，safari早就支持xml和xhtml的轉換。然而利用XSLT中的document(), 我們能夠帶著相應的cookies跨域讀取safari其他域內的資源。 這樣一來，我們就能可以通過 document()->value-of()/copy-of()這個流程被竊取到其他網站的用戶信息，最終，通過JavaScript發送給攻擊者。
我復現了ioactive的poc，然而結果卻和IOActive不一樣：
在IOActive的報告中
無疑成功取到了結果，成功BYPASS。
而我本地測試的時候卻在Safari控制塔得到這樣的提示
無疑是被sop ban掉了。
是apple修復了，還是利用姿勢不對，我將POC放到了文章最后，大家可以下載下來研究。
XSLT文檔在執行錯誤的時候回立即終止，它和他的兄弟XML類似，一小丁點錯誤就會拋出一個錯誤。然而錯誤信息也是能夠給攻擊者帶來一些有用的信息的。
XSLT提供了三個用來讀文件的方法
比如如下這個樣式表A
#!xml
<?xml-stylesheet type="text/xsl" href="2-9-Reading_Non-XML-Files.xsl"?>
<file>/etc/passwd</file>
和B
#!xml
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/">
<xsl:value-of select="document(file)"/> </xsl:template>
</xsl:stylesheet>
當B被解析時，會嘗試調用A表，而A表會試著用document()讀取/etc/passwd的內容,很明顯這不是一個xml文檔，所以不可能讀取，幸運的是在輸出的錯誤信息里面，我們可以看到目標文本的第一行被輸出了。
雖然只有第一行，但是第一行能夠獲取的銘感信息可不少了
這次，xsltproc php perl ruby這四種語言的所有方法（document() ，import() ，include()）都受到影響 （php不愧是世界上最好的語言，什么事兒都有他的份）