有 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在加密方法的路线图

　　以上皆为平常开发总结，也借鉴网上大神的文章，略略整理一二，权做学习使用，固然面试能帮到不慎感动了，之后有机会再作梳理。

　　欢迎指点。