PIN

最近去微軟上Azure的WorkShop，他們說書架上的書想拿都可以拿走

所以我就拿了一本叫作[Writing Secure Code Second Edtion]的書籍

 

裡面分享了如何撰寫安全的程式的技術、經驗以及招式

作者開頭就強調：安全的程式就是有品質的程式

所謂安全不只是網路上被別人破解入侵的事件而己

反而可能因為自己的程式漏洞，有機會給別人見縫插針。

不論是除錯訊息的公開、SQL的安全性防護、硬體資源的配置問題

或是撰寫Web程式的一些問題都有進一步的分享

 

這邊摘錄一下他這本書第三章所分享的安全守則(因篇幅太多，分成兩部分)

這也是希望從觀念上，平常就要建立的一些"常識"，來養成一個好的習慣。

除此之外，可以讓自己進一步設計程式的時候，可以考量到安全性觀點。

必竟，以安全原則設計的程式，比起事後加入安全性修補的程式來的強壯多了！

 

 

Learn from mistakes(從錯誤中記取教訓)

從錯誤經驗學習是最快也最深刻的學習方法，時常反省自己的人會更瞭解自已，不易再犯錯。

因此假如發現程式中有安全性問題或是競爭者的產品有自己程式沒有的功能。

問自己以下的問題：

1.為什麼這個安全性錯誤會發生？

2.我的程式的其他地方會有相同的錯誤嗎？

3.我應該如何防範他再發生呢？

4.我們如何確認，這個錯誤不會再發生呢？

5.我們需要新增這樣的資料到教育訓練或是分析工具中嗎？

 

Minimize your attack surface(最小化自己受攻擊的範圍)
一個產品可能會有許多的漏洞，特別是那些開放的協定或是服務接口

因此我們至少要盤點環境具備”開放”性質的項目，持續保持追縱：

1.Open Socket的數量(TCP and UDP)

2.Named Pipe的數量

3.開放RPC端點的數量

4.服務的數量

5.預設開啟的服務數量

6.ISAPI過濾的檔案數以及應用程式(IIS)

7.動態展示資料的Web網頁的數量

8.管理者帳戶的數量

9.ACLs(檔案與目錄的存取權限清單)

Do Whatever it takes to reduce your attack surface(只要任何可以降低被攻擊面的事情都要去做)

 

Employ secure defaults(套用安全的預設功能)

延續上一個觀點，這個觀點說明我們在幫使用者安裝程式的時候，提供預設的選項。

預設的選項中應該僅具備"必要"的功能就好，也就是盡可能的縮小自己的攻擊面。

安裝的功能愈多，代表受攻擊面也愈高。

有一個法則叫Pareto Principle，也就是80-20法則。

僅安裝那百分之20的功能(預設)，其他則預設為關閉，並提供簡單的開啟方法以及指引

讓使用者可以開啟那些功能。

 

這邊作者遇到一個故事，他說他在進行安全性的程式Review的時候

發現有些功能會有安全性的風險，結果產品團隊因為時程上的壓力僅能日後提供補丁來修改

但是作者建議先將該功能預設關掉，並提供文件可以教導使用者輕易的開啟。

結果產品團隊的經理非常不高興的說，你知道使用者除非必要，都不讀產品文件的

這樣使用者可能永遠也不會知道我們有這個很酷的功能

作者回說：完全沒錯，那既然你知道使用者都不會讀產品文件，那他們怎麼可能去把這個功能關掉呢？

最後該功能還是被拿掉了。

Use defense in depth(深度防禦)

這是一個原則，思考當自己的應用程式已經沒有任何的保護機制

而身陷一個隨時可能被消滅的一個環境下，我必須自己保護自己！

想象銀行即使進入了金庫，最後還是有保險箱的機制來保護

因此我們必須假設錯誤一定會發生，而造成安全性的問題。

永遠永遠要有所"準備"，來防護應用程式可能被攻擊。

 

Use least privilege(僅開放最小的權限)

僅付予應用程式可以讓它來完成它工作的最小權限，其他免談。

就像我們通常不會開放sa的角色給所有存取資料庫的服務來使用。

這樣風險太大，只要取得權限，它隨時可以Drop任何資料庫。

因此在撰寫程式之前，可以列出自己程式會存取什麼資源以及任務要達成。

註：別輕易的開啟Admin的帳戶，若應用程式無法執行，就去找出原因。

 

其他待續