就是資安

前幾天無意間聽到有人提到 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 依舊是安全的。結論知道了，接下來還是透過簡單的範例程式來看看問題是如何發生的。

雖然 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.)

不管安全議題是不是雲端運算日後能否蓬勃發展的主要障礙，安全議題目前確實是組織在決定是否採用雲端運算技術時最擔憂的考量。對此 Global Knowledge 發表了一份白皮書 – 10 Security Concerns for Cloud Computing，內文當中提到了在採用雲端服務前必須確認的 10 個問題。這 10 個問題分別是 資料在哪裡？(Where’s the data?)
不同的國家或地區對於資料保護的法規與規範相當分歧，而且有些法規會限制資料所能存放或流經的地區。 誰擁有存取的權限？(Who has access?)
內部攻擊往往導因於鬆散或錯誤的權限管理，了解授權的管理流程與控管機制可作為你判斷的依據。 有任何法規上的規範嗎？(What are your regulatory requirements?)
法規擁有絕對的強制性，因此必須了解業務所在地與產業的法規規範，並確認採用雲端服務後可以符合相關的規範。 你是否擁有稽核的權力？(Do you have the right to audit?) 供應商對於員工的教育訓練計畫。(What type of training does the provider offer their employees?)
人永遠是資訊安全中最脆弱的一個環節，良好的員工教育訓練除了可以減少人為的疏失，更可以增進服務的能量。 供應商採用何種資訊分類系統。(What type of data classification system does the provider use?)
了解供應商如何對客戶的資料進行分類，又如何保護這些分類過後的資料。保護不侷限於存放中的資料，更包含保護使用與傳輸中的資料。此外，不同客戶間的資料如何隔離也是必須注意的地方。 服務水準協議的內容。(What are the service level agreement (SLA) terms?)
所有的服務事項必須以合約為主，所以服務水準協議的內容必須明確的記載服務的範圍與各項量測數據。 供應商長期提供服務的可行性。(What is the long-term viability of the provider?)
為避免日後轉換系統的困擾，應該盡可能找尋能夠長期合作的供應商。因為雲端服務尚屬新興市場，在缺乏足夠的歷史資料以供參考的情況下，慎選供應商顯得更形重要與困難。 發生安全事件時的處理方式。(What happens if there is a security breach?)
雖然供應商不斷強調自身系統的安全性，但是雲端服務的系統對駭客而言依舊是一個極具吸引力的目標，更何況沒有任何的系統擁有絕對的安全，所以了解一旦發生資訊安全的問題時供應商將提供哪些協助是相當重要的課題。 災難復原與業務持續計畫。(What is the disaster recovery/business continuity plan (DR/BCP)?)
除了了解災難與業務持續計畫的內容外，最重要的是確認其 RTO/RPO 符合你自身業務的需求。

常常進行網路瀏覽的使用者一定有一個感受，那就是有很多的機會都需要填寫一些繁瑣的表格，而其中有很多基本資料 (例如姓名、電話) 甚至是不斷重複出現的。為了減少使用者的困擾，有不少相關的外掛工具可以幫助使用者自動填寫一些標準的欄位。而除了透過外掛工具外，大多數瀏覽器還內建了另外一個較為陽春的功能，就是會把之前填寫過的網頁資料記錄下來，而下次當你需要重複填寫同一個網頁時，這些資料就可以自動出現。這個功能首先由 Microsoft 所推出，稱之為 auto complete。 自動記憶曾經利用這台電腦的瀏覽器 (此例為 Chrome) 登入過 facebook 的帳號。 以畫面上的例子而言，瀏覽器會把使用者曾經輸入到 Facebook 電郵地址欄位的資料記憶下來，並根據使用者已經輸入的資料顯示合適的建議。這個情況出現在自己的電腦上，我相信沒有太多人會因此而感到不安。但是如果這個情況出現在一台公用的電腦上，那麼就會產生一些值得討論的議題。首先雖然以資訊安全的角度來說使用者的帳號也是需要保密的資料之一，但是對於大多數的使用者而言帳號並不是什麼極具機密的資料，儘管帳號就是自己的電郵地址亦然。也就是說以 Facebook 這個例子而言，對使用者來說往往並不會造成困擾，而且也不致於造成實際的損失。但是如果今天自動顯示的資料不是一個電郵地址，而是身分證字號、甚至是信用卡卡號呢？

雖然有關雲端安全的議題跟雲端運算本身一樣持續發燒，也有越來越多的廠商推出相關的服務/產品，但是不可否認安全議題依舊是導入雲端運算的主要瓶頸之一。對此，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)

在前幾天的文章中，我們提到 Facebook 成為釣魚攻擊目標第四名的這個警訊。為什麼說是警訊呢？因為前三名 (PayPal、eBay、HSBC) 的網站，雖然在台灣也有提供服務，但是真正的使用人數都不及 Facebook 來的多。而且使用 Facebook 的人，涵蓋層面較廣，其中不乏許多對於網路安全意識較為薄弱的使用者。再加上一般人的認知上 Facebook 並不是什麼很重要的服務 (相較於購物網站或網路銀行而言)，所以更容易因此失去了警戒心。這些因素再再都會使得 (針對 Facebook 的) 釣魚攻擊更加容易成功。 要避免遭受釣魚攻擊，作法其實很一般性。也就是說，保護網路銀行帳號跟保護 Facebook 帳號在觀念與基本作法上並沒有太大的差別，只是因為網路銀行包含更多且更值錢的資料，所以需要採用更謹慎的心態。根據 Anti-Phishing Working Group (APWG) 的文件，建議使用者採用下列方法以保護自己： 對於緊急要求提供個人財務相關資訊 (如銀行帳號) 的電子郵件保持懷疑的心態。 如果你無法確認發訊者的身分或意圖，不要直接點選電子郵件、即時訊息、或聊天訊息內的連結

• 事實上，因為很多釣魚攻擊也會透過蠕蟲的概念散布給親朋好友，所以就算是已經知道發訊者確實為自己所熟知的人，也要盡量避免直接點選訊息內附的連結。

不要在電子郵件內的表單填寫個人財務相關資訊。 當你在填寫信用卡或其他敏感性的資料時，務必確保你連結的是安全的網站。

• 所謂安全的網站至少必須採用 SSL 的加密方式，而且擁有由第三方所發放的合法憑證。

記得並不是所有網站都會顯示 https。

• 當你連結網址時，必須特別注意網址列所顯示的網址是否正確。關於此點，其實有些難度。因為釣魚網站的攻擊者，會使用一些障眼法來讓干擾使用者的判斷。光是 l 與 1　的差別，就可以讓很多使用者中招。儘管如此，多一份小心總是好的。

安裝能夠保護你避免受到惡意網站攻擊的瀏覽器工具。

• 事實上，很多新版的瀏覽器都已經具備偵測釣魚網站的能力。不過因為使用的資料來源不一，所以各家的偵測與防護能力也有所差別。
• 因此盡管瀏覽器已經內建偵測能力，個人建議還是可以安裝額外的工具 (如 SiteAdvisor) 加以保護。除了可以提供雙重的防護外，也可以減少不同瀏覽器之間的差異。

定期登入你的帳號。 定期檢查你的銀行帳號、信用卡、債務帳單，以避免非法交易的產生。 確保你的瀏覽器保持在最新的更新狀態。

• 目前常見的瀏覽器，都提供了自動更新的功能。儘管如此，仍舊必須小心該功能是否被關閉了。
• 另外一個必須注意的問題就是當瀏覽器進行大改版時 (如由 Firefox 2 改版成 Firefox 3)，自動更新是否依舊有。而當因為某些原因不能進行版本更新時，必須確保舊版本仍受到原開發商的維護。

當你發現釣魚網站或假冒網站時回報給相關的組織。

• 因為這類組織幾乎都是使用外文 (英文) ，所以對某些使用者或許會有執行上的困難。事實上，這個動作比較偏向救人，而不是自救。

筆記型電腦 (Notebook/Laptop) 不但已經成為許多消費者選購電腦的首選，而且在企業的應用也越來越廣泛。因為筆記型電腦越來越輕便，而且相對來說屬於價格高昂的電子設備，因此也引起許多竊賊的覬覦。除此之外，因為隨處可用、可連網的特性，也讓筆記型電腦遭受安全危害的機會大大增加，因此筆記型電腦的安全問題對許多組織來說已經是一個不可不正視的問題。 基本上筆記型電腦還是屬於電腦的一種，因此一些對於電腦安全的基本觀念與做法也同樣適用於筆記型電腦。例如像是安裝防毒軟體與定期更新等作法，對筆記型電腦來說同樣不可省略。但是因為筆記型電腦具備高移動性，所以特定問題所產生的危害相對提高不少，其中尤其是有關實體安全的部分，更是筆記型電腦目前所遭遇的最大危害。 以下我整理一些有關筆記型電腦的使用安全建議事項，希望對各位能夠有所幫助： 實體安全

資料外洩的議題持續成為資訊安全的熱門話題，不但 DLP 相關產品獲得許多的關注，連資料外洩所造成的事件也同樣吸引媒體的報導。以現在企業資訊化的程度，很多資料都是以數位的形式散落於資訊系統的各處。在這些地方中，資料庫 (尤其是關聯資料庫，如 MSSQL) 內所存放的數位資料可能最為大宗，也最容易成為有心分子覬覦的目標。 Imperva 的安全策略長 Brian Contos 發表了一份文章，標題為”Top-10 guide for protecting sensitive data from malicious insiders”。不管標題為合，以 Imperva 的背景來看，所描述的內容自然與該公司的產品 (Database Firewall、Database Activity Monitoring) 有關。所以我們可以將這份內容所講的要項當作是闡述資料庫稽核的重要性，以及如何選擇一個合適的工具。也因此，如果你需要導入資料庫安全的相關產品，這些要項應該可以提供你一些參考的方向。 你必須先了解資料才有辦法保護它 (To secure it you have to know about It)
也就是說必須先知道資料在哪邊，並做好資料分類的動作。 不要相信內建的資料庫工具 (Don’t trust native database tools)
當資料庫遭受攻擊時，資料庫內建的工具也可能同時被成功地加以攻擊，因此需要一個獨立運作的工具以確保資料庫使用紀錄的安全性。 監視合法的使用者以及特權使用者 (Monitoring the good and the privileged)
除了非法的使用者外 (不管是內部或外部)，內部合法的使用者同樣會造成資料庫的危害。尤其在一個正常規劃的架構下，資料庫幾乎都是經由內部合法的使用者加以存取，因此監測的角度必須據此加以思考。此外，特權使用者因為擁有更大的權限，因此其使用記錄必須特別注意。 分析不再只是 FBI 的工作 (Profiling isn’t just for the FBI any more) 你不能逮捕一個 IP 位址 (You can’t arrest an IP address)
各式各樣的資料庫與應用系統擁有不同格式的使用紀錄，必須擁有透過這些紀錄追蹤使用者連線 (Session) 的能力，才能確保事件發生時找到其源頭。 以人為導向的自動分析能力 (Augmenting machine-based analytics with human intuition)
組織內不同角色的人員會從不同角度切入資料庫安全的議題，所以必須具備自動且多樣性的分析能力。 利用稽核紀錄了解犯罪現場的情形 (Forensic crime scene investigation through audit logs)
透過分析的結果讓使用者可以快速了解：發生了甚麼事、事件發生的時間點與持續的時間、甚麼人可能參與了此一事件等重要議題。 機密的資料存放於資料庫內 (Sensitive data resides in databases)
使用 Database Firewall (DBFW) 與 Database Activity Monitoring (DAM) 之類的工具來保護資料庫內重要的數位資產。 使用者透過 Web 應用程式來存取資料庫 (Users get to databases through web applications)
因為使用者大多透過應用程式 (尤其是現今主流的 Web 應用程式) 來存取資料庫內的資料，因此如何確保 Web 應用程式的安全對資料庫本身的安全來說是一個很重要的工作。Web Application Firewall (WAF) 是一個不錯的起點。 大海撈針 (Needles hiding in stacks of needles)
因為現今資訊系統的複雜度很高，所以如果沒有一個完整且全面的防禦機制並搭配上合適的工具，想要有效解決地問題將有如大海撈針般的困難。