有 a - b < c 引发的安全性思考

Posted 2021-01-11 fuguoliang

　　软件工程中，不论使用哪种开发语言，安全性一直是一个非常棘手却又重要的问题。安全性是软件开发领域永远的主题之一，而且随着互联网的蜂拥发展而带动的新技术的兴起与革命（比如近几年火起来的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在加密方法的路线图

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

　　欢迎指点。