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、----

原文地址:https://www.cnblogs.com/xinzhisoft/p/10241790.html