The Will Will Web

在多年以前 SSL 第二版 (v2) 就已經被證實有編碼加密方面的瑕疵，因此駭客很輕易的就能對 SSL v2 加密過的封包進行反解，或可能會透過中間人攻擊(Man-in-the-middle attack)手法加害於你的網站用戶，因此大多數的資安掃瞄軟體皆會建議在伺服器上關閉 SSL v2 的協定，以確保用戶端透過 SSL ( HTTPS ) 連上網站伺服器時是安全的連線。

我原本以為從伺服器上關閉 SSL v2 可能會導致部分舊版的瀏覽器無法登入網站，但理解 SSL 協定的握手過程 (Handshake) 後，就知道不會導致客戶無法連線的問題，甚至想不到不停用 SSL v2 的理由。

SSL/TLS 大致的運作過程如下：

• 瀏覽器對特定網站發出 https 連線請求，雙方根據 SSL 所規範的 handshake 機制
• 瀏覽器會先送出一個 "ClientHello" 訊息給網站伺服器，裡面包含了瀏覽器所支援的 Protocol 資訊
• 例如: TLS v1.2 , v1.1, v1.0, SSL v2, SSL v3 等等。
• 備註: Internet Explorer 瀏覽器從 IE7 開始就預設關閉了 SSL v2 協定，其他像 Firefox, Google Chrome 等叫的出來的瀏覽器也都預設關閉 SSL v2 協定。
• 當網站伺服器收到此 "ClientHello" 訊息後，會回應 "ServerHello" 訊息給瀏覽器，其內容會從瀏覽器發出的 "ClientHello" 中所有 Protocol 中最安全的版本且伺服器也支援的 Protocol 予以回應。
• 由於是從最高安全等級做出比對，一般狀況下通常都會利用 TLS v1.0 或是 SSL v3 來取得雙方的認可，進而約定於之後的連線過程所使用的 Protocol 版本。

由上述運作過程可知，若網站伺服器關閉 SSL v2 協定，並不代表瀏覽器就會無法使用 SSL 協定，因為通常還有其他版本可供挑選。

若以舊版的瀏覽器 IE6 來說，IE6 本身就同時支援 SSL v2 與 SSL v3 協定，在與網站伺服器 handshake 時通常會自動選擇 SSL v3 協定進行後續的連線，但如果用戶端被惡意植入木馬或被駭客修改了機碼設定，導致用戶端被強迫使用 SSL v2 進行安全連線，便會導致使用者遭受中間人攻擊或機密資訊被擷取等風險，所以無論如何 SSL v2 這種不安全的加密協定還是建議從伺服器端停用比較好，寧願讓使用者連不上網，也不願意看到使用者因為你的網站而受害！

如果你的網站使用者或客戶因為你將網站伺服器的 SSL v2 給關閉而導致連不上網站的情況，那你也可以強烈的懷疑客戶的主機是否已經被駭客入侵或被植入木馬了。再換句話說，如果你不管用戶端安不安全的話，那又何必花錢採購 SSL 憑證保護使用者的網路安全呢？

關閉 SSL v2 的方式

若要取消網站伺服器 (IIS5 ~ IIS7) 對 SSL v2 的支援，必須修改系統機碼才行，步驟如下：
（註：此方法適用 x86 與 x64 架構，也適用於 Windows Server 2003 ~ Windows Server 2008 R2）

1. 建立一個 Disable_IIS7_SSLv2.reg 登錄檔，檔案內容如下：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

2. 透過滑鼠右鍵進行合併機碼的動作

3. 合併完成後需將伺服器重新開機，重新開機後自然就會生效。

驗證 SSL v2 已關閉的方法

若要驗證伺服器是否設定正確，最簡單的方法就是利用網站伺服器 SSL 支援版本檢測工具，只要輸入你的網站網址，再按下 [SSL-check] 按鈕即可進行檢測，如下圖示：

如果你的檢測結果是如下圖這樣，在 Available SSL2 ciphers 沒有任何資料，那就代表你已經完成關閉 SSL v2 的設定。

如果你的 IIS 網站沒有做出任何修改，預設還是會支援 SSL v2 的協定，檢測出來的結果如下圖示：

最後，所以還是建議各位網站管理員將網站伺服器上預設支援的 SSL v2 協定關閉，確保用戶的安全性。

相關連結

• How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services
  停用 IIS 上的 PCT 1.0、SSL 2.0 或 SSL 3.0
• How to disable SSL v2 in IIS 7
• Thread: Disable SSL v2 in IIS7?
• 網站伺服器 SSL 支援版本檢測工具
• Transport Layer Security - Wikipedia, the free encyclopedia
• SSL/TLS in Detail
• Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2
• mod_ssl - Apache HTTP Server
• Analysis of the SSL 3.0 Protocol
• Disable SSLv2 in apache (httpd)

微軟在 2009/6/22 確認了一個從 17 年前 Windows 作業系統以來直到目前都還存在的一個安全性弱點，他能讓不受信任或無權限的使用者輕易的進入系統核心(system kernel)並取得該系統最大權限，目前尚無任何補丁(Patch)可以修正這個問題，但還是有方法可以強化你系統的安全性。

這個弱點是利用一個在 Windows 中稱為 Virtual DOS Machine (VDM) 的功能，這功能是為了向前相容  16-bit 應用程式的執行而設計的，這個功能在所有 32-bit 版的 Windows 都有支援 ( 64-bit 作業系統無此問題 )，由於此功能從 1993 年開始就有了，所以從 Windows NT 3.1, XP, 2000, Server 2003, Vista, Server 2008, 甚至是 Windows 7 都一樣有這個弱點，駭客只要能利用 VDM 功能寫一點點程式就可以輕鬆入侵你的電腦，且 PoC 的原始碼也已經放出來了。

要解決這個問題也很容易，只要關閉 MSDOS 與 WOWEXEC 子系統即可有效避免弱點被有心人士利用，我想到現在還有人在用 16-bit 應用程式的人應該不多了吧？但也許有些老公司還在用祖母級的 ERP 或進銷存程式也不一定。

解決此問題最簡單的方式就是透過 Active Directory (AD) 設定群組原則，限制網域內所有電腦執行 16-bit 應用程式，至於操作此設定的方法請見以下影片教學：

Windows Server 2003 Policy Demonstration

Windows Server 2008 Policy Demonstration

Windows XP Policy Demonstration ( 本機原則設定範例 )

若想看 Windows Server 2008 的中文設定畫面範例請參考下圖：

相關連結

• Windows plagued by 17-year-old privilege escalation bug
• Windows NT User Mode to Ring 0 Escalation Vulnerability
  Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack

Cookie hijacking 是個很常見的 XSS 攻擊手法，大多是利用網站既有的 XSS 漏洞並透過 JavaScript 取得 documnet.cookie 資料，而 documnet.cookie 就包含所有你在該網頁所有可用的 Cookie 資料，但若你的網站程式在設定 Cookie 的時候有特別加上 HttpOnly 屬性，就可以進一步避免該頁的 Cookie 被 JavaScript 存取，也可保護使用者的 Cookie 不會偷走。

以下是 ASP.NET 的程式範例：

// Create an HttpOnly cookie.
HttpCookie myHttpOnlyCookie = new HttpCookie("LastVisit", DateTime.Now.ToString());

// Setting the HttpOnly value to true, makes
// this cookie accessible only to ASP.NET.

myHttpOnlyCookie.HttpOnly = true;
myHttpOnlyCookie.Name = "MyHttpOnlyCookie";
Response.AppendCookie(myHttpOnlyCookie);

由於 HttpOnly 是 W3C 的標準配備，所以不止 ASP.NET 可以運用這個技巧，其他程式語言要利用 HttpOnly 時只要在 Set-Cookie 的 Header 最後面加上 ; HttpOnly 即可套用完成，如下圖示：

所以你的網站在使用 Cookie 時如果確定該 Cookie 不會或不需要被 Browser 端的 JavaScript 使用，建議都加上 HttpOnly 屬性，以免當真的有一天你的網站不小心出現了 XSS 弱點時不會傷及無辜用戶。

雖然套用 HttpOnly 屬性可以有效防堵 Cookie 被劫走(Hijacking)，但這並不代表使用 HttpOnly 就是安全的！因為如果你的網站還是有 XSS 風險，還是很有機會讓駭客利用 XHR 代客操作，所以就算駭客不取得 Cookie 也可以達成攻擊的手段。

另外，由於 Cookie 一樣會透過 HTTP 在網路上傳輸，被半路攔截的機會還是有的，建議使用 SSL 保護網路封包的傳輸，避免資料遭攔截。

我的 解釋 Cookie 的特性 文章有解釋 Cookie 的特性，不甚了解的人建議可閱讀一番，Cookie 基本上有兩種類型：Persistent Cookie 與 Session Cookie，而 HttpOnly 可套用在任何 Cookie 類型上，唯一的差別僅在於可不可以由 JavaScript, Silverlight 或 Flash 等前端程式存取而已！

相關連結

• HTTPOnly - OWASP
• HttpCookie.HttpOnly 屬性
• Mitigating Cross-site Scripting With HTTP-only Cookies
• HTTP cookie - Wikipedia, the free encyclopedia
• XMLHttpRequest - Wikipedia, the free encyclopedia
• Protecting Your Cookies: HttpOnly
• Why HttpOnly won't protect you

從 ASP.NET MVC 2.0 Preview 2 開始 JsonResult 已經被修改成只能在 HTTP POST 的時候回應，像我們經常使用 jQuery 的 $.getJSON 就不能再用了，我從 ASP.NET MVC 2.0 Preview 2 Release Note 得知 JSON Hijacking 之後就持續追蹤下去，覺得這是個非常值得注意的安全問題。

前陣子 Twitter 就被發現了一個 JSON Hijacking 漏洞，可以讓使用者在進入惡意網站後被取得你所有在 Twitter 的好友清單。建議有在使用 JSON 或動態下載 JavaScript 的網站都應該特別注意！

我看了好幾篇文章，不過都是英文的，解釋的非常清楚，相關資訊請參考「相關連結」。以下我列出幾個中文的文章供各位參考：

• 石頭閒語:JavaScript Hijacking and How to
• 什麼是JavaScript Hijacking？
• JavaScript Hijacking: Ad Hoc Ajax
• JavaScript Hijacking (from Fortify Software)

要避免這個問題，最簡單的作法就是『不要透過 HTTP GET 送出 JSON 資料』，雖然 jQuery 沒有內建 $.postJSON 方法，但卻非常容易實做，且在官網的 jQuery.post 文件有提供一個簡單的範例如下：

$.postJSON = function(url, data, callback) {
    $.post(url, data, callback, "json");
};

相關連結

• JSON Hijacking
• Anatomy of a Subtle JSON Vulnerability
• The real reason for (JavaScript|JSON) Hijacking
• JavaScript - Wikipedia, the free encyclopedia ( Cross-site vulnerabilities )
• You Don’t Know What My Twitter Leaks / Twitter JSON Hijacking Updates
• I KNOW WHAT YOUR FRIENDS DID LAST SUMMER
• Amazon.com: Ajax Security (Paperback)
• JSON - 維基百科，自由的百科全書

雖然我之前已經寫過一篇【 推薦使用 Microsoft Anti-Cross Site Scripting Library V3.0 】文章，而且這次 Anti-XSS Library v3.1 也只有小幅新增功能，但這次新增的兩個方法(Methods)卻是我盼望許久的功能，終於被我給等到了。我覺得任何開發 ASP.NET Web 應用程式的人都應該注意並使用這一套強大的 Anti-XSS Library，絕對有助於提升你現有 Web 應用程式的安全性。

本次改版新增的 Methods 分別是：

1. AntiXss.GetSafeHtml 方法：將傳入的 HTML 視為一整個頁面進行過濾。
2. AntiXss.GetSafeHtmlFragment 方法：將傳入的 HTML 視為一個 HTML 片段進行過濾。

這兩個新增的方法 (Methods) 都是用來將傳入的字串/文字轉換成「安全的 HTML 語法」，並且支援 串流 (Stream) 處理，所以當要處理大量 HTML 字串時也非常有效率，且被轉換過的 HTML 語法也會被 正規化 (Normalize) 處理，讓非標準的 HTML 變成標準的 HTML 語法/格式。

所謂「安全的 HTML 語法」是指當傳入的 HTML 包含任何被判定為危險的(malicious)內容就會自動被刪除，用以保證最後得到的 HTML 語法是絕對安全的 HTML 版本，讓你日後就算程式寫在爛也不受 XSS 攻擊的威脅，其中包括惡意的 HTML 標籤 (例如: script, iframe, link,meta, …)、惡意的 HTML 屬性 (例如: onload, onclick, …)、惡意的 CSS 屬性 (各位知道在 CSS 中可以插入 JavaScript 執行嗎? 如下範例: )

<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

能在CSS 執行 JavaScript 是很多人不知道的開發技巧，但這同時也是駭客最愛玩的 XSS 遊戲，不過這語法在新版的瀏覽器中都被移除了，目前已知支援這語法的瀏覽器有 萬惡的 IE6.0、IE7.0、Firefox 2.0、Opera 9.02 等，有認識朋友還在用 IE6/7 的人趕快請他們升級吧。

我寫了一支簡單的驗證程式，想探探 Anti-XSS Library v3.1 過濾惡意 HTML 的能力，我沒寫得很複雜，單純只是想看看轉換出來的結果如何。

程式碼如下：

轉換出來的結果是：

<div style="color:red; background:#FFF">OK </div>

當我試圖將 CSS 的 background 換成 url 的格式

轉換出來的結果是：

<div style="color:red">OK </div>

我也更進一步測試了 XSS (Cross Site Scripting) Cheat Sheet 所列的所有 XSS 攻擊情境，也確認 Anti-XSS Library 幾乎可以防禦所有的 XSS 手法 (除了一些非常非常舊的瀏覽器的XSS弱點之外)，Anti-XSS Library 過濾 HTML 的精準度無庸置疑的好、執行速度也恨快，不管怎樣都比你自己過濾 HTML 還來的安全，這畢竟是發展好多年、經過無數次驗證過的 Anti-XSS Library 版本，而且這還是完全開放原始碼的專案，有興趣研究、驗證 Anti-XSS Library 的人可以到這裡下載最新版原始碼。

上段提到的一些非常非常舊的瀏覽器的XSS弱點講的是在 Netscape 4.0 中的一種非常特殊、詭異的 JavaScript 寫法竟然也能運作，如下範例：

<BR SIZE="&{alert('XSS')}">

說實在的，沒認真研究過 XSS 的人不會想到 XSS 有多少花招可以玩，你光看 XSS (Cross Site Scripting) Cheat Sheet 所列的所有 XSS 攻擊情境就非常有趣了，很多你想都沒想到的攻擊手法，還有 Ultimate XSS CSS injection 也是很有創意的攻擊手法。

一般人在接受網頁表單送出 HTML 時，如果要限制特定標籤才能寫入到資料庫時，或許會使用類似【清除字串中的HTML標籤利用RegExp進階版】的作法，但這樣的限制並不完整，還是非常容易被 XSS 攻擊，只要透過 HTML Attribute Injection 或 CSS Injection 就能攻擊成功，所以建議的作法是：

1. 先用 Anti-XSS Library v3.1 支援的 AntiXss.GetSafeHtml 或 AntiXss.GetSafeHtmlFragment 方法過濾一遍所有輸入的 HTML 字串。
2. 然後再過濾不想支援的 HTML 標籤，這個時候再使用【清除字串中的HTML標籤利用RegExp進階版】作法就非常完美了。

今天一整個下午都在研究 Anti-XSS Library v3.1，我發現裡面有個 HtmlToHtml Class 主要負責過濾 HTML 工作，而且寫的非常有彈性，當中有個 委派 (delegate) 屬性 HtmlTagCallback 可以用來自訂過濾特定標籤的程式邏輯，透過這種方式實做過濾標籤的功能也會比用 Regex 實做來的好，只可惜在 Anti-XSS Library v3.1 中將 HtmlToHtml 類別標注為 internal 所以沒辦法直接使用。由於 Anti-XSS Library v3.1 是開放原始碼(MS-PL)，如果有需要的人還是可以將這些類別移到自己的專案中使用。

相關連結

• Microsoft Anti-Cross Site Scripting Library V3.1 下載
• AntiXSS – CodePlex [ Source Code ] [ Discussions ]
• New and Improved AntiXss 3.1, Now With Sanitization
• HTML Sanitization in Anti-XSS Library
• The Microsoft Information Security Tools (IST) team
• Anti-XSS 3.0 Released | Jossie | Channel 9
• XSS (Cross Site Scripting) Cheat Sheet
• Ultimate XSS CSS injection