您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
代码审计--源代码审计思路
 
  5226  次浏览      14
 2019-4-4
 
编辑推荐:
本文来自于csdn,本文章主要介绍了如何通过了解整个应用的业务逻辑,逆向回溯的方式只能对通用漏洞进行快速审计。

按照业务类型正向审计

逆向回溯的审计方式针对特征明显的安全漏洞挖掘是非常有效的,但是同样会有很多弊端,通过逆向回溯的方式只能对通用漏洞进行快速审计,不能全面挖掘更有价值的漏洞,如果在时间允许的情况下,企业中安全运营对自身产品进行代码审计,就需要了解整个应用的业务逻辑,比如越权类漏洞,需要了解应用中权限划分,每一级别用户的功能,这样才能很好的发现并确定哪些操作是非法的。

1、某系统越权查看任意用户个人资料

业务类型的正向审计通常从前端页面开始,因为页面会有系统中大部分功能展示,找出功能所对应的URL就是我们所审计数据流的输入点,某系统修改个人资料处存在平行越权。

在客户现场审计大部分情况是没有测试环境的,也就是只能通过前端的展示页面对每一个功能进行审计。客户会直接将项目代码交过来,首先要将它导入编辑器,如果属于Eclipse导出的项目直接导入就可以,但是相对来说没有这么理想的情况,那么可以使用代码编辑器,例如SublimeText,如下图:

可以直接将文件夹拖拽左边目录树,拿到4个代码包,沟通了解到coreServer为核心业务代码属于model层,apiServer为前端的API代码属于controller层,jspxcms为CMS核心和后端管理代码属于view层,cas为单独的单点登录服务包暂时不在此漏洞的审计范围内。

在进行审计之前我们要了解整个应用的架构,通过查看web.xml了解到项目采用SpingMVC架构,并且未在web.xml中配置安全过滤器、身份校验机制,如下图:

SpingMVC的常用@RequestMapping注解为控制器指定可以处理哪些 URL 请求,也就是说可以直接通过在控制层搜索URL请求,即可找到控制层所对应的业务逻辑代码。

通过查看jspxcms中html页面找到修改个人资料的功能页面user/profile.html(可以通过关键字去搜索相应功能页面,比如用户中心搜索user,修改密码搜索password),如下图:

请求的URL会在js文件中,也会在form表单中。

当找到查看个人资料请求的URL后,可以通过SublimeTxt的全局搜索找到apiserver中所对应的业务逻辑代码,如下图:

跟入coreServer中userService类中进行审计,如下图:

2、Jeebbs邮箱逻辑验证漏洞:

注册的URL地址是:http://localhost/jeebbs/register.jspx, register.jspx很明显是控制层映射的URL,第一要务是找到它。然后看他的逻辑。

Tips:Eclipse全局搜索关键字方法:

根据搜索结果找到对应文件:

根据结果找到对应的public class RegisterAct类,并查看对应逻辑代码:

找到控制层的入口后即可在对应的方法内设上断点,然后发送请求到控制层的URL进入Debug模式。

注册发送数据包时用Tamper data拦截并修改请求当中的email为xss攻击代码。

选择任意对象右键Watch即可查看对应的值(任意完整的,有效的对象包括方法执行)。

F6单步执行。

F5进入validateSubmit:

F6跟到125行注册调用:

F3可以先点开registerMember类看看:

找到接口实现类即最终的注册逻辑代码:

3、积分负充漏洞

积分兑换方法如下:

@RequestMapping(value = "/member/creditExchange.jspx")
public void creditExchange(Integer creditIn, Integer creditOut,
Integer creditOutType, Integer miniBalance, String password,HttpServletRequest request, HttpServletResponse response) {}

可以看到这里直接用了SpringMvc注入参数,而这些参数恰恰是控制程序逻辑的关键。比如构建如下URL,通过GET或者POST方式都能恶意修改用户的积分:

http://localhost/jeebbs/member/creditExchange.jspx?

creditIn=26&creditOut=-27600&creditOutType=1

&miniBalance=-10000000&password=wooyun

因为他的逻辑是这么写的:

if(user.getPoint()-creditOut>miniBalance) {
balance=true;
} else {
flag=1;
}

从User对象里面取出积分的数值,而积分兑换威望具体需要多少是在确定兑换关系后由ajax去后台计算出来的,提交的时候也没有验证计算的结果有没有被客户端改过。其中的creditOut和miniBalance都是我们可控的。所以这个等式不管在什么情况下我们都可以让它成立。

4、打招呼功能处XSS

逻辑有做判断:1、用户名为空。2、不允许发送消息给自己。3、用户名不存在。

在控制层并没有做过滤:

在调用com.jeecms.bbs.manager.impl. BbsMessageMngImpl.java的sendMsg方法的时候依旧没有过滤。到最终的BbsMessageDaoImpl 的save方法还是没有过滤就直接储存了;

一般性的做法,关系到用户交互的地方最好做referer和xss过滤检测,控制层负责收集数据的同时最好处理下用户的请求,就算controller不处理起码在service层做下处理吧。

   
5226 次浏览       14
相关文章

深度解析:清理烂代码
如何编写出拥抱变化的代码
重构-使代码更简洁优美
团队项目开发"编码规范"系列文章
相关文档

重构-改善既有代码的设计
软件重构v2
代码整洁之道
高质量编程规范
相关课程

基于HTML5客户端、Web端的应用开发
HTML 5+CSS 开发
嵌入式C高质量编程
C++高级编程