沿着0xa84d通道摆放着一列柜台, 前面几个柜台上写着"拦截器",都坐着人, 中间一个柜台上写着LoginAction, 那就是我们的目的地了。 "我是Exception 拦截器, 不过现在没啥事儿, 等会儿见""不用那么详细, 我就记个国家和语言, 你们用zh_CN吧, 等会儿见"第三个柜台是FileUpload 拦截器, 他看了一眼就放行了, 我这儿实在是没有任何文件上传的东西。"我是Parameter 拦截器, 打劫了,把你包裹里的参数全给我 "但0x6904见怪不怪: "我们这儿有 user.name 和user.password , 拿去吧” Parameter 拦截器说 : "好的, 我会把他们放到ValueStack中, LoginAction 会用到, 等会儿见,伙计们。"我有些不满: "我从老IE那里出发的时候, 那里的javascript 已经验证过了,这些数据绝对没有问题"Validation拦截器毫不示弱的教训我: "年轻人呐,javascript 验证算啥啊, 这种基于浏览器的检查很容易被绕过, 没听见刚才的警报吗,黑客不用浏览器轻轻轻松就能搞个HTTP POST,把数据发到我们这里。"检查很快, 他很快就放行了: “我们这也是为了大家安全, 好了, 通过了, 等会儿见。”
![]()
(点开图片,放大看, 很多细节噢)
经过了5个拦截器, 我们终于来到了LoginAction的跟前。
他这里有个User对象, 有个setName() 和setPassword() 的方法, 很明显, 值是从我的包裹中来的。 LoginAction 干活一丝不苟: 给LoginService 打电话, 让他执行登录方法,查查数据库, 看看这个用户名和密码对不对, 最后告诉我:"登录成功, 记住这个返回码 success ,下一个柜台会用。 还有,这是你的session id, 记着回去一定要交给老IE让他好生保管"我问0x6904 : "我的包裹里好像有个session id 啊, 为什么又给我一个?""这也是安全起见, 登录成功以后, 一定要生产新的session id , 把老的session id 给废除掉, 你结合XSS攻击,想想为什么要这么做“ 我想了想: XSS攻击主要就是偷用户的session , 如果有个黑客在登录之前的页面上构造了一个XSS攻击,如果有人浏览到这个界面,虽然没有登录, session id 也被偷走了。 然后黑客不停的尝试这些偷来的session id, 访问那些登录后才能访问的页面。 如果session id 对应的用户登录了网站, 那么黑客也可以登录了 - 因为session id 没有变。我说:没想到这网络世界这么可怕, 幸亏你们这里防卫森严啊。接下来的柜台果然问我们要那个返回码"success",然后从struts.xml这张纸上找到 LoginAction的配置, 从中找到了对应的jsp : /WEB-INF/home.jsp , 生成html 交给了我。 <action name="login" class="example.LoginAction"> <result name="success">/WEB-INF/home.jsp</result>后面的柜台就让我大跌眼镜了, 这些人不都是刚刚见过的吗, 怪不得他们都说等会儿见。 只是次序和刚才不同: 先是Validation, 然后是Parameter, FileUpload, I18n , Exception , 和刚才进来的时候完全倒过来了!
![]()
(点开图片,放大看, 很多细节噢)
我有点明白了, 这些家伙们只是都是在LoginAction执行之前拦截我们一下, 在LoginAction 之后再拦截我们一下。
Validation,Parameter ,FileUpload, I18n 只是对我们笑了笑就放行了, 我们已经执行完了, 他们确实没啥可拦截的。 又到了Exception 拦截器, 他问我们: "有什么异常吗?"Exception拦截器说: "好,那我也不用再做什么事儿了, 你们可以离开这个通道了"(码农翻身注: 实际的Struts 拦截器比这里列的要更多)终于走了出来 , 我感慨的对0x6904说: "这个ActionProxy通道可是真麻烦啊"。0x6904说: "其实这个通道设计的挺精致的, 你看只要走一遍, 像参数处理, 表单验证,国际化等事情都搞定了。 "我问他: "每个Action 都有这么多拦截器吗?""不一定, 这是可以定制的,每个Action都可以不同 ""绝对不会, 一人一个, 用过就销毁, 垃圾回收了"我虽然有些吃惊, 但仔细想想 ,很正常, 这个通道其实保存了我的信息 , 别人确实不能用啊。