j2ee框架使用中，框架特点及不良习惯容易引发的安全问题：越权操作！

//ps: 这也是个常见的问题，都知道，但为什么还是有人犯这个错误了（不是每个互联网公司都有SDL的，目前来看，公司业务大，架构不一定完整，安全架构更无从说起）？这里作者也是（查看自己写的简单MVC模式框架实现的一个简单应用中出现了类似问题，虽然没危害，但觉得开发时的习惯很重要，能避免一些安全问题），在这里留个底本，如果哪天转行做做安全玩玩，没准哥还能拿它做个j2ee安全开发培训的基础教材，哈哈！安全漏洞或问题的本质其实都很简单（这里也推荐一下乌云的新平台，它还是很有意义的（为什么这么说？仔细看完这段话后再自己想想吧！）：WooYun知识库）。

越权操作：是个很常见的安全问题，应用开发或设计者对访问权限没有考虑或考虑不全。他们即希望于用个未知的访问URL来打发不熟悉开发的攻击者，但如果熟悉就很容易被猜解了。

MVC模式的框架，如：Struts2（其他常规框架或自己写的框架同理，这里框架优点我们就不去讨论了！），它对访问控制弄了个类似默认的规范，对于同一业务对象或者叫DTO的操作都可以（注意这里的“可以”之词，是不强迫你，但默认要你按这个流程开发了，由开发者决定的问题。）放在一个类里面实现，而不同的操作（无非：C（增）R（查）U（改）D（删）等操作，）通过类里面的不同方法实现，但就是这个规范的引导加上一些开发时对实现方法的命名不良习惯及诸多因素的影响，可能导致安全问题的发生，如：

对于有权限考虑的应用，如果是个注册型的网站，简单拆分一下CRUD操作权限（在这里我们只讨论越权，平行权限之类等问题不考虑了！），C（增加即注册），及U（修改）用户是可以触及；而R（查询）、D（删除）只有管理员才能操作的，实例代码：

import com.opensymphony.xwork2.ActionSupport;
public class MemberAction extends ActionSupport {
    public String register() {
        //注册用户，实例代码略...
        return REGISTER;
    }
    public String add() {
        //保存用户，实例代码略...
        return ADD;
    }
    public String getList() {
        //查询用户，实例代码略...
        return LIST;
    }
    //其他方法省略...
    public String execute() {
        return SUCCESS;
    }
}

当用户注册时，先访问：http://xxx.xxx.xxx/member.do?method=register注册，再通过：http://xxx.xxx.xxx/member.do?method=add保存数据。如果是一个了解j2ee开发流程的攻击者，马上就会猜解到method=xxx其他方法名（如关键字：list、getList）来访问管理员权限：http://xxx.xxx.xxx/member.do?method=getList。

在这里绝对不是偶然，在实际开发中，也不会将方法名称搞得很复杂，而且开发者在对框架学习之初对add、getList、delete等，这样类似枚举类型的关键字选词产生依赖，形成习惯，熟悉攻击者就很容易猜解它。

值的注意的是，这里越权问题的产生，有一个很大因素：框架提供一个业务对象操作的类似规范（在同一个Action类中操作，框架不强迫，但结合上下文容易出现安全问题。主要是说这个问题，哈哈！）！

乌云案例：苏宁易购某站点应用设计缺陷！

//问题太简单，都无力去描述了，但发现你们做安全的人当前就是反复在做这些事情！

原文地址：http://hi.baidu.com/shineo__o/item/3cb8a4ecd8c8dc932f140b07

乌云吐槽：

无敌L.t.H | 2013-01-19 15:52

MVC的话可能除了C还得把V给搞定，视图不一定一样。

horseluke (微碌) | 2013-01-19 18:45

j2ee可以引入AOP（切面编程）来解决这个问题吧？

Sogili (. )( .) | 2013-01-19 19:01

struts2有拦截器啊

shine (shield) | 2013-01-19 19:41

@Sogili @horseluke 你们的回答让哥[乍舌]，如果都能想到AOP及拦截器等解决方法，应该不会这么容易出现这个问题了。你们都是对的，问题没这么复杂，解决方法很多。主要开发者意识及框架特点诸多因素影响造成的，加强安全意识比较重要。如果非要从框架自身入手，引入第三方安全框架或自己弄一个权限访问插件，但开发成本及开发者自身要求等都高了点（这几项好象都是做安全的历史难题啊）！

horseluke (微碌) | 2013-01-19 21:08

@shine 就谁来负责问题，我也在OAuth 2.0的研究中有困惑。如果一个协议或框架需要开发者自行保证安全，那么就只能取决于开发者的安全意识，和安全意识的普及程度。实际上来讲，这样就等于把开发者推向重复出老漏洞的怪论中；但如果框架自己都包罗万象，那么在开发看来，绝不是好框架（意味着只能依赖它来实现，无法解耦）。

有时间，看来要写篇文章交流一下困惑。

GaRY | 2013-01-19 22:38

这就是框架的本身的设计问题，尤其s2还嫌用户不方便，还设计一个动态方法调用(DMI)。让这问题更甚。

不过正如之前几位所说，S2用拦截器，S1也可以用Filter去解决这个问题。但还是一般的开发者的确很容易犯这种错误，这就得靠各个框架的教程，demo去潜移默化了，也是各位安全工作者的任务，一定要做好安全开发培训。

GaRY | 2013-01-19 22:44

看到楼主此文，想到我之前有个关于S1和S2相关安全方面比对的文档，我找找发上来。

shine (shield) | 2013-01-20 11:09

@horseluke 这个应该没什么好困惑的吧？

例如：通常情况下，一个框架如果能够远程代码执行，肯定是安全漏洞（不是绝对啊！）；如果是上面这个安全问题，但如果在现实中危害表现得严重，就会有你们这样的安全人员反馈信息给产品开发者，再通过产品开发者的一些思想斗争后，把安全问题上升到安全漏洞，做出适应的策略解决这个问题。只是这个流程在不断完善而已！

安全只能做到平衡（所有存在的事物也同样），不困惑。不然，象剑心、GaRY等安全行业的人，只能组团搞摇滚或当国际诗人或者其他了！

文章目录