就是資安

前幾天無意間聽到有人提到 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 的攻擊。

雖然 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 點我個人倒是有一些不同的看法。

不管安全議題是不是雲端運算日後能否蓬勃發展的主要障礙，安全議題目前確實是組織在決定是否採用雲端運算技術時最擔憂的考量。對此 Global Knowledge 發表了一份白皮書 – 10 Security Concerns for Cloud Computing，內文當中提到了在採用雲端服務前必須確認的 10 個問題。這 10 個問題分別是

1. 資料在哪裡？(Where’s the data?)
   

常常進行網路瀏覽的使用者一定有一個感受，那就是有很多的機會都需要填寫一些繁瑣的表格，而其中有很多基本資料 (例如姓名、電話) 甚至是不斷重複出現的。為了減少使用者的困擾，有不少相關的外掛工具可以幫助使用者自動填寫一些標準的欄位。而除了透過外掛工具外，大多數瀏覽器還內建了另外一個較為陽春的功能，就是會把之前填寫過的網頁資料記錄下來，而下次當你需要重複填寫同一個網頁時，這些資料就可以自動出現。這個功能首先由 Microsoft 所推出，稱之為 auto complete。

雖然有關雲端安全的議題跟雲端運算本身一樣持續發燒，也有越來越多的廠商推出相關的服務/產品，但是不可否認安全議題依舊是導入雲端運算的主要瓶頸之一。對此，Gartner 預期企業初期在私有雲 (Private Cloud) 的投資會大於公開雲 (Public Cloud)，主要原因就在於企業對於私有雲依舊擁有足夠的掌控權，可以減少與其他人共用平台所產生的額外風險。儘管如此，私有雲畢竟與原先的 IT 架構有所差別，因此在安全的考量上也有其特別之處。如果一味的將私有雲與原先的 IT 架構一視同仁，那麼產生的風險將是無法估算的。

為了因應雲端運算的安全議題，雲端安全聯盟 (CSA, Cloud Security Alliance) 發表了安全指導原則 (Security Guidance)，期望給所有相關人士一些可行的參考方向。目前最新的安全指導原則是在 2009 年年底所公布，版本號碼為 2.1。在這份文件中，將雲端安全分為兩大領域，分別為治理 (Governance) 與維運 (Operation)，其下各有 5 個與 7 個分類，共計 12 個分類：

在前幾天的文章中，我們提到 Facebook 成為釣魚攻擊目標第四名的這個警訊。為什麼說是警訊呢？因為前三名 (PayPal、eBay、HSBC) 的網站，雖然在台灣也有提供服務，但是真正的使用人數都不及 Facebook 來的多。而且使用 Facebook 的人，涵蓋層面較廣，其中不乏許多對於網路安全意識較為薄弱的使用者。再加上一般人的認知上 Facebook 並不是什麼很重要的服務 (相較於購物網站或網路銀行而言)，所以更容易因此失去了警戒心。這些因素再再都會使得 (針對 Facebook 的) 釣魚攻擊更加容易成功。

要避免遭受釣魚攻擊，作法其實很一般性。也就是說，保護網路銀行帳號跟保護 Facebook 帳號在觀念與基本作法上並沒有太大的差別，只是因為網路銀行包含更多且更值錢的資料，所以需要採用更謹慎的心態。根據 Anti-Phishing Working Group (APWG) 的文件，建議使用者採用下列方法以保護自己：

筆記型電腦 (Notebook/Laptop) 不但已經成為許多消費者選購電腦的首選，而且在企業的應用也越來越廣泛。因為筆記型電腦越來越輕便，而且相對來說屬於價格高昂的電子設備，因此也引起許多竊賊的覬覦。除此之外，因為隨處可用、可連網的特性，也讓筆記型電腦遭受安全危害的機會大大增加，因此筆記型電腦的安全問題對許多組織來說已經是一個不可不正視的問題。

基本上筆記型電腦還是屬於電腦的一種，因此一些對於電腦安全的基本觀念與做法也同樣適用於筆記型電腦。例如像是安裝防毒軟體與定期更新等作法，對筆記型電腦來說同樣不可省略。但是因為筆記型電腦具備高移動性，所以特定問題所產生的危害相對提高不少，其中尤其是有關實體安全的部分，更是筆記型電腦目前所遭遇的最大危害。

資料外洩的議題持續成為資訊安全的熱門話題，不但 DLP 相關產品獲得許多的關注，連資料外洩所造成的事件也同樣吸引媒體的報導。以現在企業資訊化的程度，很多資料都是以數位的形式散落於資訊系統的各處。在這些地方中，資料庫 (尤其是關聯資料庫，如 MSSQL) 內所存放的數位資料可能最為大宗，也最容易成為有心分子覬覦的目標。