我個人對黑客和網絡安全比較感興趣，時常關注這方面的新聞。我們知道這些安全問題都是軟件程序有Bug導致的，例如CSDN的數據庫泄露事件、攜程泄露用戶銀行卡信息事件、電商網站被用戶篡改購買支付金額等等。
在軟件項目開發時，安全一直是一個比較容易忽略的問題，但這也會導致很嚴重的損失，所以我們在軟件開發時必要對安全問題引起重視，防患未然，構建安全軟件。
我們今天一起討論一下軟件開發中的安全問題。
安全問題本質是技術風險
安全問題本質上是一種技術風險，沒發生問題的時候大家一切平安，一旦發生問題就會有嚴重的影響。所以對待安全問題，我們可以借鑑對風險管理的方法來改進軟件的安全問題，也就是風險識別、風險量化、應對計劃和風險監控。
我們做風險管理的時候，首重之重就是識別風險和對風險的量化，對於安全問題，我們要思考一下，軟件項目中安全問題的主要來源是什麼？
- 第一類：惡意輸入
大多我們熟知的軟件安全問題都屬於此類型，就是黑客通過惡意輸入，然後繞過軟件限制對系統進行攻擊和破壞
像SQL注入，就是黑客把SQL命令輸入到軟件的輸入框或網頁的URL查詢參數，欺騙服務器，執行惡意的SQL命令，這種可以繞過密碼驗證，登錄管理員賬號，或者刪除數據庫數據，甚至控制服務器，當成肉雞對網絡發起泛洪攻擊。
還有像XSS攻擊，將惡意代碼通過外部參數或者用戶輸入的方式植入網頁中，獲取用戶的Cookie等敏感信息、盜用管理員權限，甚至非法轉賬。
上面的問題都可以歸結爲惡意輸入導致的，應對惡意輸入的問題，最簡單有效的方式就是對用戶輸入數據進行嚴格的檢查校驗和格式化。
- 第二類：假冒身份
很多程序對於用戶身份檢驗比較弱，會導致黑客假冒用戶身份做出超越權限的事情。
比如有的網站把後臺入口隱藏起來，不做權限控制，導致黑客猜到地址後就可以進入後臺操作。
還有的遊戲後臺不做驗證，直接接收傳入的數據，導致僞造遊戲用戶發送數據破壞遊戲公平。
這類問題應對策略就是對用戶的身份做驗證，尤其是涉及敏感權限的操作，甚而做兩重驗證。
- 第三類：數據泄露
很多軟件數據庫都存儲了用戶的敏感信息，比如用戶賬號密碼信用卡信息或者服務器的敏感信息，比如數據庫連接字符串、登錄賬號密碼，這些數據是有被泄露風險的。
一些軟件甚至會把服務器上的敏感信息打包到程序中，要知道程序會被反編譯從而導致敏感數據泄露，攜程泄露用戶銀行卡信息事件就是因爲把用戶信用卡信息記錄在日誌中，日誌泄露導致用戶信用卡也被泄露，造成盜刷等等嚴重問題。
還有CSDN，對用戶密碼銘文存儲到數據庫中，數據庫泄露之後，用戶密碼也跟着泄露，而且現在大多數用戶都習慣於使用統一的密碼，導致一起泄露。
所以，對於軟件來說，我們不能假設數據存儲是安全的，而是要考慮到數據是有泄漏的可能，提前做好預防措施，對敏感數據加密。
如何預防軟件中的安全問題
在風險管理中，對風險識別和量化後，接下來就是要制定應對計劃了。
很多開發人員覺得安全問題，只要在軟件開發完成後，測試階段做一個安全測試就可以了，但這種做法完全把安全問題留到了最後環節，是很難達到對安全問題進行高質量管控的。爲什麼呢？
一方面對於安全測試來說，很難覆蓋到所有可能存在的場景，會出現疏漏，另一方面，如果測試階段發現安全問題，可能需要修改很多代碼，甚至架構要重新設計，成本代價太高。
很顯然，應對安全問題，最好的方式就是整個生命週期都做到重視安全問題。
需求階段
需求是軟件項目的源頭，在確定需求，做產品設計的時候，不僅要考慮到功能上的需求，同時還要考慮到安全方面的要求，這樣我們在設計架構的時候，不會輕易遺漏安全方面的架構設計。
需求階段，涉及用戶輸入的內容，需要考慮到可能的惡意輸入，做出針對性的預防措施；對於涉及用戶權限的，要求有身份的驗證，甚至一些安全要求極高的，可以在需求商就要求做雙重驗證；對於有敏感數據的，需求商要對數據進行加密。
舉例，用戶登錄功能，安全方面的需求，我們可以考慮到如下功能：
- 登錄網頁使用Https或者在傳輸密碼時加密；
- 增加圖形校驗碼，避免惡意攻擊；
- 密碼失敗次數過多，應該鎖定用戶一段時間；
- 記錄用戶登錄IP；
我們在需求階段就提出了安全性的需求，設計、實現和測試時自然不會遺漏掉安全方面的內容，從源頭上就讓大家有了安全方面的意識。
設計階段
做設計架構時，我們就要把安全加入到設計目標中，有了這個設計目標，我們自然能找到很多安全相關的解決方案。
爲了保障在設計時就考慮好安全方面的問題，我們在做架構設計方案評審時，也需要增加安全方面的評審，確保有安全方面的考慮，確保技術方案切實可行。
在架構設計領域，我們也有了業界公認的好的安全相關的設計原則，比如攻擊面最小化、權限最小化、縱深防禦等。
- 攻擊面最小化
攻擊面指程序被用戶直接訪問到的部分，比如API、網站等，而攻擊面最小化的設計原則，就是儘量減少暴露黑客可能發現並試圖利用的攻擊面數量。舉例來說，你的數據庫應該關閉外網訪問，避免黑客直接攻擊數據庫導致數據泄露，還有對於複雜的多網站業務系統，實行單點認證，就可以讓所有業務都在一個地方登錄，這一個地方做到足夠安全了，那所有的網站的登陸都是相對安全的。
- 權限最小化
權限最小化的設計原則就是對於系統的用戶、文件訪問、進程運行等，給予其能擁有的最小權限，這樣可以保證一個應用程序或者網站被攻擊、破解，將損害講到最低。
以前在部署Asp.Net程序時，運行Asp.Net程序是單獨一個用戶，此用戶擁有的權限只能是運行程序目錄，不能超出其目錄範圍，這樣即使用戶上傳了惡意木馬文件，也只能控制着一個目錄，避免進一步的損失。
- 縱深防禦
縱深防禦的設計原則，指的是從不同的維度去實施安全保護措施，從而緩解被攻擊的風險。縱深防禦的核心是從不同的層面、不同的角度對系統做出整體的解決方案。
我們知道國內中小電商，一半以上早年都在犯過一個錯誤，就是電商的交易和支付系統之間流程是這樣的，我買一臺顯示器1500，把錢交給支付系統，支付請求是從用戶側瀏覽器發出的，用戶不可見，但是攻擊者實際上可以修改這個數據，把瀏覽器提交的數據改爲1，支付系統返回OK，表示收到款項，交易系統看到支付成功了，就跳到安排發貨，用戶就1元買到顯示器了。
從系統的整體角度考慮，顯然不僅要校驗交易有沒有成功，還要校驗交易的金額是否匹配。
開發階段
在編碼規範時我們要多用戶輸入數據進行校驗；涉及權限的操作，要檢查用戶權限；對於敏感數據要進行加密處理；對於用戶的操作，要有日誌記錄；不能在日誌中記錄敏感信息等等。要有代碼審查，及時發現代碼中的安全問題。增加安全相關的自動化測試，和CI集成。
測試階段
測試階段，除了功能測試以外，還要增加對安全性方面的測試，除了增加相應的測試用例，還可以藉助一些安全測試工具。
上線維護
上線部署時，不部署源代碼，只對編譯後程序部署；刪除Debug文件。對服務器進行安全設置，嚴格限制端口，只保留必須的端口；只對少數服務器開放服務；開啓操作日誌；對訪問目錄設置最小的權限；
如果真的出現了安全問題怎麼辦？
安全問題就像程序的Bug一樣，沒有誰能保證絕對的安全，風險管理的最後一步風險監控說的有道理，我們必須做好Plan B，出現問題馬上應對，將損失降到最低。
首先，設立應急的流程，出現安全問題了，根據流程，找到第一責任人，立即解決問題回覆生產，避免進一步損失。
其次，要分析程序的漏洞，通過分析日誌，找出漏洞
最後，總結原因，從錯誤中吸取教訓，看問題是在哪個環節導致的，必要的話，改進開發流程，避免類似的安全問題再次發生。