Web Security 網站安全基礎

Written by Allen Own    Friday, 21 May 2010

前言

網路安全一直都是相當重要的議題，網站就是所有使用者的入口，提供各種服務的網站也有著各式各樣的風險，因此網站一直以來都是駭客攻擊的首要目標。 一個網站的安全與否取決於很多因素，作業系統的版本、網站應用程式的撰寫、架構的設計、使用者的設定等等。只要任何一個環節出問題，都會導致整個網站暴露 於風險之中。技術層面來看，管理者必須要時時跟隨系統應用程式的腳步，注意最新的消息、技術和攻擊手法，因應進行修補及防護，才能確保系統處於安全的狀態。

「沒有不安全的系統，只有不安全的人」

人們在探討資訊安全的時候，往往會有一個想法，就是什麼系統是不安全的，什麼軟體是不安全的，甚至什麼公司出產的軟體都是有問題的。但是其實大家必 須要有一個觀念，多數的情況，不安全的其實是人，而不是系統。一個再安全的系統，只要管理者做出了錯誤的設定，攻擊者就可以因此直接進入到我們的系統。在 我們遇到的案例中，多數的弱點都是由管理者的疏忽所發生的。

為什麼資訊安全的重要性越來越高？主要是因為網路為主的應用大量增加，開發技術也越來越簡易，使用攻擊程式進行攻擊的門檻也日漸降低。因此只要有心 人士找到相對應版本的攻擊程式，就可以輕易的對我們的主機進行攻擊。

Google Hacking！

攻擊的門檻到底有多低呢？利用 Google Hacking 這樣的手法，就可以對一個網站進行攻擊。Google Hacking 是一個無技術門檻的攻擊手段，藉由網站管理者錯誤的設定及疏失，以及 Google 搜尋 Index 的能力，搜索可攻擊的網址。攻擊者可以因此取得網站資訊、攻擊標的和暴露的弱點等等。

Google Hacking 到底有多危險呢？以下圖為例，我們只要在網路上搜尋一些字串，就可以取得一些令人驚訝的資訊。例如說我們搜尋「密碼表 ext:xls」，就會找到以下的資訊。有心人士就可以因此利用以下的資訊進行進一步的攻擊。還有其他攻擊手法，可以找到其他系統資訊，我們在這邊就不多 做介紹。如果想要知道更多 Google Hacking 的語法，可參考以前的 「Google Hacking Database」，可 以找到一些相關的範例。

這些問題有一大部分都是因為人為的因素。因此，在探究系統的安全之前，管理者必須先從自身做好資訊安全的規劃。從技術、知識到思維，都要做好建設。

駭客想的跟你不一樣！

在了解系統該怎麼防護之前，一定要先了解駭客的思維，因為駭客想的跟你不一樣！一般來說，駭客攻擊的流程可以分為五個步驟：偵查、掃描、取得權限、 維持權限、清除足跡。

偵查 (Reconnaissance)

攻擊者準備攻擊之前進行的偵查，找尋目標的相關資訊，以利之後的攻擊。

掃描 (Scanning)

掃描目標主機的弱點，取得主機作業系統、服務和運作狀況等資訊。

取得權限 (Gaining Access)

利用系統弱點取得主機權限。

維持權限 (Maintaining Access)

維持目前取得的權限，以便日後再次存取而不需繁雜的步驟。

清除足跡 (Clearing Tracks)

清除入侵的痕跡。

真實攻擊事例

讓我們來看看一個真實的駭客案例。

駭客鎖定了一個受害者網站，從 Google 上搜尋此網站所有的相關資訊。並利用 Google Hacking 技術找到所有網站暴露的目錄及檔案。

接著，經由網站找到的弱點，嘗試進行攻擊。並且植入 Web Shell 後門，透過網頁連入操控主機。例如：http://victim.org/webshell.php?cmd=oxox

連入主機後發現帳號權限不足，因此從主機內尋找可用的資訊。例如從 /etc/passwd 找尋可用帳號，利用 /var/log 查詢系統可用資訊，或者搜尋有無 setuid 檔案可供利用。

下個步驟，駭客發現主機 Kernel 版本過舊，有可提權的弱點。因此撰寫或搜尋 Exploit 進行攻擊，取得 root 管理者權限。

得到權限後，為了方便連入主機，放置後門供日後使用。常用的手法例如建立主機帳號、/etc/rc.d 放置後門，代換 sshd 系統服務等。

最後，清除自己的足跡，例如指令記錄檔及系統紀錄。

~/.history
~/.bash_history
/var/log/*

這是一個很簡單的駭客思維，但是只要我們了解這些，就能夠知道駭客是怎麼進行一次完整的入侵行為，進而知道該如何去防禦。

該如何去確保網站安全？

就如同前面所講，網站是一個窗口，使用者經由網站取得資訊，攻擊者也經由網站進行攻擊。因此網站的防護就是第一道防線。如果第一道防線都沒有做好， 那攻擊者就可以長驅直入。那我們到底要怎麼去確保網站安全呢？目前網路上 OWASP 組織有提供各種防護方法以及弱點介紹，讓網站管理者依循維護及修改。

我們會在下面繼續有關 OWASP 的詳細介紹。

接下來我們要介紹身為開發者的我們，要如何去確保自己的網站應用程式是安全無虞的。透過網路上 OWASP 組織提供的防護方法以及弱點介紹，我們可以很快的檢視自己的網站是否有安全弱點。以下我們會介紹 OWASP Top 10 十大網站安全弱點，以十項最常見的弱點來介紹網站的安全問題。


Open Web Application Security Project  開放網站應用程式安全計畫

OWASP 是一個開放社群的非營利組織，致力於改善網站應用程式的安全性。OWASP Top 10 揭露常見的網站應用程式弱點，以供軟體開發安全參考。 OWASP Top 10

通常我們會針對 OWASP Top 10 來進行基本的網站安全風險說明。目前 OWASP Top 10 釋出 2010 年版。十大風險如下：

A1 – Injection（注入攻擊）
A2 – Cross Site Scripting (XSS)（跨站腳本攻擊）
A3 – Broken Authentication and Session Management（身分驗證功能缺失）
A4 – Insecure Direct Object References（不安全的物件參考）
A5 – Cross Site Request Forgery (CSRF)（跨站冒名請求）
A6 – Security Misconfiguration（安全性設定疏失）
A7 – Failure to Restrict URL Access（限制 URL 存取失敗）
A8 – Unvalidated Redirects and Forwards（未驗證的導向）
A9 – Insecure Cryptographic Storage（未加密的儲存設備）
A10 – Insufficient Transport Layer Protection（傳輸層保護不足）

以下針對這十大風險做一個簡單的介紹。

A1 – Injection（注入攻擊）

網站應用程式執行來自外部包括資料庫在內的惡意指令，SQL Injection 與 Command Injection 等攻擊包括在內。 因為駭客必須猜測管理者所撰寫的方式，因此又稱「駭客的填空遊戲」。

舉例來說， 原本管理者設計的登入頁面資料庫語法如下：

$str = "SELECT * FROM Users WHERE Username='“.$user."' and Password=‘”.$pass."'“;

如果說 $user 以及 $pass 變數沒有做保護，駭客只要輸入「’ or ‘‘=’」字串，就會變成以下：

$str = “SELECT * FROM Users WHERE Username='' or ''='' and Password= '' or ‘’=‘’”;

如此一 來，這個 SQL 語法就會規避驗證手續，直接顯示資料。

簡述駭客攻擊流程：
1. 找出未保護變數，作為注入點
2. 猜測完整 Command 並嘗試插入
3. 推測欄位數、Table 名稱、SQL 版本等資訊
4. 完整插入完成攻擊程序

防 護建議：
● 使用 Prepared Statements，例如 Java PreparedStatement()，.NET SqlCommand(), OleDbCommand()，PHP PDO bindParam()
● 使用 Stored Procedures
● 嚴密的檢查所有輸入值
● 使用過濾字串函數過濾非法的字元，例如 mysql_real_escape_string、addslashes
● 控管錯誤訊息只有管理者可以閱讀
● 控管資料庫及網站使用者帳號權限為何

A2 – Cross Site Scripting ( XSS )（跨站腳本攻擊）

網 站應用程式直接將來自使用者的執行請求送回瀏覽器執行，使得攻擊者可擷取使用者的 Cookie 或 Session 資料而能假冒直接登入為合法使用者。

此為目前受災最廣的攻擊。簡稱 XSS 攻擊。攻擊流程如下圖：

1. 受害者登入一個網站
2. 從 Server 端取得 Cookie
3. 但是 Server 端上有著 XSS 攻擊，使受害者將 Cookie 回傳至 Bad Server
4. 攻擊者從自己架設的 Bad Server 上取得受害者 Cookie
5. 攻擊者取得控制使用受害者的身分



防護建議：
● 檢查頁面輸入數值
● 輸出頁面做 Encoding 檢查
● 使用白名單機制過濾，而不單只是黑名單
● PHP 使用 htmlentities 過濾字串
● .NET 使用 Microsoft Anti-XSS Library
● OWASP Cross Site Scripting Prevention Cheat Sheet
● 各種 XSS 攻擊的 Pattern 參考

A3 – Broken Authentication and Session Management（身分驗證功能缺失）

網站應用程式中自行撰寫的身分驗證相關功能有缺陷。例如，登入時無加密、 SESSION 無控管、Cookie 未保護、密碼強度過弱等等。

例如：

應用程式 SESSION Timeout 沒有設定。使用者在使用公用電腦登入後卻沒有登出，只是關閉視窗。攻擊者在經過一段時間之後使用同一台電腦，卻可以直接登入。

網站並沒 有使用 SSL / TLS 加密，使用者在使用一般網路或者無線網路時，被攻擊者使用 Sniffer 竊聽取得 User ID、密碼、SESSION ID 等，進一步登入該帳號。

這些都是身分驗證功能缺失的例子。

管理者必須做以下的檢查：
● 所有的密碼、 Session ID 、以及其他資訊都有透過加密傳輸嗎？
● 憑證都有經過加密或 hash 保護嗎？
● 驗證資訊能被猜測到或被其他弱點修改嗎
● Session ID 是否在 URL 中暴露出來？
● Session ID 是否有 Timeout 機制？

防護建議：
● 使用完善的 COOKIE / SESSION 保護機制
● 不允許外部 SESSION
● 登入及修改資訊頁面使用 SSL 加密
● 設定完善的 Timeout 機制
● 驗證密碼強度及密碼更換機制

A4 – Insecure Direct Object References（不安全的物件參考）

攻擊者利用網站應用程式本身的 檔案讀取功能任意存取檔案或重要資料。進一步利用這個弱點分析網站原始碼、系統帳號密碼檔等資訊，進而控制整台主機。

例 如：http://example/read.php?file=../../../../../../../c:\boot.ini。

防 護建議：
● 避免將私密物件直接暴露給使用者
● 驗證所有物件是否為正確物件
● 使用 Index / Hash 等方法，而非直接讀取檔案

A5 – Cross Site Request Forgery (CSRF)（跨站冒名請求）

已 登入網站應用程式的合法使用者執行到惡意的 HTTP 指令，但網站卻當成合法需求處理，使得惡意指令被正常執行。

舉例來說，攻擊者在網 站內放置了 <img src=”http://server.com/send.asp?to=...”> ，受害者讀取到此頁面之後，就會去 server.com 主機執行 send.asp 惡意行為。

例如 Web 2.0 時代的社交網站等等，都是 CSRF 攻擊的天堂。

防護建議：
● 確保網站內沒有任何可供 XSS 攻擊的弱點
● 在 Input 欄位加上亂數產生的驗證編碼
● 在能使用高權限的頁面，重新驗證使用者
● 禁止使用 GET 參數傳遞防止快速散佈
● 使用 Captcha 等技術驗證是否為人為操作

或者參考  OWASP 所提供的 CSRF Solution
● OWASP CSRFTester Project
● OWASP CSRFGuard Project
● OWASP CSRF Prevention Cheat Sheet

A6 – Security Misconfiguration（安全性設定疏失）

系統的安全性取決於應用程式、伺服器、平台的設定。因此 所有設定值必須確保安全，避免預設帳號、密碼、路徑等。甚至被 Google Hacking 直接取得攻擊弱點。

防護建議：
● 軟體、作業系統是否都有更新到最新版本？是否都有上最新 Patch?
● 不需要的帳號、頁面、服務、連接埠是否都有關閉？
● 預設密碼是否都有更改？
● 安全設定是否都完備？
● 伺服器是否都有經過防火牆等設備保護？

各種設備、系統的預設密碼， 都可以在網路上找到一些整理資料。
http://www.phenoelit-us.org/dpl/dpl.html
http://www.routerpasswords.com/
http://www.defaultpassword.com/


A7 – Failure to Restrict URL Access（限制 URL 存取失敗）

網頁因為沒有權限控制，使得攻 擊者可透過網址直接存取能夠擁有權限或進階資訊的頁面。例如管理介面、修改資料頁面、個人機敏資訊頁面洩漏等等。

舉例來說，
/admin
/backup
/logs
/phpmyadmin
/phpinfo.php
/manage
這 些都是常見的路徑及檔案。攻擊者只要猜測到，就可以操弄主機。

防護建議：
● HTTP Service 直接限制來源 IP
● 使用防火牆阻擋
● 密碼授權加密頁面
● 網站架構最佳化

A8 – Unvalidated Redirects and Forwards（未驗證的導向）

網頁應用程式經常將使用者 Forward 或 Redirect 至其他頁面或網站，沒有驗證的機制。攻擊者可將受害者導向至釣魚網站或惡意網站，甚至存取受限制的資源。

例如：
http://example.cc/redir.jsp?url=evil.com
http://example.cc/func.jsp?fwd=admin.jsp
http://g.msn.com/9SE/1?http://xxx.com

防 護建議：
● 非必要時避免使用 Redirect 及 Forward
● 驗證導向位置及存取資源是合法的

A9 – Insecure Cryptographic Storage（未加密的儲存設備）

網站應用程式沒有對敏感性資料使用加 密、使用較弱的加密演算法或將金鑰儲存於容易被取得之處。加密演算法是安全防護的最後一道防線，當駭客取得了帳號密碼，可以簡單的使用一些破解軟體甚至線 上服務進行破解。例如 Cain & Abel，MD5 Reverse Lookup 等。

防護建議：
● 使用現有公認安全的加密演算法
● 減少使用已有弱點的演算法，例如 MD5 / SHA-1，甚至更簡單的加密法
● 安全的保存私鑰

A10 – Insufficient Transport Layer Protection（傳輸層保護不足）

網頁應用程式未在傳 輸機敏資訊時提供加密功能，或者是使用過期、無效的憑證，使加密不可信賴。

例如：攻擊者竊聽無線網路，偷取使用者cookie；網站憑證 無效，使用者誤入釣魚網站。

防護建議：
● 盡可能的使用加密連線
● Cookie 使用 Secure Flag
● 確認加密憑證是有效並符合 domain 的
● 後端連線也使用加密通道傳輸
● http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Cookie Secure Flag 設定：
● PHP setcookie ("TestCookie", "", time() - 3600, “/", ".example.com", 1);
● JSP cookie.setSecure(true);
● ASP.NET cookie.Secure = True;

小 結

以上 OWASP Top 10 包含了大部分常見的網站安全弱點，但並不是只有這些。管理者必須時時注意最新的資安消息，並且對自己的主機定時進行更新，檢查系統記錄檔，絕不可有僥倖之 心。如此一來，才能確保主機處於安全的狀態。


附錄

以下附上常見的弱點資料庫 以及網站淪陷資料庫，管理者可以定期瀏覽最新的資訊安全消息，並且檢查自己的網站有沒有在淪陷資料庫榜上有名。

弱點資料庫
CVE - Common Vulnerabilities and Exposures (CVE)
SecurityFocus
National Vulnerability Database 
VUPEN Security

網站淪陷資料庫
TW 網站淪陷資料庫
Zone-H
</xssed> 

◎ 作者簡介

翁浩正 ( Allen Own )

網駭科技技術顧問，資安團隊 NISRA 創辦人，多年網路管理、資訊安全、駭客攻防技術經驗，自覺什麼都沒有，只有滿腔熱血。

• Mail：allenown@gmail.com
• Blog：http://allenown.blogspot.com/
• Twitter：http://twitter.com/allenown
• Plurk：http://www.plurk.com/allenown

轉自OSSF