为什么80%的码农都做不了架构师？>>> 
1.限制敏感数据的生命周期
对存储敏感信息的数据用后没有清除
---解决方案: 对敏感信息使用过后, 要主动进行清除. 尽量不用String这样的不可变数据存储.
敏感信息被交换到磁盘存储
---解决方案: 选用安全操作系统
通过日志, 调试信息等暴露敏感信息
----解决方案: 对相关信息进行检查
通过缓存(bufferedReader)读取敏感数据后, 没有清除缓存
----解决方案: 改用Channel, 并主动调用clear()方法清空缓存
2.不要在客户端存储未经加密的敏感数据
----解决方案: 在客户端存储的数据进加密, 并用有效时间控制风险
3.为敏感可变类提供不可修改的包装器
内部可变的敏感数据在对外返回时, 可能受到恶意修改
----解决方案: 通过创建子类, 并重写敏感数据方法, 将数据复制后返回,
4.确保安全敏感方法被调用时参数经过验证
5.防止任意文件上传
----解决方案: 通过Apache Tika 对文件元数据进行解析和验证
6. 正确的编码或转义输出
----解决方案: 对于危险的字符, 如HTML里的<>, 即使输入相关可信, 也要再对输出信息进行检查和转义
7.防止代码注入
----解决方案: 在使用Javascript这样的脚本引擎时, 要对输出的代码进行白名单无害化处理.
8.不要依赖可以被不可信代码覆盖的方法
----解决方案: 当调用一个不可信对象的clone()方法进行主动防御式编程时, 可能启用了恶意代码, 对此应使用手动复制的方法; 如果对于一个复合对象, 不能确定其equals方法重写是否可信, 可以用逐个属性比对的方式处理. 对于自定义的敏感类, 可用final修饰, 保证其不会被恶意重写.
9.不要使用不安全的弱加密算法
----解决方案: 如MD5, DES, 3DES, SHA-1等不安全的加密算法, 不要在生产环境中使用
10.使用散列算法存储密码等单向敏感信息
----解决方案: 将密码等信息用SHA-256 等算法散列后进行存储, 既能提高很高的安全性, 又保持密码的单向验证功能.
11.确保SecureRandom正确地选择随机种子
----解决方案: SecureRandom类的默认构造方法是选择了一个内部很强随机性的种子, 如果你不能保证自己提供的随机种子的随机性, 请用默认构造方法.
12.不要授予过多的特权
----解决方案: 在用AccessController的doPrivileged()方法进行授权时, 应传递第二个参数进行权限的限制.
13.最小化特权代码
----解决方案: 确保特权代码段只包含需求增加特权的操作.
14.不要将使用降低安全性检查的方案暴露给不可信代码
JVM支持类加载器通过动态加载额外的类来在运行时扩展, 类加载器架构通过使用不同的类加载器来控制来自不同来源的代码之间的交互. 如果攻击类的类加载器可以将不可信类的加载委托给可信类的类加载器, 将发生特权升级.
----解决方案: 不要对外开放据有类加载能力的可信代码. 防止被攻击利用.