就是資安

ReDoS? 可不是再次的阻斷服務攻擊 (Re-DoS)，而是正規表示式阻斷服務攻擊 (Regular Expression DoS)，是阻斷服務攻擊的一種手法。對於一般的程式開發，雖然不見得常使用到正規表示式的應用，但是正規表示式卻常見於各式各樣的過濾器上。所以像是網站應用程式的輸入檢查、快取伺服器或其他類型閘道器的存取過濾功能，通常都有正規表示式的存在。 正規表示式最基本的應用就是用來尋找資料中是否含有特定樣式的內容，例如我們可以透過正規表示式來判斷一個文字檔內是否含有手機號碼，而判斷條件就是以0為開頭的連續10個數字 (這個條件可能不適合用來找出所有可能的手機號碼，但是無損於說明性)。也因此正規表示式的應用至少含有兩個部分，一個就是用來當做搜尋的樣式 (Pattern，通常這部份也稱為正規表示式)，以前述的例子而言就是”以0為開頭的連續10個數字”。另外一部分則是用來被搜尋的輸入目標，以前述的例子而言就是文字檔的內容。而正規表示式阻斷服務攻擊發生在利用某些樣式進行搜尋時將有可能會產生大量消耗運算資源的情況，因而使得系統無法處理其他的請求。這也是它為什麼被稱為阻斷服務攻擊的原因了。 至於”某些樣式”是哪些樣式，在 OWASP 上面的說明文件舉了一些例子，包含 (a+)+ ([a-zA-Z]+)* (a|aa)+ (a|a?)+ (.*a){x} | for x > 10

資訊安全專家 Bruce Schneier 日前在他個人的部落格發表了一篇文章，提到了一個可以用來分析電話來源的小工具 - PinDr0p。根據部落格的內容指出，這個工具雖然沒有辦法分辨出電話來源的所在區域或 IP 位址，但是它可以用來判斷不同的電話之間是否來自同一個所在地。也就是說如果該程式知道你日常往來銀行客服電話的特徵，那麼它就可以判斷出日後宣稱來自該銀行的電話是否符合之前的特徵，也就是說它可以避免使用者接到由其他地方發出的詐騙電話而不自知。雖然 Bruce Schneier 宣稱每一個電話來源只要經過 5 次的取樣就可以達到日後 100% 的準確率，但是如何轉換成為可行的系統，而且在實際的環境下又能有多好的成效，就讓我們拭目以待吧。    

前幾天無意間聽到有人提到 iBatis 使用了 PreparedStatement 的機制，所以沒有 SQL Injection 的問題，因此我特地寫了這篇文章來說明 iBatis 與 SQL Injection 的關係。在開始說明之前，我稍微解釋一下 iBatis 這個套件。根據作者的解釋，它是一個 SQL Mapping 的工具，抽象程度高於 JDBC，但是卻低於 ORM (例如 Hibernate)。簡單來說，iBatis 將系統中會使用到的 SQL 指令皆放置在 XML 檔案內，以避免利用程式本身產生與維護 SQL 指令時的困擾。相較於 JDBC，iBatis 也提供了像是 Cache、Transaction Management 等高階的功能，幫助系統開發者簡化資料庫的相關操作。而因為某些原因，iBatis 已經改名為 MyBatis，不過基本上兩者是一樣的。反倒是目前 MyBatis 有 2.x 與 3.x 兩個主要版本，兩者之間卻是不相容的。 回到 SQL Injection 本身，用了 iBatis/MyBatis 就沒有 SQL Injection 的問題了嗎？聰明的讀者，您一定想到了答案。因為如果答案是肯定的，就沒有這篇文章存在的必要性， 所以答案就是即使使用了 iBatis/MyBatis，並不能保證系統就沒有 SQL Injection 的問題。基本上，iBatis/MyBatis 雖然會以 PreparedStatement 的方式執行 SQL 指令，但是就像我在之前文章內的說法一樣，光使用 PreparedStatement 並無法完全杜絕 SQL Injection 的攻擊。主要的問題發生於在當使用 inline 方式宣告 SQL 指令的參數時，iBatis/MyBatis 允許兩種參數傳遞的宣告方式，一種是利用 #，另外一種則是透過 $，而後者正是問題所在。$ 表示將參數的內容直接附加於 SQL 指令之內，而不是使用參數化的設定。因此只要使用了 $ 的方式來傳遞參數，就有可能遭受 SQL Injection 的攻擊。 此外，iBatis/MyBatis 也支援所謂 Dynamic SQL 的功能。我們之前提到 Dynamic SQL 正是 SQL Injection 的元兇，但是使用 iBatis/MyBatis 的 Dynamic SQL 卻並不表示就有 SQL Injection 的問題，還是必須取決於參數傳遞的方式。如果使用 # 的方式傳遞參數，即使使用 iBatis/MyBatis 的 Dynamic SQL 依舊是安全的。結論知道了，接下來還是透過簡單的範例程式來看看問題是如何發生的。

DoS/DDoS (阻斷服務攻擊) 對許多人來說，早已經是耳熟能詳的名詞。以 DoS 的定義來說，只要能夠讓服務中斷，不管用什麼方法都可以算是 DoS 的攻擊。所以，拿榔頭把連結伺服器的路由器給敲爛，絕對也是 DoS 攻擊的一種。這樣的攻擊方式除了被逮捕的風險高了許多，而且在效率上也不夠好。所以除非你跟某家企業有深仇大恨，而且報著必死的決心，不然請勿輕易嘗試此一作法。也因此以網路為主的遠端 DoS/DDoS 才是主要的攻擊手法，駭客想盡一切辦法讓使用者無法連結到某個企業的網路服務，像是把網路頻寬或伺服器的運算資源消耗殆盡。 而這一兩年極為熱門的話題 - SaaS (或大家比較常聽到的雲端運算)，除了它本身產生的資安考量外，SaaS 與 DoS/DDoS 還有其他的關聯。首先，SaaS 的架構讓駭客擁有了更多且更便宜 (甚至免費) 的資源來對攻擊目標的資源進行消耗的行為。嚴格來說，甚至可以說是以 Botnet 為主的地下經濟本身就是一種 SaaS 的服務，只是買方甚至連軟體都不用操作就可以收到結果。另外之前提到利用 SaaS 架構提供破解 WPA 的服務，雖然不是用來進行 DoS/DDoS 的攻擊，卻也是利用 SaaS 來增強破壞力的應用。 除此之外，隨著 SaaS 架構的風行，有人預計利用 DoS/DDoS 攻擊手法來對企業進行威脅的事件將會持續增加。原因之一是很多 SaaS 架構採用用多少算多少的計費方式，這樣的方式也就表示用的越多，帳單的金額就越高。在此情況下，DoS/DDoS 攻擊就算無法癱瘓企業的網路服務，也將使得帳單金額大增。因此，駭客可以利用這樣的預期損失而對企業進行事前的勒索。我個人覺得這雖然有其道理，但是 SaaS 的服務通常可以設定帳單金額的上限，所以在最差的情況下，被攻擊企業的網路服務也”只是”完全停擺，並不會有金額大爆炸的情況發生。倒是 SaaS 的模式，讓企業遭受 DoS/DDoS 攻擊時的損失容易量化，因此方便駭客對勒索金額進行”合理的”喊價。不論如何，當 SaaS 讓資源的應用變成價格化後，DoS/DDoS 攻擊已經不再只是單純的”給他死”，而有更多的操作空間可以讓駭客獲取利益。這年頭，當駭客不但要有技術能力，還得有商業頭腦才行。   相關連結：

雖然大多數的人跟我一樣，都不是密碼學的專家，但是密碼學的應用卻充斥在我們的日常生活之中。從你買東西時使用信用卡付賬，到在網路上進行購物，甚至是你每天登入到作業系統，都跟密碼學有關。密碼學的中文說法，其實很容易讓人產生誤解，因為密碼學講的並不是我們平常登入各式系統所使用的密碼，而是加解密的演算法。雖然比較嚴謹的系統都會將密碼做加密的保護，但是兩者之間卻沒有必然的關係，而密碼學就是一門充滿了各式各樣演算法的學問。這些複雜的演算法，往往都不是由資訊專家所提出，而是數學家所苦心研究出來地成果，並經過外界公開的審視。儘管演算法在被公開接受並採用前往往已經經過了仔細的評估，但是卻沒有一個演算法本身是絕對安全的。所有的演算法至少都會遭遇一種手法的攻擊，那就是所謂的暴力攻擊法。簡單的說，暴力攻擊法就是利用強大的運算能力，將加密或解密的各種可能性逐一計算，最後獲得所需資訊的手法。既然所有的演算法都會遭受暴力攻擊法的攻擊，那麼為什麼密碼學的應用還會被大量採用在我們日常生活當中呢？原因很簡單，就是因為暴力破解法所需的強大運算往往在現今的技術下是無法有效地加以實現，也因此我們的資料”暫時”是安全的。 除非是很特殊的組織或個人，否則一般駭客能夠用來破解加密資料的工具還是最常見的個人電腦設備。傳統上我們常用的電腦設備主要透過中央處理器  (CPU) 處理各式各樣的運算需求，而中央處理器本身是一個通用的處理器，所以對於處理大量的數學運算並不在行。儘管隨著技術的進步，中央處理器的處理速度已經大為提昇，但是先天的定位註定中央處理器一旦遇到複雜的數學運算就是只能吃憋。 而電腦內部除了中央處理器之外，往往還有另外一個處理器，稱之為繪圖處理器 (GPU)。繪圖處理器顧名思義就是用來處理圖型顯示的運算，而圖型顯示正需要大量的數學運算，所以繪圖處理器天生就是數學運算的高手。其實繪圖處理器的存在由來已久，但是因為市場需求的關係，之前繪圖處理器的發展速度並不如中央處理器那般快速。而近年來遊戲與網路多媒體的蓬勃應用，讓繪圖能力的重要性越趨重要。再加上技術的成熟，因此繪圖處理器的處理速度大幅增進，尤其是這樣的技術應用已經相當普及，而不像過去繪圖處理器是有錢人的專屬玩具。也因為這樣的發展，所以繪圖處理器的強大數學運算能力不但可以用在繪圖功能上，更有人開始發揮創意並開發新的應用，而其中一個應用就是用來破解加密的資料。一旦這樣的運用普及化，我們對於演算法的安全性就必須重新加以思考，因為所謂的”暫時”安全可能已經不再是”暫時”，而僅僅只是一瞬間的時間。至於在實際上會有多大的影響層面，就讓我們持續觀察吧。

在上個月的一篇文章中，我們看到 WhiteHat Security 對於避免 SQL Injection 的危害提出了 10 個手法。其中第 7 個手法，使用”參數化的查詢 (在 Java 的程式語言中主要是透過 PreparedStatement 來提供) 並避免使用動態式的查詢”對許多人來說應該算是老生常談了。事實上，程式內未採用參數化查詢大多不是因為技術上的考量，因為除了極少數的情況 (通常與效能有關) 外，參數化查詢都是可以順利運作的。在無法採用參數化查詢的原因中，最常見的情況就是使用了預儲程序 (Stored Procedure)。預儲程序如果小心使用，對於 SQL Injection 其實也有一定的防護能力。但是預儲程序畢竟不像參數化查詢那般嚴謹，所以提供這些功能的程式碼無法事先做太多的防範措施，大多數防護的責任還是落在系統開發者自行開發的程式上。而參數化查詢因為會嚴格限制每個參數的型別，所以提供此一功能的程式就可以做好萬全的準備，讓系統開發者在撰寫自己的程式時不需太過擔心。所以除非被限制必須使用預儲程序來存取資料，否則我們就應該採用參數化查詢來存取資料。 參數化查詢與預儲程序之間的取捨，往往還有許多其他非技術的因素，但是這並不是我這篇文章的重點，所以這個問題就在此打住。當我們確實採用了參數化的查詢後，是否就可以對 SQL Injection 高枕無憂了呢?很可惜的是，答案依舊是否定的。如果我們仔細審視第一段的藍色文字，可以發現後半段是避免使用動態式的查詢。而前、後段文字使用”並”加以連結，所以一旦使用者違反了後半段文字的限制，即使使用參數化查詢依舊會遭受 SQL Injection 的攻擊。因為這點對於部分的系統開發者來說或許並不是那麼熟悉，所以接下來我將以實際的例子 (Java 語法) 來加以說明。我假設我們擁有一個稱為 users 的資料表，內含 name 與 password 兩個欄位，分別表示使用者的姓名與密碼。而在此資料表中有一個使用者的姓名與密碼分別為 ‘cyril wang’ 與 ’1234’。

知名的微網誌 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 小時不中斷的安全機制與應變機制，對所有網站的經營者而言都是必須去認真思考的一個課題。   相關連結：

雖然 SQL Injection 提出至今已經經過了許多年，但是 SQL Injection 依舊是目前網站應用程式的主要弱點之一，更是資料外洩的主要管道。根據 WhiteHat Security 的一份 White Paper 的內容指出，可以採用下列 10 個方法來避免 SQL Injection 產生危害： 將資料庫與網站伺服器分別安裝在不同的機器上，並確保機器維持在最新的更新狀態。(Install the database on a different machine than the Web server or application server. Make sure all the latest patches are applied.) 應該將資料庫內所有預設帳號與密碼加以關閉，尤其是管理者的帳號更是不可掉以輕心。(The database should have all the default accounts and passwords disabled, including the super-user account.) 建立一個應用程式專用的帳號，並給予其執行任務所需的最小權限。將所有範例表格以及不需使用的 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.) 找出所有需要執行的 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.) 在不需要使用 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.) 檢查輸入 (包含資料類型、長度、格式等) 並去除不必要的內容。(Sanitize the input by validating it in your code.) 使用參數化的查詢並避免使用動態式的查詢。以 Java 為例，應該使用 PreparedStatement 物件而非 Statement 物件。(Use parameterized queries instead of dynamic queries. For example, in Java, use Prepared Statement instead of Statement Object.) 採用合適的錯誤處理與記錄功能以確保資料庫發生錯誤時的訊息或其他技術資訊不會因此而洩漏。(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.) 選擇不易猜測的資料庫表格/欄位名稱。(Choose names for tables and fields that are not easy to guess.) 盡可能的使用 stored procedures。(Use stored procedures instead of raw SQL wherever possible.)

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



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

根據前幾天的消息指出，來自臺灣的資訊安全廠商 Armorize 發現了在著名的主機代管業者 Network Solutions 中，有大量客戶的網站遭受到惡意程式的感染，並成為惡意程式散佈的平台。而根據 Armorize 的估算，受感染網站的數量可能高達五百萬個，創下新的歷史紀錄。此次感染的方式，據悉是透過一個已被植入惡意程式的小工具 (Widget)，這個小工具名為 Small Business Success Index，是由 Network Solutions 所提供。此一小工具不但可以運作在 Network Solutions 客戶的網站中，也可以安裝在 Facebook, Blogger, Twitter, iGoogle, WordPress, LinkedIn, my Yearbook 等知名的服務平台上。目前官方的建議解決方案是將此一小工具先行移除，並對你的網站進行惡意程式的掃描，以避免繼續散佈惡意程式。而 Armorize 也特別指出這類針對主機代管業者的攻擊行為對駭客來說是可以讓惡意程式快速擴散的有效方法，因此類似的事情在未來將會越來越多，值得相關業者好好地重視。   相關連結： Security Alert: Malware found on Widget @ Network Solutions SMCI widget and growsmartbusiness.com by Network Solutions still serving malware, part 1/3 @ Armorize Record Five Million Sites Were Likely Infected by Hacked Web Widget。