2016-09-06 13:25:17
来源：京东应急响应中心 作者：安全客
阅读：1060次
点赞(0)
收藏
一：白盒代码审计初期遇到的问题
在漏洞扫描领域，可以大致分为黑盒扫描和白盒扫描两种主流方式，黑盒扫描工具主要是通过发送模拟攻击数据包给线上业务，通过返回数据包中的特征发现漏洞；白盒扫描则是通过扫描程序源代码中的漏洞代码特征，进行针对性的漏洞查找。黑盒扫描技术门槛、成本都较低，适合大批量发现安全漏洞，因此目前几乎所有公司的安全团队都采取自研或者使用商业工具建立了黑盒扫描平台。但是随着时间推移大量明显漏洞被黑盒扫描方式发现并修复，可以直接通过黑盒扫描工具发现的漏洞逐渐减少，而越来越多的安全漏洞隐藏较深难以发现，这些漏洞也成了攻击者重点利用的对象。相对于黑盒扫描，白盒代码扫描可以从代码层面准确发现隐藏较深的安全漏洞，但是白盒代码扫描相对来说技术门槛和成本都比较高，所以目前大部分公司没有能够很好的建立起白盒代码审计平台，京东安全团队为了推进白盒代码审计建设，使用了一款商业代码扫描引擎，在前期的使用中，也遇到了很多困难，主要有如下四方面。1.1源代码分布较为分散
京东最初的源代码基本上都使用SVN进行管理，且上百个研发团队分管自己的SVN，导致源代码分布较为分散，这就为白盒代码审计获取代码带来了困难。为了推动代码审计项目进程，审计团队不得不分别与各个研发团队进行联系来获取相关的上线项目源码，严重影响了代码审计的工作效率。
1.2代码库地址与域名及研发负责人不能对应
在开发白盒代码审计系统之前，由于代码库地址、域名及研发负责人的ERP没有被对应起来，导致审计过程中还需人工去对应代码库与域名。发现漏洞后还要去找到对应的域名进行漏洞验证，并且还需要寻找相应的研发负责人去沟通交流，在这一过程中浪费了大量的时间及精力，严重影响了代码审计的工作效率。
1.3扫描引擎默认扫描规则检测效果不理想
将采购的扫描引擎应用于京东白盒代码审计之初，我们发现其默认的扫描规则对于京东代码的检测效果并不理想。鉴于京东具备一套符合其业务发展的研发架构，代码审计团队需在此基础上研究适应该架构的扫描规则以提高检测效果。
1.4扫描引擎默认界面只能手工提交扫描任务
扫描引擎默认接口只支持手动提交扫描任务，且每次只能提交一个扫描任务，针对京东成百上千个代码库，难以批量扫描，效率低下。
二：京东白盒代码审计系统第一期设计思路
针对以上的四点主要问题，我们通过几个月时间的协调和设计，规划并且研发出了京东白盒代码审计一期平台，能够比较好的解决上面四点问题。
2.1白盒代码审计系统整体架构介绍
白盒代码审计项目一期，主要实现从京东上线平台同步数据，主要包括系统域名、代码库、研发人员，并提交扫描任务至扫描引擎进行扫描。扫描引擎使用安全团队针对京东项目源代码特点定制的扫描策略，最终形成报告供审计人员验证漏洞。
（如图所示为系统的整体架构图）
（1）与京东上线平台对接
当京东上线平台中有项目上线时，都会将系统域名、代码库地址、研发负责人等信息自动录入白盒代码审计系统的数据库中，为后期的代码扫描提供自动化的数据来源，有了系统域名、代码库地址、负责人信息的汇聚，就解决了之前提到的源代码分散以及发现漏洞难以验证的问题。下图为系统中汇聚到的域名、代码库、负责人等信息。
（2）扫描引擎调度
白盒代码审计系统通过调用扫描引擎开放的web services接口实现了对扫描引擎的调度。当白盒代码审计系统发现有新项目提交进来之后会自动提交扫描任务给扫描引擎进行扫描。这样就省去了人工提交扫描项目的繁琐操作，审计人员可以把主要精力全部都放在分析扫描报告、验证安全漏洞上。
（3）扫描引擎使用定制化规则进行代码扫描
扫描引擎在接收到白盒代码审计系统提交的上线项目的代码库地址等信息后，会根据代码库信息clone相应源码，再根据京东安全团队配置的符合京东项目特性的扫描规则，进行相应的漏洞扫描，并生成最终的漏洞扫描报告以供后期的漏洞验证。
三：截止到目前白盒代码审计总体成果介绍
经过2个月左右时间的实际运行扫描测试，共扫描代码库65个，发现多个安全漏洞。（如图所示为风险等级分布图和漏洞类型分布图）
四：主要扫描规则设计思路介绍
1.文件上传漏洞
（1）设计背景
文件上传操作是web程序中的常见操作，但是如果没有对上传文件操作做相应的安全处理，很容易被攻击者利用上传脚本木马，获取服务器权限。例如，上传图片到web目录中，如果没有限制上传文件的扩展名，攻击者可以上传一个脚本木马到web路径，从而直接获取服务器权限，并且可以进行进一步的攻击。
（2）设计原理
京东线上业务有很多文件上传操作，这些操作有很大一部分使用了Spring MVC框架提供的文件上传功能，根据Spring文档，可以知道，Spring MVC默认支持两种文件上传操作方式。一种是使用MultipartHttpServletRequest或者MultipartFile作为方法参数，第二种是使用javax.servlet.http.Part作为方法参数，如下图所示。
根据这个特点，我们可以编写代码扫描规则，发现代码中的文件上传操作，然后就可以进一步判断是否存在文件上传漏洞。
2.SQL注入漏洞
（1）设计背景
通过总结发现京东业务中数据库交互层面大部分使用mybatis框架，mybatis框架中#{变量}对应JDBC中的预编译机制，不存在SQL注入漏洞，${变量}对应SQL语句拼接方式，存在SQL注入风险。
（2）设计原理
若与数据库交互的位置存在动态拼接，即用户输入的参数可控，在这种情况下，很容易遭到黑客恶意利用而进行SQL注入攻击。针对SQL注入，设置匹配规则在mybatis的sql语句层面扫描文件中的“$”符号，再使用扫描引擎提供的数据流分析机制层层跟进数据到web层面。
3.通用组件漏洞
（1）设计背景
一个项目中除了研发人员自己编写的代码中可能存在安全漏洞，使用的第三方组件中同样可能包含安全漏洞，如Struts2远程代码执行漏洞，这类漏洞的特点是使用了存在漏洞的组件，就有产生安全漏洞的风险。
（2）扫描规则设计原理
目前由于京东的项目构建主要依靠maven系统，项目的pom.xml文件中记录了项目所依赖的各种第三方组件信息，很适合白盒代码扫描，所以在这里设计了相应的规则扫描pom.xml文件中的组件坐标信息。
更多精彩内容欢迎关注“京东应急响应中心”
本文转载自 京东应急响应中心原文链接：