在一般常見的系統中，很常見到只要一個漏洞被發現，然後攻擊，整台電腦就跟著淪陷，為何這麼的容易，原因出在於，防線只有一道，以戰爭來比擬，你的防線可能有十公里，在這十公里中，只要有個洞就可以讓敵人鑽進來，而進來以後就有如入無人之境，以資訊安全來看，假設你的主機是網頁伺服器，你的戰線有OS、SQL Server、Web Server等等各種可能會被攻擊的點，如果你的防線就只有這樣，那麼很可能只要其中一個環節被拿下就等於整台電腦淪陷，不管你再怎麼加強每個層面，世界上沒有不存在漏洞的系統，不存在沒有漏洞的系統，那我們到底能做什麼? 答案就是 : 深度防禦。

什麼是深度防禦(Defence in depth)

深度防禦最經典的應用，應該要算是應用在核能發電廠，我們都知道核能發電廠有著一定的風險，不容許有一絲的差錯，因為核能電廠的安全是極度重要的，因此核能電廠採取就是深度防禦的策略，說了半天，到底什麼是深度防禦，所謂的深度防禦，就是一層防線後面還有一層防線，每層防線都是獨立的，多元化的、且有備援的，舉個例子來說，核能發電需要水來冷卻反應爐，如果第一套水冷系統失效，還有第二套完全獨立的系統在一旁待命，立刻可以接著運作，如果不幸的，連第二套系統也失靈了，我們還有另一道防線，將控制棒插入反應爐吸收中子，就算這層失敗了，後面還有許多許多層的防線，在很外面有一層圍阻體，就算用戰機高速衝撞也不會有事，因此核能電廠是世界上最安全的電廠，因為這一連串防線要全部失效的機率比慧星撞地球還低，每次看到一些沒道德的環保團體欺騙民眾說核電廠會像車諾比那樣炸掉來反核就很火大，回到正題，雖然主題不是核電廠，不過講到這裡我們大概就可以了解，深度防禦的策略，其思維，還有帶來的好處，與壞處，我們接著就來看在資訊安全上要如何應用

• 多層的防護

一層防禦是不夠的，如你所見只要一層失效了，就等於淪陷，因此深度防禦的理念之一，就是提供多層的保護，一層防火牆不夠? 再加一層，還覺得不夠? 再加一層，不過當然不是加越多防護就越安全，我們繼續看下去

• 多樣性的防護

試想你加了100層防火牆來保護你重要的資料，但這100層防火牆全用的是同一套防火牆，只要這防火牆被發現某種漏洞，這100層的防火牆很可能變得跟紙一樣，因此多樣性是必要的，例如三層不同的防火牆，以駭客的角度來看，想要進入到最裡層就需要突破三層不同的防火牆，從此看來要強行突入的可能性就大大減少

• 獨立的組件

系統的運作最好要能盡量獨立，假設所有系統的驗證是靠另一個系統，而只要那個系統被攻破，就等於依賴那個驗證系統的所有系統也跟著一起完蛋，因此獨立性也是非常重要的

• 備援系統

當你的系統失效時，是否有備援機制? 舉個例子，魔獸世界有通訊鎖，似乎是透過電話來驗證以防止盜帳號，前陣子突然發生通訊鎖失效，玩家抱怨進不了遊戲，於是通訊鎖似乎就因此暫停了小段時間，以攻擊者的角度來看，如果是我要盜取帳號，就可以從這裡下手，首先癱瘓它的通訊鎖，逼他們在玩家的壓力之下把通訊鎖的服務暫時關掉，不必驗證就能登入，如此一來就造成了空檔，之前盜來的帳號本來少了手機驗證這關，無法登入，但是有了這個空檔或許就可以好好利用，從這個例子我們可以看到，重要的系統需要有備援的系統，否則當這個系統失效，就產生了安全性上的問題，而且也可能造成提供攻擊的空檔，駭客可以刻意癱渙該系統以取得攻擊的空檔

• 最小化的權限

很常見的問題之一，就是使用過大的權限去執行做一些雞毛蒜皮的事，舉個例子，使用root來執行網頁伺服器，在這種情況下，只要網頁伺服器有什麼漏洞因此被利用了，就等於整台電腦的root被拿走了是一樣的，因此使用過大的權限是危險的行為，盡量將權限限制在能做好該做的任務就好的範圍，如此一來，就算某個帳號被拿下，也難以成大事，必須尋求其它管道

• 不要相信內部系統

即使來到系統內部，也不該相信所有資料不是惡意的，考慮一下如果駭客只拿下最外面的系統，接著要往裡面的系統攻擊，如果裡面的系統天真的以為，來自內部系統的都是安全的，那同樣等於內部的系統也被拿下，因為太相信內部系統而不做檢查的後果，因此就算來到了防線的後方，也不該因此而偷懶不用考慮安全的問題，記得假設你的每個系統都可能被攻擊，就算來自內部的系統也可能是攻擊，你怎麼知道你旁邊的電腦是不是變成殭屍了? 你怎麼知道管理員的介面就不會被殖入XSS因此而不用檢查惡意的html? 因此"不要相信任何人"

現實是…

如果都做到了，攻擊你的系統會是一件非常困難的事，一層防禦還有一層，防禦的種類又是多樣性且不盡相同，都有備援，權限被最小化，即使拿到了也只是個沒什麼用的使用者，而系統內部也不相信其它系統，拿下來外圍的系統想藉此攻擊內部也是很困難，是的，理論上來講非常困難，但是真正值得考慮的應該是到底能夠做到多少? 越多越繁複的防禦表示越高的成本，想像一下你會拿這樣的方式來防禦王小明寫給隔壁阿花的情書嗎? 我想不會，除非那個很重要，但是相對的，如果是核子彈發射的系統，這樣做就很值得，你不會想看到核子武器把玩在script kid的手中吧? 因此深度防禦如果真的要達到有深度確實要花不少成本，但是其實不用很深，我們保護的不是核子彈，就算是客戶的資料，我們一樣可以盡量增加防禦的深度，事實上不用太深的深度，當你的資料沒有那個價值讓駭客去花那麼大的力氣取得時，到那樣的深度其實就已經足夠

對於寫程式而言，很多預設的行為都是相當危險的，舉一些最常見的例子SQL Injection、XSS、Buffer overflow，我們可以從這些幾個最常出現被攻擊的類形，都有一個共同的特點，就是它們通常都是因為預設的行為很危險，我們一個一個來看

SQL Injection

這是最常見的網頁程式攻擊手法之一，例如有一個SQL語法這樣寫

SELECT * FROM Member WHERE id = '$userId'

userId沒有經過任何過濾，那麼這樣的程式等於打開了SQL的大門任惡意的使用者操作，考濾一下如果使用者帳號輸入這樣

‘; SHUTDOWN –

如此一來整句SQL語法就會變成這樣

SELECT * FROM Member WHERE id = ''; SHUTDOWN --'

SELECT的SQL語法後面被加上了一句Shutdown指令，如此一來SQL Server就會被關掉，當然這還稱不上太邪惡，要做任何事情幾乎都可以，只要SQL語法能辦到，很明顯地，危險來自預設的方式去下SQL指令，使用者，也就是程式設計師，如果沒有這方面的知識，那麼使用預設的行為是理所當然的事情，像PHP較後面的版本就有自動取代一些危險的字元，雖然有點麻煩，但至少它是一個方法，讓預設的行為不那麼的危險

XSS

接著是XSS，也就是Cross-site Scripting，這也一樣是危險的預設行為所引起的問題，假設我們有下面的一個簡單PHP程式

echo "Hello ";
echo $userName;

看起來只是一個無傷大雅跟使用者打招呼的程式，考慮一下$userName變數如果沒有經過任何過濾，如果使用者將userName輸入成下面的資料

<script type="text/javascript"><!--mce:0--></script>

這一樣是一個無傷大雅的小惡作劇，輸入這個資料會讓頁面標題被改成你想要的字串，但是把這程式碼改得更邪惡一點就不再是什麼有趣的事，很明顯地，這一樣又是一齣危險的預設行為所造成的悲劇，任何資料輸出都預設直接是完整地顯示出來，沒有經過任何過濾，像name這種顯而易見的欄位可能會被注意到並且記得過濾，那其它欄位呢? 今天我如果是攻擊者，任何可以輸入的欄位都是值得一試的，不是只有text box類形的表單元件才能輸入惡意的資料，因此過濾危險字元，便成了寫PHP網頁程式的重要任務，它是那麼的危險，但是它是預設行為

Buffer overflow

接著我們看Buffer overflow，這就算是比較困難一點的手法，SQL Injection那種只要把那句shutdown指令到處貼，連小孩子都有可能癱渙政府的網站，我相信只要寫一個bot去爬網站，然後輸入那句語法，被爬到的網站還是會有很多會掛掉，政府機構的網站也是外包的，裡面只要有一個菜鳥忘記濾語法(或是老練的工程師忘記過濾)，整個網站就完蛋了，但是Buffer overflow的手法就不一樣了，考慮一下下面的程式碼

void foo(char *userName) {
    char temp[16];
    strcpy(temp, user);
    // do something here....
}

看起來不怎麼樣的函數，但卻潛藏著大大的危險，如果使用者名稱輸入的資料長度超過16字元，在stack中後面的資料就會被蓋掉，惡意經過設計的資料，會將後面的函數返回的位置蓋掉成想要執行的位置，例如資料本身夾帶一段惡意程式，其中函數返迴的位址改成資料夾帶的惡意程式的位址，如此一來就可以利用資料的輸入來使目的程式做想幹的壞事，原因一樣出在，strcpy預設的行為是不檢查字串長度的，但是因為要了解定址、Stack如何運作等底層的一些知識，絕對不是script kids可以輕易辦到的事，當然利用現成的工具就另當別論，但那還是script kids在幹的事

危險當預設行為之於安全當預設行為

PHP的預設行為通常都很危險，這就是我不太喜歡它的原因之一，需要有經驗的程式設計，並且用盡你的力氣想辦法去防堵任何可能的漏洞，你只要忘記一個地方，就等於打開了大門，之前做的辛苦就全白費了，不止是你，還有你得燒香拜拜祈求你的整個團隊裡沒有出任何一個天兵在程式的某個角落裡忘記過濾惡意資料，相較之下我使用Python寫的TurboGears開發了不少網站之後，發現它確確實實落實了"別讓危險成為預設的行為"的概念，所有在PHP見到那堆煩死人的危險預設行為都看不到

首先是SQL Injection，在TurboGears裡用的是SQLObject或是SQLAlchemy/Elixir等ORM的一層，使用者不必寫任何一句SQL語法，因為語法都由這層ORM產生，自然避開了SQL Injection的問題，任何資料透過這層都會被過濾掉，然而SQLAlchemy等ORM的完備性，並不會因此而限制到太多程式的自由

接著是XSS，TurboGears預設使用的是Kid Template，它是一款樣版引擎，任何輸出的HTML都必須是要合法的才能輸出，而且所有資料預設都是被過濾的，要輸出HTML的情況比較少，須要"明確地說出來"

例如下面一個簡單樣板

${userName}

我們在這裡看到的userName預設就是把html過濾掉了，那你可能會說，如果我想輸出html怎麼辦，其實很簡單，像這樣

${XML(userProfile)}

如你所見，Kid template用一個XML函數來明確地指出要輸出html，雖然那些資料也一樣須要自己過濾，但是想想看，80%以上的資料都只是資料只有20%以下的資料是html需要這樣輸出，而樣版引擎也處理了語法迴圈輸出等等的問題，你寶貴的開發時間不該浪費在過濾那些該死的惡意語法上不是嗎?

至於Buffer overflow，Python因為是高階的語言，天生就沒這種問題，除非c語言寫的模組有這樣的問題，又剛好有使用者輸入的資料會跑到那個c語言模組的漏洞

危險的行為應該要被明確地說出來

解決的方法，應該說在設計上，就應該要這麼做，讓危險的行為應該要被明確地說出來，例如echo預設就過濾所有包含在裡面的變數，想輸出html需要明確地指出，像是這樣

echo "User's profile : ";
echo XML($userProfile);

這麼一來，只有少數需要將變數內裝html輸出的資料要用XML函數明確地指出來輸出，除此之外，十之八九的資料都不需要過濾，那麼危險的行為當預設行為，明明那麼少用到，變成過濾的工作一直都浪費在這些少數的情況上，這就是PHP很大的敗筆之一

接著是SQL Injection，一樣讓危險的事情需要明確的講出來，又或著用一層ORM之類的避免直接的SQL語法產生和字串合成

接著是Buffer overflow，最大的兇手就是strcpy這個函數，最初就不應該讓這樣的函數設計，造成無數的漏洞，不過當初又有誰會想到有這樣的漏洞，strcpy因為沒檢查邊界所以很危險，預設應該讓它檢查邊界，又或著是，乾脆不要有這樣的函數存在，當然它的存在有一定的方便性，而且檢查邊界又考濾到效能的問題，所以最好的辦法，還是一樣讓危險的行為被明確地指出來，像這樣假設在C++之下，預設是檢查邊界的行為

strcpy(temp, username);

然而要不檢查邊界的寫法可能像這樣

strcpy(temp, username, NOCHECK);

以某種程度來說，讓危險的行為麻煩一點總是比較好的，人們都會選擇比較輕鬆的寫法，而比較麻煩的寫法，除非有特別的需要，才會特別明確地指出，甚至不希望使用者去用的話，還可以故意讓危險的行為越麻煩越好

最後

切記別讓危險的行為成為預設值，特別是那些佔少數特例、又是極度危險的行為，實在沒有理由讓它們程為預設或是最常用的方法，反而要特別來過濾

別讓危險成為預設的行為，讓危險的行為比安全的行為更麻煩

——

修改 : 原本strcpy誤植為strlen 奇怪= = 我怎麼會寫成strlen..