Web 2.0 早已不是什麼新話題。過去的幾年內，知名度高如 Google、Yahoo、MySpace、PayPal 等大站，也都無法完全免疫，而陸續爆發過各種攻擊事件（釣魚、蟲…）。Web 2.0 網站不管是選擇用 AJAX 、Flash，還有逐漸風行的離線解決方案，如 Dojo Offline、Google Gears 、Adobe AIR 等，來提供互動性更高的 UI，只要一不小心，這些 Web 應用出現安全漏洞、被壞人佔便宜的機率，其實是很高的。有時候不僅是自己的 code，而問題也可能出現在第三方提供的現成工具箱、API。

要如何防範？對網站開發人員而言，在過去，對這個主題的探討，往往比較零散，要不就偏學術，要求較高的門檻（例如 OWASP 發表的文獻），一直缺乏系統化，全面性，且深入淺出的探討。不久前終於出了一本好書 — AJAX Security，作者為 Billy Hoffman 和 Bryan Sullivan 這兩位 Web 2.0 安全的專家（過去在零星的安全相關報道中，也常出現他們兩位的影子）。在此強烈推薦這本書，給所有從事與 Web 2.0 開發相關的網友。儘管書名選擇叫 “AJAX” Security，但事實上，除了 AJAX 之外，Flash 安全，甚至於如何將 CSS 這種看似無害、展現層的東西，拿來攻擊的方法，在書中都有深入探討（第十二章）。儘管這樣的書，早該出現，但出版時間晚，反而也做出一些額外的貢獻 — 比較新的科技，如上述的 Google Gears 和 Dojo 離線工具箱的安全弱點，在書中都涵蓋了。希望它盡快能被翻譯成中文，以造福更多大眾。

真的有那麼可怕嗎？如果你問作者，那麼他的答案，會是一個非常肯定的 “YES!!”，這麼說只是因為他想多賣幾本書嗎？其實不是。不管從書裡，或從這個和作者的 podcast 訪談中，作者列舉的種種弱點，攻擊方式，技術上都論點鏗鏘，絕非危言聳聽。而最恐怖的還是，各大著名網站相繼中箭的事實，為這些攻擊方式，提供了最佳的 「成功案例」。這些安全事件，聽在不懂技術的一般網民耳中，如果再被過分呈現，往往會引發「因噎廢食」的反應（英文叫 “knee-jerk reaction”）。記得多年前 Web 1.0 時代，許多用戶便對 cookies 有不明就裡的懼怕。身為 IT 從業人員的我們，自然不希望用戶採取過當的對應手段，例如選擇將瀏覽器中的 JavaScript 關閉（那將會是 Web 2.0 最黑暗的一天）。但我們也的確要好好警惕，讓對我們網站的攻擊事件的發生機率，盡量減到最低 — 這點更凸顯了本書的重要性。

如果 Web 2.0 安全也有「十戒」般的戒律，那麼第一大戒肯定是：絕對不能相信 client 端。來看作者在 podcast 中所舉的一個很經典的例子，他們還因此吃了很多免費的漢堡 。故事是這樣的：美國的麥當勞網站上，有個用 Flash 開發的棋盤遊戲，贏的人可得到免費的兌換餐券。他們先用 sniffer 檢視瀏覽器對外的交通，發現這個 Flash 遊戲不斷需要對某個網站傳遞資訊，因此懷疑程式的作者可能將遊戲的輸贏狀態，直接向某個 Web service 回報（這已經犯了另一戒 — 不該將程式的狀態控制或流轉邏輯放在 client 端，因為 client 端是不可信賴的）。他們發現攔截到的信號是一些奇怪的亂碼，但看起來又不像是用 SSL 加密過的 pattern。於是接著開始將 Flash 程式 SWF 進行反組譯（用的是 Flare，一個 open-source 的 SWF 反組工具）。從原始碼中，分別找到一個負責加密、一個解密的函數 — 啊哈！原來用的是一個對稱性加密演算法（又犯一戒 — 因為應該用不對稱加密，即 public-key encryption），這代表在程式中某處，必藏有那把加解密都需要的私密金鑰。果然，作者不但找到、偽造了對伺服器端回報結果的 request，而且還根據該 key 的命名 pattern（”某設計公司_客戶_3″），推測出承包麥當勞網站的那家設計公司，所承包的其他網站中，也有類似的做法。果然，他們去看該設計公司的客戶清單，得知是那些網站，然後用 “…_客戶2″、「…_客戶5」 諸如此類的 key，也成功地破解其他網站的遊戲，贏得更多獎品。

關於如何過濾用戶輸入的問題，作者也提了一些很好的建議。一是用黑名單方式 (blacklisting) 的不足，建議實在應改用白名單來過濾 (whitelisting)。我們知道，黑名單的過濾方式，是針對已知的不正常字元、字串 patterns 等進行過濾，以避免包括 SQL 注入、JavaScript 注入等的攻擊，如果黑名單漏了任何其他的可能，攻擊仍可能成功。相對地，白名單則更加嚴格，只讓合理的內容通過（例如電話號碼的欄位，只可能有數字、「+」、「-」、”(”、「）」、空白這幾種可能的字元），任何其他，不管是不是特殊字元，一律擋掉。

此外，光是在瀏覽器端用 JavaScript 過濾用戶的輸入是不足的（因為第一戒：不可相信 client），server 端的過濾相形之下更加重要。當然，這個需求會增加不少開發人員的負擔，要如何將過濾的條件在 server 和 client 間同步？實作方式？未來隨著 Dojo、Google Gears、Adobe AIR 這類的離線應用的普及化，如果要確保安全，每當離線的 client 恢復和 server 的連線，就要檢查一次，這個過濾條件同步工作只會更加複雜。

Google Maps 的成功，可說帶來了 mashup 的大量風行。例如某 blog 網頁，希望在用戶擷取該 blog 時，同時可以動態從幾個第三方網站，如 Google、del.icio.us 等拿資料，內嵌在 blog 網頁中，這是典型的 client 端 mashup，不需要 coding，只需剪貼幾行簡單的 JavaScript 到網頁模板裡即可。此類 widgets、gadgets 在眾多社交網站的用戶首頁中，早已獲得爆炸性的歡迎。但事實上，在 Google、Yahoo 和眾多供應商提供這些簡單、高生產力的 API 背後，牽涉了一個叫 「同源政策」 (Same Origin Policy) 的技術障礙，需要繞過。簡單地說，按照 Firefox、IE、Safari 這些支援 AJAX 瀏覽器先天的安全設計，JavaScript 到上述例子中的 blog 網之外的其他網站去下載資料，是不被允許的，就像 JavaScript 不可跨域讀 cookies 一樣。Google、Yahoo 的工程師很聰明地利用了 JSONP（JSON with Padding，或稱 JSON RPC），發明出一個 「跨站腳本運行」（Cross-Site Scripting，簡稱 XSS）的解決方案（注）。JSON 的運用，成就了 mashup，但在此同時，許多此類的程式，也暴露出可被人進行注入式攻擊的漏洞。例如過去 Gmail 的 JSON 程式，就被人用來竊取通訊錄的內容。Google 還有其他好幾個服務，都曾經成功地被人用 JavaScript 注入攻擊。

Flash 的跨域 XML (cross-domain XML) 對象，也是一個潛在的問題。作者提到 Flickr 的 SWF API 中，用了跨域 XML，暴露出讓人有機可趁的弱點。

是不是有什麼方便的工具，可以將大部分安全檢查的工作自動化？作者現身說法，以自己過去曾創立過一家小公司長期研發此類工具的經驗，悲觀地表示，由於問題牽涉的複雜性，很難做出能高度自動化的工具。目前最有效的方式，還是通過對開發人員的教育。說到開發人員的背景，作者表示自己在近兩年，體會到一個遺憾的趨勢（主要指美國） — 有愈來愈多非 Web 程式設計師出身的開發人員，其中許多有多年client-server 應用開發經驗，認為 Web 開發很簡單，沒什麼大不了的，因此不太能接受他人關於 Web 安全方面的忠告，他們忽略了 Web 的應用模式和過去他們熟悉的那些有很大的不同，因此安全方面的顧慮也大不同。當然，廣大 Web 開發人員中還有很多是從網頁設計工作慢慢接觸 scripting 的，儘管他們相對而言非常虛心學習，但因為本身的技術背景有限，可能會對複雜的安全問題感到頭大而不知從何下手。作者說到儘管自己是 CS 科班出身，但過去學校也並未對安全這門知識，有任何系統化的教育，他的知識都是後來自學的。這些都加深了問題的嚴重性。

如果把上述的安全問題放到 SOA 和企業 Web 2.0 的情境中，不難預見，將產生一些新的挑戰。在 SOA 界地位頗高的資訊機構 CBDI，他們的總經理兼首席顧問 David Sprott 在三月份的期刊中，對服務組裝 (Service Assembly) 的發展現況和展望，做了一個探討（需要註冊）。他認為在各種現行方式均不盡理想的情況下，AJAX mashup 的簡單方式，提供了一個新希望。但他同時也承認，有安全上的顧慮需要面對。

試想：如果未來某大上市企業，開始在內部開放一些 JavaScript 的 API，讓員工可以自由地做 mashup，是不是有可能發生某員工利用該 API 有可以讓人進行 JavaScript 注入的漏洞，佈置一個釣魚攻擊，騙到某 CXO 的密碼，用以登入財務系統，偷看下次財報的相關資料，事先進一批股票海削一筆？這不是天方夜譚。

注：

• XSS 裡的 X 像斜躺的十字架，所以老美就用 X 作為 “cross” 的縮寫，記得剛到美國的時候，常見許多 “XING” 的路標，不知是什麼意思，後來才知道代表 crossing，警告前面可能有火車、行人、野生動物等穿越
• JSONP XSS 的運作原理：一，二。