誰在看我的噗？第三回：弔詭的過濾函式

（本文感謝 armorize parser 團隊 Chris, Eric, Steven, Wing 與 ASF 團隊 Kuon 的意見）

泡咖啡或茶的藝術，我稍微接觸過一些，很有意思，每一個部分都很講究，從水、豆子或茶葉、到器具、時間等，每一個環節的掌握，決定了最後享受的品質。

有在品嚐的朋友都知道，其中常被忽略但是卻是關鍵者，就是過濾方式。以茶來說，不好的濾網可以直接喝到金屬的味道，所以有些人會把沖泡器的濾網拆除，寧可茶中有些茶葉。以咖啡來說，紙濾網會有味道，另外吸油能力太強，會讓咖啡少了原本的濃郁。很多人因此喜歡用金（或K金）濾網，雖然貴，但是金穩定，比較不會有異味，泡出來的咖啡跟紙濾網喝起來完全不一樣。可是金濾網除了價格高以外，很多廠商的技術不到位，濾得不乾淨，常讓咖啡渣漏到咖啡中，那就大大破壞興致了。就連自己做豆漿，最難的部分還是過濾機制的設計。要做一個好的過濾器，並不容易。

在Web資安中亦是如此。前面我分享了「誰在看我的噗？第一回」與「誰在看我的噗？第二回」兩篇，裡頭提用了噗浪的一些跨站腳本攻擊(XSS)漏洞來做範例。當初噗浪雖然有過濾CSS中的「expression」，但是改其中一個字的大小寫，例如「eXpression」，就繞過噗浪的過濾機制了。

回報給噗浪後，改好了，我這次，恩，的確改好了，現在不論是「Expression」、「eXpression」或「exPression」，都會被阻擋起來。於是我就試了下面這個字串：

「ex/**/pression」

IE的CSS parser，會將「/*」與「*/」當成是註解，將中間的字串都拿掉，於是「ex/**/pression」還是變成了「expression」，會執行javascript。測試發現噗浪並沒有偵測這種形式（pattern），於是又回報他們。以下是一些可能的變形：

「ex/**/pression」、「ex/**/p/**/ression」、「e/**/x/**/p/**/r/**/e/**/s/**/s/**/i/**/o/**/n/**/」

噗浪改好後，我測試，嗯，真的改好了，以上這些形式都會被阻擋起來，確定改好了。接下來我測試「ex/*armorize*/pression」，發現繞過了噗浪的檢查。原來噗浪沒有注意到，「/*」與「*/」中間可以加任何的字串，於是又回報他們。以下是一些可能的變形：

「ex/*armorize*/pression」、「e/*A*/x/*B*/p/*C*/r/*D*/e/*E*/s/*F*/s/*G*/i/*H*/o/*I*/n」、「e/*/*/*****///"hello"*/*/*/xpression」

噗浪改好後，我測試，嗯，真的改好了，以上這些形式都會被阻擋起來，確定改好了。接下來我想，該不會噗浪的過濾機制，是以「行」為單位的吧？於是我測試：

ex/*

*/pression

中間換行，發現又繞過去了。註解中間雖然有換行，IE還是會執行expression後面帶的javascript，可是噗浪是以「行」為單位進行過濾，所以又被我繞過去了。於是我又回報他們。以下是一些可能的變形：

ex/*

armorize

*/pression



ex/*

XSS**/**/*/pression

噗浪改好後，我測試，嗯，真的改好了，以上這些形式都會被阻擋起來，確定改好了。這是我仔細想，噗浪是如何做過濾機制的呢？最直覺的作法，應該是用正規表示法（regular expression）來過去，並採以下步驟：

1. 以整個CSS為單位，移出「/*」與「*/」以及中間的字串（因為是註解）
2. 偵測「expression」的各種大小寫形式

恩，那麼，如果我用以下的一段CSS呢？

X{"/*"} expression() X{"*/"}

上面這樣的CSS，對於IE來說，由於文法是可以接受的，另外「/*」與「*/」被包在雙引號內，所以IE不會視為是註解。可是對於此時噗浪的過濾機制來說，過濾機制的第一步會將「/*」與「*/」以及中間的字串移出，所以經過第一步後，噗浪看到的是：

X{""}

沒有「expression」的存在，故判定是合法沒有惡意的CSS而接受。實際上測試，正是如此，而我這個新的CSS攻擊，又繞過了噗浪此時的過濾機制。於是趕緊回報噗浪，噗浪改好後，我測試，嗯，真的改好了，這種形式都會被阻擋起來，確定改好了。可是我仔細一想，不對，目前最新的過濾機制應該是這樣，那麼如果我寫這樣，應該又可以繞過，結果果然。於是我回報，不過到這次，已經不是那麼容易可以改了，甚至要考慮一下以正規表示法（regular expression）為基礎的CSS過濾機制，到底有沒有辦法做到安全？過了兩星期問題還是沒修好，我這邊就不探討實際的字串了。

算一算到目前為止，攻擊已經變形了七代了。如同Twitter Mikeyy蠕蟲變形了多代一樣，如果今天同樣有駭客要攻擊噗浪，那麼已經變形七代了，可以做七波的攻擊，每一次攻擊都可以是蠕蟲或是偷受害者的cookie（然後以該身份登入噗浪）。另外很有趣的是，噗浪的第二代過濾機制，其實是可以阻擋第六與第七代的變形攻擊的，因為該機制只是單純地檢查有無「expression」的各種大小寫形式存在。可是之後，噗浪為了要應付第三代攻擊形式（「ex/**/pression」），而導致改進後的過濾機制反而會被第六與第七代攻擊形式繞過（X{"/*"} expression() X{"*/"}）。

從噗浪的一系列攻守中我們可以獲得以下結論：

1. 設計一個正確的過濾機制是不容易的。找到漏洞不表示可以正確修補。
2. 修補的過程中，很有可能導致新的漏洞產生。

在這邊順便問一下，有沒有網友有興趣寫一個CSS的過濾函式？如果願意與我們一起研究，我們可以一起公開一套針對CSS的開放源碼過濾函式。

CSS的過濾函式，真的可以用單純的正規表示法（regular expression）之字串比對機制來完成嗎？

我們先來研究一下，到底IE是如何處理CSS的。第一，「ex/**/pression」==「expression」到底是否合於CSS2的文法（grammar）與語意（sematics）？我們看一下W3C對於CSS2.1的定義中，註解（comments）這段：

Comments begin with the characters "/*" and end with the characters "*/". They may occur anywhere between tokens, and their contents have no influence on the rendering. Comments may not be nested.

「註解以 "/*" 開始，以 "*/" 結束，可以存在於任兩個 token 之間...」既然是任兩個token之間，那麼「ex/**/pression」根本不應該等於「expression」，而要被分成「ex」與「pression」兩個token。實際上W3C對於CSS2.1的文法定義也反映了這點。

如果是單純用標準的lexer與parser來處理CSS的話，ex/**/pression一般來說會被切成兩個token，而要認識「ex/**/pression」為「expression」的話，需要特別花功夫重組token。我認為IE不是這樣做的。我認為IE目前的CSS處理模組，包含了一個或多個的preprocessor，然後才餵給一組lexer與parser。前面的preprocessor可能也是用lexer與parser組成，但更可能只是用正規表示法（regular expression）之字串比對機制來完成。這樣的設計造就了在IE裡，「ex/**/pression」==「expression」的錯誤。

可是說IE錯了，沒有用，因為「ex/**/pression」在IE中就是會執行javascript，攻擊就是會成功。所以我們這篇探討的過濾機制，重點變成了，「如何了解各家瀏覽器對於CSS的處理機制，並實做一個模擬函式，來做資安過濾」。

這個就難了，因為各種歷史因素加上一開始CSS的定義並不明確，各家瀏覽器對於CSS的處理可說各顯神通，怪招一堆。舉個例子，雖然CSS中並無定義，但是以往非IE瀏覽器（FF、Safari、Chrome）對於「//」這個註解掉本行的語法，也是支援的；IE則不支援。可是到了IE8時，突然決定在「IE8標準模式」下時，跟其他非IE瀏覽器一樣，支援「//」。於是以下CSS，用非IE瀏覽器瀏覽，以及用IE8在「IE8標準模式」下瀏覽，背景會是紅色的（支援「//」），但是用IE<8或IE8在「IE7標準模式」瀏覽，背景會是藍色的（不支援「//」）：

body {

  background-color:red; 

  //  background-color:blue;

}

那麼我們在寫過濾器時，到底要不要把「//」當成行註解呢？

又舉一個例子，以下這個CSS，在IE5/MAC，以及在IE8 beta 1上，中間的「@import」會被執行，但是在其他瀏覽器，包含IE8正式版中，則會被當成註解：

/*\*//*/

  @import...

/**/

這主要跟lexer/parser或proprocessor在處理CSS時所採用的優先順序（operator precedence）有關。IE5/MAC與IE8 beta 1 是如此解讀的（資料來源：stopdesign.com）

(1)的「/*」被視為是註解的開始，(2)的「\」將(3)的「*」給escape掉了，所以一直到(4)的「*/」才被視為是註解的結束。(5)的@import在註解外，而(6)的「/*」與「*/」被視為一對註解的開始與結束。

其他的瀏覽器則是如此解讀：

(1)的「/*」被視為是註解的開始，(2)的「\」被視為在註解中所以沒有作用，(3)的「*/」被視為註解的結束，(4)的「/*」被視為第二個註解的開始，(5)的「@import」被視為註解內，而最後(6)的「*/」為結束註解，於是「@import」不會被執行。

反過來看，我們的過濾器如果需要正確識別「ex/**/pression」以及類似變形，就必須正確判斷註解的開始與結束，可是各家瀏覽器在CSS處理機制實做上的不同，增加了我們過濾器的困難度。

事實上，這些各家瀏覽器在CSS實做上的不同，不但大家早就熟悉，還早就被當成「功能」來使用--利用這些不同來有效判斷不同的瀏覽器，讓不同瀏覽器讀取不同的CSS檔。這種技巧叫做「CSS Hack」或「CSS Filter」，大家可以參考 Wikipedia 中的定義，這邊就不多著墨。

但是由於這些差異被當成「功能」來使用，讓錯的一方也不能修正，因為如果修正了，反而很多網站的顯示就要變得不正確了。於是目前瀏覽器廠商只能推出新一代瀏覽器（IE5 -> IE6 -> IE7）時，才對這些bug進行修正。

為何瀏覽器的lexer/parser或preprocessor這麼糟糕？事實上，很久以前大家不就發現，資料庫的SQL處理器也是一樣糟嗎？「se/**/lect」這種SQL注入（SQL injection）手法大家應該都很常用。事實上，MS SQL伺服器的T-SQL處理器以及MySQL的SQL處理器，在這方面也都是有名的...說複雜好了。

雖然攻擊手法並不新，但是從噗浪的七代實驗可以知道，老人雖然很熟，新人還是會不斷地重複採地雷，正確地過濾惡意字串，並非易事。

瀏覽器/資料庫的lexer/parser/proprocessor處理器的複雜與不穩定，不但增加了資安的過濾函式的難度，也同時增加了WAF（Web應用程式防火牆、web application firewall）在實做與設定上的難度。

這些也就是為何，在情況允許之下，程式中應盡量避免過濾機制，而採用參數化機制。你的過濾機制，真的安全嗎？

作者Wayne為阿碼科技一員
系列第一篇：誰在看我的噗？第一回：DOM沙盒 vs 跨網站腳本漏洞（XSS）
系列第二篇：誰在看我的噗？第二回：IE執行模式 vs 跨網站腳本漏洞（XSS）
系列第三篇：（本篇）誰在看我的噗？第三回：弔詭的過濾函式
系列第四篇：誰在看我的噗？第四回：我噗誰在看！