有 a - b < c 對Java安全性的思考

　　軟件工程中，不論使用哪一種開發語言，安全性一直是一個很是棘手卻又重要的問題。安全性是軟件開發領域永遠的主題之一，並且隨着互聯網的蜂擁發展而帶動的新技術的興起與革命（好比近幾年火起來的node.js，python，go等，甚至微軟也開源後的.net Core），軟件工程中的安全性更加的凸顯與重要了。

　　那麼，什麼纔是危險的呢？個人第一反應是注入攻擊，好比SQL注入攻擊。一個典型的場景是WEB應用中，用戶登錄功能，根據用戶輸入的用戶名密碼獲取相應的數據，那麼SQL注入就應運而生，模擬用戶名，密碼加入特殊字符，加入惡意腳本等等手段，進而形成不了可挽回的後果。好比，正常腳本當如：

select * from userInfo where username='input_Name' and password='input_Pwd or'

　那麼，若是是這樣的呢？

select * from userInfo where username='input_Name' and password='input_Pwdte' or 1=1 or ''

 

　　關於如何編寫安全的Java代碼，Sun官方給了一份指南，有興趣的同窗能夠參考這篇文章，大體爲：

　　　　• 靜態字段
　　　　• 縮小做用域
　　　　• 公共方法和字段
　　　　• 保護包
　　　　• equals方法
　　　　• 若是可能使對象不可改變
　　　　• 不要返回指向包含敏感數據的內部數組的引用
　　　　• 不要直接存儲用戶提供的數組
　　　　• 序列化
　　　　• 原生函數
　　　　• 清除敏感信息

　　好比，DoS是一種常見的網絡攻擊，有人戲稱爲「洪水攻擊」。其慣用手法是經過某種手段，好比大量的機器發送請求，將目標網站寬帶和其資源耗盡，致使用戶沒法正常訪問，甚至服務器的宕機。

　　而對於此類問題，若是單從服務器級別考慮，多少欠缺，咱們或許須要考慮程序級別的攻擊，好比Java，JVM，以及涉及到的線程方面的安全，應用程序的瑕疵等進行低成本的DoS攻擊。

　　而在面試中，咱們都會被問到安全性的問題，卻大多比較多泛泛，大而廣，而大多數的安全性問題都與代碼安全性有關。咱們回顧下Java代碼的運行過程：

　　首先編譯器把.java文件編程成.class字節碼文件，而後由類加載器負責把.class文件加載到JVM，再由字節碼校驗進行校驗，而後由Java解釋器負責把該類文件解釋爲機器碼執行。

　　在類加載器加載.class文件到java虛擬機的過程當中，類加載器經過區分本機文件系統的類和網絡系統導入的類增長安全性（不容許網絡上的應用程序修改本地的數據），本機的類先被加載，一旦全部的類加載完，執行文件的內存劃分就固定了，而後字節碼校驗器開始校驗.class字節碼文件，字節碼校驗器不檢查那些可信任的編譯器所產生的類文件。經過以後，java解釋器材負責把類文件解釋成爲機器碼進行執行。

//  a b c 都是int類型的數值
	if (a - b < c) { 
            // … 
    }
    

　　這段看似簡單，沒毛病的代碼會引起下列問題：

　　若是b<0，而形成的數據溢出，你能想象出多少問題？！而對於越界的處理雖然Java底層給出了很好的解決，可是數值而形成內存問題不容小覷。

　　固然，過多的考慮安全性問題，勢必會形成應用程序的冗餘甚至疲軟，這些須要視狀況而定，而不可蓋棺而論。

　　再好比，對於一段可能出現問題的代碼，經常使用手段 try … catch(){… },那麼問題來了，catch的是什麼？而通常狀況下，咱們程序須要抓取到catch，由於要作日誌處理，那麼日誌中不可或缺的有相似代碼位置，方法名，以及錯誤緣由等，甚至包含了敏感信息。固然，不可避免，個人建議是，儘可能使用內部標識的異常信息，而返回給客戶端的相似異常消息儘可能少的自動返回的異常消息。

　　對於安全標準特別高的系統，甚至可能要求敏感信息被使用後，要當即明確再內存中銷燬，以避免被探測到；或者避免在發生core dump時，意外暴露。

 

　　開發和測試階段

　　　1. 儘可能的規範化代碼，可參考《阿里巴巴開發手冊》

　　　2. 儘可能多的code review，避免沒必要要尷尬代碼出現

　　　3. 在代碼check-in等環節，利用hook機制去調用規則檢查工具，保證不合規範代碼進入OpenJDK代碼庫

　　部署階段

   　　可參考JDK在加密方法的路線圖

　　以上皆爲平常開發總結，也借鑑網上大神的文章，略略整理一二，權做學習使用，固然面試能幫到不慎感動了，之後有機會再作梳理。

　　歡迎指點。