PIN

續上篇：http://www.dotblogs.com.tw/pin0513/archive/2011/01/11/20734.aspx

 

Backward Compatibility Will Always Give You Grief(向前相容性永遠會帶給你麻煩)

開發出新的功能以後，我們不易將所有的電腦馬上進行升級

但為了相容於舊的版本(可能使用者的數量極大)

有時會為舊版本的規格進行妥協

例如自動恢復舊的版本或是開放舊的版本的相容

但這樣也會造成了舊版的安全性問題仍在

因此為了安全性的理由對重要功能作出變更時

隨時要準備面對升級以及向前相容性方面的問題。

 

Assume External Systems Are Insecure(假設外部系統是不安全的)

這一點和 使用深度防禦相近，所以這個假設也是防禦之一。

將任何來源的資料都視為攻擊的一方，外部的伺服器也是。

客戶端可以用任何方式來導向錯誤的Server上。

因此撰寫客戶端程式的時候，不要假設會跟行為正常的伺服器打交道。

使用者介面也是，即使是正常的使用者介面

也可能是惡意資料的輸入

 

Plan on Failure(為錯誤進行計畫)

錯誤應變計畫一定要準備，即使我們很希望是備而不用

例如，當網站資料被偷改的時候怎麼辦？網站被入侵的時候該怎麼做。

假如有這類型的計畫，將可以降低這類的損失成本，且快速反應事件。

 

Fail to a Secure Mode(當錯誤時進入安全模式)

當系統錯誤的時候，不要透露大量有關錯誤發生原因的資訊，並將詳細內容記錄到Log中

另一個就是，我們應該判斷使用者的輸入(或透過Regular Rexpression來擋掉使用者惡意或不正常的輸入)

以及我們也驗證程式流程必須是正確的以後，才進行下一步

只要有一個問題發生錯誤，就馬上回絕請求！這樣也算是這個模式的應用。

 

Remember That Security Features ! = Secure Features(安全性功能不等於安全的功能)

這些功能通常是由具有資安意識的人所撰寫，因此撰寫這些安全性程式碼的人往往都會針對

特定的安全性議題進行防護，但應用程式的核心呢？我們要如何正確地提供正確的功能呢？

建立威脅模型是本書之建議。

 

Never Depend on Security Through Obscurity Alone(不要倚賴安全性的功能去對付所有不明的狀況)

我們必須假設入侵者瞭解所有自己知道的事情，並假設入侵者看過所有的程式原始碼以及相關設計。

對入侵者來說，要瞭解他們所不清楚的資訊是相當簡單的。

不清楚本身可以算是一項不錯的策略，但也不能是唯一的防線。

隱藏細節也算是深度防禦的一部分。

 

Don’t Mix Code and Data(別把資料和程式混在一起)

巨集病毒的歷史教訓就告訴我們這個事情，除此之外，對網頁安全議題而言，XSS瑕疵會存在

也是因為HTML資料與Java Script語法被混在一起。雖然資料與程式結合讓功能更強大

但也增加了安全性的弱點。

 

Fix Security Issues Correctly(正確的修正安全性議題)

如果找到了程式碼的Bug或是設計上的問題時，請在應用程式的其他部分裡修正他。

他們有可疵能在很多相似的地方出現。若有安全上的瑕存在的話，請修正根本的問題

因為隨時間不斷變大的修補程式，常常會導致迴歸錯誤，而產生更大的問題。

 

總結：

作者也建議，這些原則沒有一個是難以實踐的，但回報都很豐富

盡力將這些概念用到我們平日的開發情境中實作

若要從這些原則選擇一個開始的話，本書建議：

1.用預設的方式套用安全性(順便導入深度防禦及使用最小權限)

2.自錯誤中學習教訓(發生錯誤並不可恥，我們都會犯下錯誤，但不要一而再的犯下相同的錯誤。)

 

參考資源：

Writing Secure Code  Second Edition

Michael Howard, David C. LeBlanc