就是資安

在上一篇的文章中，我們了解到何謂 CSRF 以及其運作原理，在這篇的文章中我想要談談網站開發者與使用者該如何做才能避免 CSRF 的威脅。 要避免 CSRF 的攻擊，目前公認最有效的方式就是所謂的 Synchronizer Token Pattern。簡單來說，Synchronizer Token Pattern 指的是每次使用者發出請求時 (不管是透過 POST 還是 GET) 都必須傳回一個網站系統所指定的亂數，而這個亂數可以設計成適用於整個 Session 階段，也可以設計為只能使用一次。以安全性而言，後者的作法確實可以達到相當好的效果，但是卻也會為使用者帶來極大的不便性，所以在大部分的情況下前者反而是比較常用的作法。其實後者的作法除了應用在增加安全性之外，也常被用來作為避免使用者重複發出請求的保護措施。使用者重複發出請求尤其容易出現在反應較慢的系統中，使用者因為失去耐心或不知所措之下往往只好重複之前的動作 (請求)。 等等，在使用 GET 的情形下，Synchronizer Token 不就等於直接擺在 URL 參數中讓人取用，那怎麼還有安全性可言？別忘了在 CSRF 攻擊中，通常駭客是無法取得受害者與目標網站之間溝通的訊息，所以這樣的作法依舊大幅增加駭客產生合法請求的困難度。再加上 Synchronizer Token 的有效期僅存在單一 Session、甚至是單一請求中，因此就算駭客取得 Synchronizer Token 後也往往無濟於事了。此外，透過 SSL 進行連線可以讓 Synchronizer Token 被”看到”的機會大大降低。 Synchronizer Token 的一個特例就是直接把 Session Token 當作 Synchronizer Token 使用，這種方法又稱之為 Double Submit Cookies。使用 Double Submit Cookies 的好處是比較方便，網站系統不需要另外維護一份 Synchronizer Token 的對應關係表，但是這樣做卻會讓 Session Token 處於一個較危險的狀況，增加了 Session Hijacking 攻擊的成功機會。

Cross-site Request Forgery，常縮寫為 CSRF (或 XSRF)，中文翻譯稱之為跨網站的偽造要求。除了這些稱呼，其他像是 Cross-site Reference Forgery、Session Riding、One-click Attack 等等各式各樣的名稱，其實指的都是同一種攻擊手法。 CSRF 跟 XSS (Cross-site Scripting) 都是跨網站的攻擊手法，但是 CSRF 利用的是使用者對於瀏覽器的信任而達到攻擊目的，而 XSS 則是利用使用者對於網站本身的信任。 簡單來說，CSRF 就是在使用者不知情的情況下，讓瀏覽器送出請求給目標網站以達攻擊目的。 對於 HTTP 協定有所了解的讀者，看到這句話可能會覺得很困惑。因為在預設的情況下，任何人只要知道 URL 與參數都可以對網站發出任何請求，如此說來不是所有的網站都會遭受 CSRF 的攻擊了嗎？可以說是，也可以說不是。因此嚴格來說，CSRF 通常指的是發生在使用者已經登入目標網站後，駭客利用受害者的身分來進行請求，如此一來不但可以獲得受害者的權限，而且在系統的相關紀錄中也很難發現可疑之處。 在進一步談到 CSRF 的攻擊手法之前，我要先談一下一般網站應用程式是如何識別使用者的身分。對於需要辨別使用者身分的網站而言，最常見的方法就是依靠帳號/密碼。凡使用者想要進行受限制的動作時，就必須先經過帳號/密碼的驗證。但是如果在每次進行受限制動作前都要輸入一遍帳號與密碼，我想沒有多少使用者可以忍受這樣的不便。所以所有的網站系統都會把使用者輸入且通過驗證的帳號資訊記錄下來，之後就不再進行驗證的動作了。然而因為 HTTP 協定的限制 (Stateless)，所以如何紀錄這個驗證過的帳號資訊就成了棘手的問題。早期有些系統會將帳號本身紀錄在 Cookie 中，因為 Cookie 的特性就是瀏覽器在每次存取網站的同時會將內容傳回去，所以網站系統就可以從 Cookie 中獲得帳號的資訊。然而因為 Cookie 存放在使用者的電腦中，算是一個極不安全的環境，因此後來的網站系統都是在 Cookie 中存放一個隨機亂數產生的代號，網站系統再經由這個代號找出相對應的帳號資訊，這個代號我們通常稱之為 Session Token。Session Token 的概念與實作雖然很簡單，但是安全性卻依舊不足，所以為了提昇 Session 的安全性就必須採用其他補強措施。像是 Session Token 自動失效、定期更新 Session Token 的數值、加上檢查 Session Token 來源 IP 位址等方式，都可以用來增加 Session 的安全性 (主要是避免 Session Hijacking)。除了利用 Cookie 來紀錄 Session Token 外，其他像是把 Session Token 放在 URL 參數中，或是使用 Basic Authentication 的方式，雖然細節上有些不同，但是基本的原理卻都是一樣的。

DLP (Data Loss Prevention) 一詞對於 IT/IS 人員來說，可說是已經朗朗上口，甚至成為茶餘飯後的聊天話題。目前有很多現成的產品宣稱可以全面保護重要的資料，大多數保護的範疇以資料庫為主，但是也有一些產品以非結構性的資料 (如檔案) 為保護對象。然而除了導入技術性的產品之外，要做到更為完整的資料防護就不可以忽略資訊安全政策的重要性。因為很多時候重要資料並不一定只會以數位的形式存在，對於非數位形式 (如紙本) 的重要資料而言，唯有透過良好的安全政策才有辦法加以保護，而技術性的產品對此幾乎可以說是無任何用武之地。而且就算是針對數位形式的資料，同樣需要良好的安全政策才能讓技術性產品發揮應有的功能。舉例來說，如果公司對於資料存取的授權沒有一定的程序而任憑管理者自由心證，那麼就算佈署再好的技術性產品也是枉然。 做到了這些，資料就安全了嗎？很可惜答案還是否定的。以目前的商業環境而言，這些寶貴的資料大多會被具備網路功能的服務所取用。標準的 DLP 產品可以避免寶貴資料透過 Email、HTTP、IM 等方式外洩出去，但是對於客製化的系統 (像是 CRM 或 E-commerce 等) 通常就愛莫能助了。這個議題屬於軟體安全 (Software Security) 與應用程式安全 (Application Security) 的範圍，對許多組織來說是比較不受重視的議題。除了不受重視之外，軟體安全/應用程式安全的負責人員也跟上述 DLP 產品或資訊安全政策負責人員有所不同，因此雙方如何合作以達到無間隙的防護能力，更是需要特別費心的事項。前一陣子沸沸騰䲢的 AT&T iPad 客戶資料外洩事件，據悉並不是因為 iPad 本身設計的問題，而是網站應用系統出現安全漏洞而造成的。以 AT&T 跟 Apple 這麼知名與具備技術能量的公司都尚且出現這麼嚴重的瑕疵，可見得問題的嚴重性與影響層面之大。或許大家可以說 AT&T 跟 Apple 本來就不是以 Web 與 Security 著稱，那麼 Google 呢？這家網路原生的網路巨擘，不斷強調其服務的安全性，但是依舊免不了遭受駭客攻擊成功的下場。舉這些例子並不是為了數落這些公司，因為我相信絕大多數的組織並不見得會做的比他們更好。今天發生在 iPad 上面，或許無法改變 iPad 持續熱賣的事實。但是如果類似的事情發生在其他的組織中，會有多少組織能夠全身而退？既然問題如此嚴重，我們又怎能不認真地面對軟體安全/應用程式安全這些議題，並好好擬定對策呢？

前一陣子在一次偶然的機會中，被一位高手問到 (應該說是考到) 什麼是 Clickjacking，又要怎麼防備？老實說，雖然 Clickjacking 這個手法剛被提出時我就注意到相關的新聞，但是當時尚未公布實際的手法，再加上 Clickjacking 一直不像 SQL Injection、XSS 這些手法這麼普及 (OWASP Top 10 還排不上)，所以後來我就一直沒有動力去研究 Clickjacking 這個手法。因此，只記得當時我真的是比穿黑衣還掉了滿身的頭皮屑還糗。不過話說回來，學習永遠不嫌晚，所以我趕緊惡補了一下，並透過這篇文章跟各位分享一下 Clickjacking 這個很危險卻還沒有被廣泛應用的攻擊手法。 Clickjacking，簡單來說就是將使用者在瀏覽網頁的點擊動作進行綁架，讓點擊動作產生非使用者所預期的行為。Clickjacking 最初公布的 例子，也是最著名的例子，就是利用隱形頁框 (invisible iframe) 的方式，讓受害者在不知不覺中”自己”修改 Flash 的安全設定，以利駭客可以遠端控制受害者電腦的攝影機與麥克風，進而進行遠端的監聽/監視。目前常見的資料將 Clickjacing 分為 frame-based clickjacking (又稱為 UI readressing) 與 plugin-based clickjacking 兩大類，但是在阿碼外傳上的 範例 使用修改 onclick 事件處理程序的方式，也可算是另外一種實現的手法。

電影 女神的報酬 的男主角是一位工作能力很強卻人際關係不佳的外交官黑田，他被派駐到義大利後，首件任務就是確保前來參訪的日本外相的人身安全。沒想到黑田竟被意外捲入一樁日本觀光客的綁架案件，女主角的小女兒在沒有任何線索的情況下被犯罪集團所綁架。在與綁匪交手的過程中，黑田雖然發現許多不合理的細節，但是依舊一步步試著解開謎團，最後終於有機會前往負責監視小女孩走失地點的安控中心，想要釐清一些無法理解的疑點。綁匪利用女主角進入管理嚴密的安控中心的機會，要脅女主角趁機癱瘓安控系統並取得存取的權限，之後更將保全設施加以關閉，製造想要襲擊義大利總理的假象。在層層抽絲剝繭之下，黑田發現所謂的綁架事件只是一個瞕眼法，綁匪真正的目標其實是日本外相，兩人的恩怨導因於多年前的一件國際援助事件… 男主角黑田新官上任。 男主角主要負責安全事宜，思慮冷靜且清楚。 女主角的小女兒不見了，是自己走失了嗎？

根據 Wired 網站的新聞報導，有一個犯罪組織多年來利用信用卡小額轉帳的方式，成功獲取超過一千萬美元的不法所得。這個組織透過垃圾信件刊登不實的求才廣告，並利用多個虛設的公司與網站騙取使用者的資料。因為每個使用者的轉帳金額並不高 (從 0.2 到 10 美元)，所以此舉不但成功地躲過信用卡處理中心的偵測機制，甚至有高達 90% 的受害者根本沒有注意到信用卡帳單上無緣無故多出了一筆支出。因為使用習慣的不同，這類信用卡的詐欺行為在台灣相對來說比較少見，但是謹慎一點總是好事。下次當你收到信用卡帳單時，請注意帳單上的每筆消費記錄是否有所可疑。事實上，很多我們平常消費的店家我們只知道店家的名稱，但是公司的名稱往往不見得與店家名稱相同，所以在檢查帳單時可能會造成一些困擾。小心駛得萬年船，多注意這些細節不但可以避免金錢上的損失，更可以避免可能的法律紛爭。   相關連結： FTC: Scammers Stole Millions Using Micro Charges to Credit Cards

在電影 我的意外老公 中，男主角的未婚妻因為 Callin 到女主角的電台進行愛情諮詢而選擇毀婚。男主角在心懷不滿之下，透過房東兒子的協助，修改女主角的結婚記錄，讓男主角與女主角成了合法夫妻。女主角結婚在即，也因此這項毫無緣由的婚姻記錄可說是打亂了她的一切計畫。就在兩人協調的過程中，男、女主角不自主的產生情愫，甚至女主角後來更決定同樣來個大逃婚。就在一切看似美好的時刻，女主角無意間在垃圾桶內發現男主角之前對她進行調查時所列印的網頁資料，惹得女主角勃然大怒並因此負氣決定回到未婚夫的身邊。 房東的兒子很喜歡上網找八卦。 男主角相當瞧不起在江湖上人稱愛情博士的女主角。 男主角對螢幕上的資料很好奇。

雖然有關雲端安全的議題跟雲端運算本身一樣持續發燒，也有越來越多的廠商推出相關的服務/產品，但是不可否認安全議題依舊是導入雲端運算的主要瓶頸之一。對此，Gartner 預期企業初期在私有雲 (Private Cloud) 的投資會大於公開雲 (Public Cloud)，主要原因就在於企業對於私有雲依舊擁有足夠的掌控權，可以減少與其他人共用平台所產生的額外風險。儘管如此，私有雲畢竟與原先的 IT 架構有所差別，因此在安全的考量上也有其特別之處。如果一味的將私有雲與原先的 IT 架構一視同仁，那麼產生的風險將是無法估算的。 為了因應雲端運算的安全議題，雲端安全聯盟 (CSA, Cloud Security Alliance) 發表了安全指導原則 (Security Guidance)，期望給所有相關人士一些可行的參考方向。目前最新的安全指導原則是在 2009 年年底所公布，版本號碼為 2.1。在這份文件中，將雲端安全分為兩大領域，分別為治理 (Governance) 與維運 (Operation)，其下各有 5 個與 7 個分類，共計 12 個分類： 治理 (Governance)

• 治理與企業風險管理 (Governance and Enterprise Risk Management)
• 法律與電子資料搜尋 (Legal and Electronic Discovery)
• 法規遵守與稽核 (Compliance and Audit)
• 資訊生命週期管理 (Information Lifecycle Management)
• 可攜性與互通性 (Portability and Interoperability)

維運 (Operation)

• 傳統上的安全、業務持續與災難復原 (Traditional Security, Business Continuity, and Disaster Recovery)
• 資料中心維運 (Data Center Operations)
• 事件處理、通知與回復 (Incident Response, Notification, and Remediation)
• 應用程式安全 (Application Security)
• 加密與金鑰管理 (Encryption and Key Management)
• 身份與存取管理 (Identity and Access Management)
• 虛擬化 (Virtualization)

Google 於今年 (2010 年) 3 月中推出了一個自行開發的 Web 應用程式安全掃描工具，稱之為 Skipfish。Skipfish 與其他 Google 的工具有所不同，並不是直接透過瀏覽器加以操作，而是必須自行下載並編譯才可以執行。為了效能的考量，Skipfish 以 C 語言開發，同時支援 Linux、FreeBSD、MacOS X 與 Windows (必須安裝 cygwin) 的環境。 這類工具中比較著名的包含 open source (GPL) 的工具 Nikto，此外也有許多付費的工具可供選擇，而 Skipfish 則提供了另一個免費的選擇。不過根據 Skipfish 的說明，Skipfish 與其他工具並不是相互重疊的選項，而是補足其他工具不足之處，所以對於其他工具已經實現的功能在 Skipfish 中是缺席的。舉例來說，Skipfish 並沒有採用已知弱點資料庫的方式來找出一些已公布的安全漏洞。 如果你熟悉 *nix 下的編譯過程，編譯 Skipfish 並不會是一件困難的工作，唯一需要特別注意的是所需的函式庫是否已經完整安裝，其中尤其是 libidn 這個函式庫 (在 Fedora 的環境下，所需安裝的 RPM 套件名稱為 libidn-devel-*)。編譯成功之後會出現一個名為 skipfish 的執行檔，但是在開始使用 Skipfish 進行掃描前，還需要額外進行一個動作，那就是從 dictionaries 目錄下的四個 wl 檔案中挑選一個並將它複製到與 skipfish 執行檔同一層的目錄，檔名則為 skipfish.wl。準備好之後，就可以透過 ./skipfish –o output_dir url

《阿凡達》的故事敘述在未來世界中，人類為取得另一星球的資源，開啟阿凡達計畫，以人類與納美人的DNA混血，培養出身高近3米高的阿凡達，以利在潘朵拉星球生存並採礦。男主角傑克因為鑾生兄弟去世，因而被選上成為其兄弟的阿凡達”駕駛”。傑克本身原為因受傷而不良於行的軍人，因此不但一開始被阿凡達計畫主持人所不屑，軍方甚至要他成為內應，透漏更多有關納美人的內線消息。然而在一次的偶然機會中，參與阿凡達計畫的科學家發現了傑克的內應身分。但是礙於傑克是最接近納美人的阿凡達，所以計畫主持人當機立斷，前往一個隱密山區的基地繼續進行後續的計畫，以避免傑克與軍方的接觸。 男主角是神奇的傑克，一個不良於行的軍人。 另一個阿凡達計畫的成員。