代码审计小结一

以OWASP10个高危漏洞为对象进行审计，审计方法为人工检查为主，工具验证为辅。

PS:因为手头没有具备license的代码审计工具，所以网上找了一个fortify，license至2008年。

形成了一个简单的手工检查列表，方便审计人员检查和提防御建议：
按照10个漏洞的顺序，

SQL注入：
特征：1）明显的sql‘拼接’，

2）或入库参数进行了过滤，但是过滤不完全（过滤的规则目前未完全掌握，难以判断过滤函数中的逻辑是否完全）
防护手段：使用预编译语句
审计位置：网站程序和数据库交互的位置，如向数据库操作传递的变量、过滤函数处
实例：使用fortify对Jforum 2.1.9进行了检查，因为jforum采用的都是预编译语句的方式,工具报了很多sql注入都是误报

跨站脚本攻击：
特征：网页前端未对输入内容进行限制，可以输入js、html等语句；网页前端显示时没有对数据库中的内容进行转义就直接显示
防御手段：对输出的数据进行过滤或者转义；或者输入的时候进行过滤
审计位置：前端页面的数据输出点，数据输入点
实例：以jforum2.1.9为例，用户注册时会对用户名进行过滤，只过滤了<和>，代码如下（过滤是否完全，是否可以绕过，没把握）：

 if (!error && username.indexOf('<')> -1 || username.indexOf('>')> -1) {

jforum 2.1.9对跨站脚本攻击的防护逻辑，简单总结如下： 1.对输入的内容使用过滤语句进行过滤；（部分字段漏掉，如e-mail字段未执行该逻辑，发帖时的poll字段未执行该逻辑） 2.过滤完的数据在存储到数据库之前，进行了html转义；（部分字段漏掉，如投票字段未编码） 3.在显示给用户前，对输出的内容进行html转义；（程序逻辑不完善：如果是游客浏览，则不进行编码，直接输出；如果是注册用户，则进行编码） 欠缺：由于前期接触较少，本次未审计反射型跨站；另外对DOM跨站也不了解，所以也未考虑进入，xss规则待补充

CSRF： 特征：对于重要业务操作的url只有单纯的参数传递，未使用令牌参数对用户身份进行二次验证

防御手段：在重要业务操作时增加检验用户身份的令牌；

审计位置：较高权限用户执行敏感业务操作（如修改密码，提升用户权限）的位置

实例：测试论坛同时还有一个andowson.com进行二次开发的2.4.1版本，因为jforum曾被提过存在CSRF漏洞，这个版本使用了OWASP的CSRF防护lib，该点没有再审。

上传： 特征：文件类型验证有缺陷可以被绕过，具体见防御手段

防御手段：上传文件类型白名单、mime验证、文件重命名（不改后缀名）、改后缀名、上传目录不可执行。

审计位置：文件上传表单

实例：测试论坛会对上传文件重命名，在原后缀名后增加一个'_'号，所以上传后的文件均不可执行

命令注入： 特征：java的命令执行函数，如Runtime.getRuntime().exec

防御手段：对传入命令执行函数的数据使用白名单过滤

审计位置：所有命令执行函数名存在的位置。

实例：测试论坛没有该调用

远程文件包含： Java不存在该问题

越权： 特征：高权限用户才允许执行的一些操作，执行前未进行用户权限验证

防御手段：检查是否进行了权限的验证

审计位置：高权限用户才允许执行的一些操作

实例：与业务有关，需整理业务逻辑，本次未进行这个点的审计

敏感信息泄露： 位置：注释、 服务器报错信息，未自定义错误页面、 网站备份、测试页面

一种检查思路：敏感信息包括哪些（密码、资料、业务字段）、是否加密，加密算法是否脆弱

实例：未审计

Session： 问题：Session timeout周期过长、用户登出时，session不销毁、多次登录时，session值是一样的

实例：测试论坛的session每次是随机生成的，在登陆时会销毁，session超时时间为10分钟

    <listener>
        <listener-class>net.jforum.ForumSessionListener</listener-class>
    </listener>
    ......
    <!-- SESSION -->
    <session-config>
        <session-timeout>10</session-timeout>
    </session-config>

Cookie： 问题：用户登出时，cookie未销毁、cookie中明文保存了敏感信息、未设置安全标志 防御手段：cookie及时销毁、敏感信息加密存储、设置http only标志

实例：测试论坛未在本地保存密码； 当选择下次自动登录后，服务器会生成一个随机的hash保存在本地cookie中，下次登陆时浏览器自动带上id和hash值到服务器端进行对比

以上是目前代码审计的检查表，方便后续继续建议和更新。

审计成果：按照以上检查list对Jforum2.1.9进行了审计，发现了一个存储型XSS漏洞，因为不熟悉CVE申请流程，该漏洞最终未申请CVE，但是通知了软件的开发者对该漏洞进行了修补。

同时，软件开发者提供了一份之前请安全公司进行渗透测试的报告供交流，在该报告中，普通的渗透测试并未发现该存储型XSS漏洞（因为逻辑藏得比较深），且fortify也未发现该漏洞，此处即可以看到代码审计的价值。