Java代碼規範及安全漏洞防範及性能調優

一、Null Dereference

　　對於對象若是可能爲null時，下邊使用他必定要檢查是否爲null，不然就可能存在 NullPointException 風險。

　　例如：在邏輯判斷內部或者try-catch內實例化時，在外部使用此對象時就必定要檢查。

二、Password Management: Hardcoded Password

　　代碼裏不能出現String pwd = 「123456」等硬代碼。

三、系統資源未釋放風險

　　數據庫鏈接、輸入輸出流必須在finally或者可靠的地方進行手動關閉。

四、finally塊裏不能return

　　從 finally 塊中返回會致使異常的丟失，正常應該在catch中返回異常的信息。

五、xml解析時，禁制外部實體解析

　　若是實際狀況中不會出現外部實體的話，能夠直接禁制外部實體解析，這樣基本就作到了防範。詳細介紹

 public <T> T fromXml(String xml) {  
        StringReader stringReader = null;
        try {                          
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
            dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
            stringReader = new StringReader(xml);
            InputSource inputSource = new InputSource(stringReader);
            DocumentBuilder db = dbf.newDocumentBuilder();
            Document document = db.parse(inputSource);
            return (T) createUnmarshaller().unmarshal(document);
        } catch (Exception e) {  
            e.printStackTrace();
            return null;
        }  finally {
            if(stringReader!=null){
                stringReader.close();                
            }
        }
    }  

六、Password Management: Password in Configuration File

　　數據庫密碼不能明文存儲在配置裏。簡單作法就是存儲密文，項目啓動時用解密類解析數據庫密碼。

　　我當時的項目使用到了proxool鏈接池和bonecp兩種鏈接池，作法以下：

　　①使用proxool時

　　對於java項目來講，代碼裏看不到proxool的內部實現，沒法在原來基礎獲取和修改用戶名密碼，只能修改proxool.jar包源碼，寫入一個接口，本身寫接口的實現類來實現。

　　　　proxool配置文件中用戶名和密碼使用加密後的密文（安全測評）

　　對於web項目來講，能夠在web.xml裏配置或者使用了spring的話，在配置文件裏配置本身寫的DataSource解析xml，解析時把數據庫的用戶名和密碼解密。詳細操做方法點擊這裏

·　  ②使用bonecp鏈接池

　　在讀取配置時能夠經過Config.get和set的方法修改戶名密碼。

七、經常使用對稱加密算法 AES 的推薦使用方法 

　　java學習-AES加解密之AES-128-CBC算法

八、常見非對稱加密RAS的推薦使用方法 RSA介紹

　　使用 RSA 公鑰的加密一般與某種填充模式結合使用。該填充模式的目的在於防止一些針對 RSA 的攻擊，這些攻擊僅在執行不帶填充模式的加密時才起做用。

　　爲安全使用 RSA，在執行加密時必須使用 OAEP（最優非對稱加密填充模式）。

九、XML Entity Expansion Injection

　　使用配置的 XML 解析器沒法預防和限制文檔類型定義 (DTD) 實體解析，這會使解析器暴露在 XML Entity Expansion injection 之下。
　　XML Entity Expansion injection 也稱爲 XML Bombs，屬於 DoS 攻擊，利用格式工整的有效 XML 塊，它們在耗盡服務器分配的資源以前不斷呈指數式擴張。XML 容許定義做爲字符串替代宏的自定義實體。經過嵌套復
發性實體解析，攻擊者能夠輕鬆使服務器資源崩潰。
　　下面的 XML 文檔介紹了 XML Bomb 的示例。

<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]><lolz>&lol9;</lolz>

　　此測試能夠在內存中將小型 XML 文檔擴展到超過 3GB 而使服務器崩潰。
　　應該對 XML 解析器進行安全配置，使它不容許將文檔類型定義 (DTD) 自定義實體包含在傳入的 XML 文檔中。
　　爲了不 XML Entity Expansion injection，應爲 XML 代理、解析器或讀取器設置「secure-processing」屬性：
　　factory.setFeature("http://javax.xml.XMLConstants/feature/secure-processing",true);
　　在 JAXP 1.3 及更早版本中，當開啓安全處理功能時，將爲 DOM 和 SAX 解析器設置默認限制。這些限制是：
　　　　entityExpansionLimit = 64,000
　　　　elementAttributeLimit = 10,000
　　從 JAXP 1.4 開始，將默認打開安全處理功能。除了上述限制外，還在驗證解析器中添加了新的 maxOccur 限制。此限制是：
　　　　maxOccur = 5,000
　　若是不須要 inline DOCTYPE 聲明，可以使用如下屬性將其徹底禁用：

　　　　factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true);（與5同樣）

十、java多線程及數據庫鏈接數

　　各個項目間的多線程數量應相互匹配，好比 A -> B -> C  ，A和B訪問同一個數據庫，A線程池最大500，請求一次A就請求一次B，B也應設500，數據庫應設置1000。相似這樣的邏輯，須要考慮一下，好比A對外開的鏈接數很高，B開的少了，A訪問B就會堵塞。

　　Java 線程狀態之 BLOCKED 簡介     java線程阻塞問題排查方法     

　　項目寫日誌，寫日誌要操做I/O，方法通常都是同步方法，因此日誌會影響系統性能。

　　在高併發的狀況下小小的日誌打印會嚴重影響到性能    

　　大數據量高併發訪問的數據庫優化方法(一)

　　MySQL鏈接數超過限制的解決方法

十一、----