[新聞時事] Twitter 遭受跨網站腳本攻擊

知名的微網誌 Twitter 在 21 日的 AM 2:54 收到警告，表示該網站存在一個跨網站腳本攻擊 (XSS) 的安全漏洞。但是根據其他網誌的報導，一個來自日本的資安研究員 Masato Kinugawa 表示他早在八月中就告知 Twitter 此一問題的存在，並利用此一漏洞做了一些不具破壞性的展示。Masato Kinugawa 將 Twitter 的頁面裝飾成七彩的顏色，並稱之為 Rainbow tweets。此一漏洞被揭露之後，許多人就開始發揮創意，不但產生各式各樣不同的行為，連觸發動作也由原來必須將滑鼠移到連結上 (onMouseOver) 改成自動啟動。後來甚至有了具備自動感染功能的蠕蟲出現，受害者包含前英國首相 Gordon Brown 的妻子 Sarah Brown。

這次的跨網站腳本攻擊來自於當使用者輸入的內容包含連結時 (如 http://www.twitter.com/) Twitter 會自動將其轉換成 html 的連結標籤 (<a>)，但是解析程式對於 @ 這個特殊字元的處理出現問題而導致。受影響的範圍主要為使用 Twitter 主網站服務的用戶，對於使用 3rd party 程式存取 Twitter 服務的用戶則不受影響。Twitter 則對外宣稱在收到通知之後的數個小時 (AM 7:00) 之內就把漏洞修補好了。

跨網站腳本攻擊的氾濫程度與嚴重性已經是老生常談的話題，雖然解法說起來很簡單，但是在執行上卻有其困難度。這次的事件還有另外一個需要注意的重點，那就是網站安全的不中斷性。不管你的網站其使用者是否來自於世界各地，對於駭客而言絕對沒有區域與時區的限制，所以如何建立一個 24 小時不中斷的安全機制與應變機制，對所有網站的經營者而言都是必須去認真思考的一個課題。

相關連結：

• Twitter Blog: All about the “onMouseOver” incident
• The Twitter hack: how it started and how it worked
• Twitter hit by worm that infect tweets with rogue code @SC Magazine UK

[新聞時事] ASP.NET 區塊加密法因實作錯誤而導致 Cookie 產生危險

根據 Thai Duong 與 Juliano Rizzo 兩位資安研究員於日前所發表的資料顯示，他們已經找到 ASP.NET 當中用來加密 Cookie 演算法的實作錯誤。這個錯誤影響了包含 AES、3DES、MARS 在內的區塊演算法 (Block-Cipher)，而攻擊者則可以透過 ASP.NET 所傳回的錯誤訊息計算出用來加密的 Machine Key，其所產生的危害包含攻擊者可以假冒任何合法的 Cookie 及 ViewState。因為 Cookie 是許多系統用來儲存使用者身分資料的機制，也就是表示攻擊者可利用此一攻擊手法來假冒合法的使用者、甚至是管理者。

目前 Microsoft 針對此一問題所提出的建議方案正是減少錯誤訊息所提供的資訊。例如可以在 web.config 內加上或修改成下列內容
<customErrors mode=”On” defaultRedirect=”~/error.html” />

如此一來攻擊者就只能看到固定的錯誤訊息，而無法利用錯誤訊息來計算出所需的 Machine Key。

 

這裡有示範的影片，研究員利用發現的錯誤攻擊 DotNetNuke 這個套件，並順利取得管理者的權限。

 

相關連結：

• Updated: Security Hack Exposes Forms Authentication in ASP.NET

[教戰守則] 如何避免 SQL Injection?

雖然 SQL Injection 提出至今已經經過了許多年，但是 SQL Injection 依舊是目前網站應用程式的主要弱點之一，更是資料外洩的主要管道。根據 WhiteHat Security 的一份 White Paper 的內容指出，可以採用下列 10 個方法來避免 SQL Injection 產生危害：

1. 將資料庫與網站伺服器分別安裝在不同的機器上，並確保機器維持在最新的更新狀態。(Install the database on a different machine than the Web server or application server. Make sure all the latest patches are applied.)
2. 應該將資料庫內所有預設帳號與密碼加以關閉，尤其是管理者的帳號更是不可掉以輕心。(The database should have all the default accounts and passwords disabled, including the super-user account.)
3. 建立一個應用程式專用的帳號，並給予其執行任務所需的最小權限。將所有範例表格以及不需使用的 stored procedure 加以移除。(Create an application user account in your database that has minimum privileges necessary for that application to access the data. Remove all the sample tables. Disable access to any stored procedure that is not required by that application user.)
4. 找出所有需要執行的 SQL 指令，並僅允許這些指令的執行。(Identify the list of SQL statements that will be used by the application and only allow such SQL statements from the application, e.g. Select, Insert, Update, etc.)
5. 在不需要使用 insert 或 update 的情形下使用 view 的方式來存取資料庫，可以應用在搜尋或是登入功能。(Use read-only views for SQL statements that do not require any inserts or updates, e.g. Search functionality or Login functionality.)
6. 檢查輸入 (包含資料類型、長度、格式等) 並去除不必要的內容。(Sanitize the input by validating it in your code.)
7. 使用參數化的查詢並避免使用動態式的查詢。以 Java 為例，應該使用 PreparedStatement 物件而非 Statement 物件。(Use parameterized queries instead of dynamic queries. For example, in Java, use Prepared Statement instead of Statement Object.)
8. 採用合適的錯誤處理與記錄功能以確保資料庫發生錯誤時的訊息或其他技術資訊不會因此而洩漏。(Employ proper error handling and logging within the application so that a database error or any other type of technical information is not revealed to the user.)
9. 選擇不易猜測的資料庫表格/欄位名稱。(Choose names for tables and fields that are not easy to guess.)
10. 盡可能的使用 stored procedures。(Use stored procedures instead of raw SQL wherever possible.)

嚴格來說，第 7 點才是目前專門針對 SQL Injection 最主要也是最有效的控制措施。然而其他控制措施雖然並不是特別針對 SQL Injection 這類威脅，但是卻可以減少當系統發生問題時所產生的危害，因此也有其實施的效益。雖說如此，對於第 9 點與第 10 點我個人倒是有一些不同的看法。

首先針對第 9 點，雖然採用較難猜測的表格/欄位名稱可以減少攻擊者成功執行 SQL Injection 的機會，但是如果因此走向極端而將所有表格/欄位名稱改成無意義的名詞，那麼對於開發人員所造成的困擾可能遠大於其所帶來效益，在執行上必須小心謹慎。

而對於第 10 點我個人則採取完全相反的意見。雖然使用 stored procedures 確實可以增加 SQL Injection 成功的難度 (stored procedures 本身還是會遭受 SQL Injection 的攻擊)，但是 stored procedures 的大量使用很容易使得系統的可移植性受到不良影響。更重要的是 stored procedures 將使得程式邏輯隱含在資料庫內部，對於系統功能的模組化往往是一大傷害。我這樣說並不是說 stored procedures 完全不可使用，而是 stored procedures 要不要使用、要使用到什麼程度，不應該從安全的角度來加以考量，而是應該回歸到業務與系統本身的需求。

除了這些要項之外，採用好的自動化工具 (不管是白箱或黑箱測試工具) 對避免 SQL Injection 的威脅也是目前相當有效的一種作法，值得需要系統化管理 SQL Injection 威脅的團隊加以評估。

 

相關連結：

• 10 Steps to Protect your Websites from SQL Injection Attacks @ WhiteHat Security
• IBM X-Force® Report Reveals Phishing, Document-Related Threats Rising Dramatically

[研究報告] IBM X-Force 2010

IBM X-Force 上個月發表了 2010 年的年中報告，報告中有幾項重要趨勢值得特別注意：

• 攻擊者使用更多的隱匿技術來進行攻擊，例如像是 JavaScript 混淆 (Obfuscation) 的手法，而這些技術已經對 IT 安全專家造成相當程度的困惱。
• 被發現的安全弱點數量持續成長，與去年同期相比成長了 36%，創下歷史新高點。
• 利用 PDF 的攻擊行為隨著攻擊手法的翻新持續增加。PDF 攻擊被大量採用的原因在於其攻擊目標為防禦能力較差的終端設備 (如個人電腦)，一旦入侵成功就可以作為其他入侵手法的跳板。
• Zeus botnet 持續對企業產生莫大的影響，而新版的 Zeus 甚至開始提供攻擊者更新的功能。

至於在網站應用程式安全方面，有下列幾個重要的現象：

• Cross-site Scripting (XSS) 與 SQL Injection 依舊是主要的弱點類型。其中 SQL Injection 雖然於前次報告發表時呈現下滑的現象，但是在這次的報告中又再次上升，顯示 SQL Injection 的問題依舊需要善加處理。
• 在網站應用程式平台 (Web Application Platforms) 方面，其弱點數量所佔的比例就高達所有弱點的 14%。進一步加以分析，其中僅 12% 為平台本身的問題，而高達 88% 的問題則來自於擴充元件 (plug-ins)，顯見擴充元件的安全品質仍與平台本身有相當程度的差距。
• 在終端設備部分，瀏覽器依舊是問題的主要來源。但是就如前述所言，PDF 的攻擊大幅成長並緊追在瀏覽器問題之後。
• 以瀏覽器 (包含 plug-ins) 的分類來看， Firefox 與 IE 的弱點數量依舊佔了大多數。而 ActiveX 的弱點數量雖然成長幅度較不明顯，但是其弱點數量卻遠較瀏覽器本身更高。

對於完整報告有興趣的讀者可以在這裡加以下載。

相關連結：

• IBM X-Force報告揭示全球網路安全威脅空前凌厲 @ 資安之眼