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


1、Null Dereference

  對於對象如果可能為null時,下邊使用他一定要檢查是否為null,否則就可能存在 NullPointException 風險。

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

2、Password Management: Hardcoded Password

  代碼里不能出現String pwd = “123456”等硬代碼。

3、系統資源未釋放風險

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

4、finally塊里不能return

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

5、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();                
            }
        }
    }  

6、Password Management: Password in Configuration File

  數據庫密碼不能明文存儲在配置里。簡單做法就是存儲密文,項目啟動時用解密類解析數據庫密碼。

  我當時的項目使用到了proxool連接池和bonecp兩種連接池,做法如下:

  ①使用proxool時

  對於java項目來說,代碼里看不到proxool的內部實現,無法在原來基礎獲取和修改用戶名密碼,只能修改proxool.jar包源碼,寫入一個接口,自己寫接口的實現類來實現。

    proxool配置文件中用戶名和密碼使用加密后的密文(安全測評)

  對於web項目來說,可以在web.xml里配置或者使用了spring的話,在配置文件里配置自己寫的DataSource解析xml,解析時把數據庫的用戶名和密碼解密。詳細操作方法點擊這里

·   ②使用bonecp連接池

  在讀取配置時可以通過Config.get和set的方法修改戶名密碼。

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

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

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

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

  為安全使用 RSA,在執行加密時必須使用 OAEP(最優非對稱加密填充模式)。

9、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一樣)

10、java多線程及數據庫連接數

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

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

  項目寫日志,寫日志要操作I/O,方法一般都是同步方法,所以日志會影響系統性能。

  在高並發的情況下小小的日志打印會嚴重影響到性能    

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

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

11、----


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM