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