转载

Http历险记(下)-- Struts的秘密

转自:码农翻身(微信号:coderising)

Http历险记(下)-- Struts的秘密

Http历险记(上) 说到,我来到了Ngnix大厦, 04号长工接待了我, 然后把我转到到Tomcat这里, 遇到了著名的0x6904号线程, 他带着我找了Struts的Filter老大, 然后到二楼找LoginAction , 新的历险开始了…

第三章 警报

到二楼一看, 嚯,好家伙,这里有成千上万个通道, 名称全是 ActionProxy, 哪里有什么LoginAciton ?

0x6904说: "奥,我刚刚在线程池里睡觉, 刚起床,犯傻了, 我们想见LoginAction, 得经过特定的ActionProxy通道, 你等等,我去问问Filter老大,我们具体到哪个通道去。 "

我在那儿无聊的等0x6904, 饶有兴趣的看着大家都是从通道的这头进去, 从另外一头出来。 有的快,有的慢。

有个贼头贼脑的家伙刚从一个通道出来, 突然凄厉的警报大声想起来: 注意, 有javascript 攻击。

一群卫兵跑过来把他给按住了, 带头的领导打开这个家伙的包裹, 仔细的检查里边的数据:

"报告Filter老大, 这个返回包裹里要把用户输入的数据送回浏览器, 但是这个用户输入的数据包含… 这样的代码,怎么处理,请指示”

“按规定消毒吧, 把这些‘<’ ‘>’ 字符做转义操作, 这样发送到浏览器就只是显示,而不会执行了”

(码农翻身注: 转义指的是吧 < , > , & 等字符转成 < > & 这样的转义字符)

怪不得Filter老大这么忙, 这么细的事情都管啊。

这时候0x6904气喘吁吁的回来了: “快, 走0xa84d通道”

我说: “刚才那个警报是咋回事, 为什么要把 做转义操作?”

"这么说吧, 这些javascript 的脚本不是我们系统产生的, 可能是黑客精心构造的, 通过参数发送到我们这里, 如果我们不消毒, 直接发到用户的浏览器,这些javascript 就有可能在浏览器执行,会把用户的cookie (里边有session id ) 偷走, 然后黑客就可以假装成用户来干坏事了, 例如:把你的钱转走! "

我心里暗暗吃惊: “这么厉害啊”

“是啊, 很多网站如果不对用户的输入和输出消毒, 就可能出乱子, 这种黑客攻击叫做 XSS, 跨站点脚本攻击”

第四章 拦截器

沿着0xa84d通道摆放着一列柜台, 前面几个柜台上写着"拦截器",都坐着人, 中间一个柜台上写着LoginAction, 那就是我们的目的地了。

后面几个柜台上也写着“拦截器”,但没有人在那里。

这到底是要干嘛呢?

我和0x6904来到第一个柜台, 他对我们说:

“我是Exception 拦截器, 不过现在没啥事儿, 等会儿见”

我心里犯嘀咕:没事你一本正经的待在这儿干嘛?

第二个柜台的拦截器对我们说:

“我是I18n 拦截器, 你们从哪里来啊”

“中国北京中关村软件园”, 我说

“不用那么详细, 我就记个国家和语言, 你们用zh_CN吧, 等会儿见”

第三个柜台是FileUpload 拦截器, 他看了一眼就放行了, 我这儿实在是没有任何文件上传的东西。

到了第四个柜台, 有个家伙笑着对我说:

"我是Parameter 拦截器, 打劫了,把你包裹里的参数全给我 "

我心想: 我靠, 又要要钱了。

但0x6904见怪不怪: "我们这儿有 user.name 和user.password , 拿去吧”

Parameter 拦截器说 : “好的, 我会把他们放到ValueStack中, LoginAction 会用到, 等会儿见,伙计们。”

怎么都是等会儿见?

下一个柜台是Validation 拦截器。

我有些不满: “我从老IE那里出发的时候, 那里的javascript 已经验证过了,这些数据绝对没有问题”

Validation拦截器毫不示弱的教训我:“年轻人呐,javascript 验证算啥啊, 这种基于浏览器的检查很容易被绕过, 没听见刚才的警报吗,黑客不用浏览器轻轻轻松就能搞个HTTP POST,把数据发到我们这里。”

我赶紧禁声。

检查很快, 他很快就放行了: “我们这也是为了大家安全, 好了, 通过了, 等会儿见。”

Http历险记(下)-- Struts的秘密

(点开图片,放大看, 很多细节噢)

经过了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>
</action>

后面的柜台就让我大跌眼镜了, 这些人不都是刚刚见过的吗, 怪不得他们都说等会儿见。

只是次序和刚才不同: 先是Validation, 然后是Parameter, FileUpload, I18n , Exception , 和刚才进来的时候完全倒过来了!

Http历险记(下)-- Struts的秘密

(点开图片,放大看, 很多细节噢)

我有点明白了, 这些家伙们只是都是在LoginAction执行之前拦截我们一下, 在LoginAction 之后再拦截我们一下。

像这样:

Exception : 执行login之前拦截

I18n : 执行login之前拦截

FileUpload: 执行login之前拦截

Parameter : 执行login之前拦截

Validation: 执行login之前拦截

执行 LoginAction

生成结果

Validation: login之后拦截

Parameter : login之后拦截

FileUpload: login之后拦截

I18n : login之后拦截

Exception : login之后拦截

Validation,Parameter ,FileUpload, I18n 只是对我们笑了笑就放行了, 我们已经执行完了, 他们确实没啥可拦截的。

又到了Exception 拦截器, 他问我们: “有什么异常吗?”

我想了想, 整个过程确实没有异常: “一切顺利”

Exception拦截器说: “好,那我也不用再做什么事儿了, 你们可以离开这个通道了”

(码农翻身注: 实际的Struts 拦截器比这里列的要更多)

终于走了出来 , 我感慨的对0x6904说: “这个ActionProxy通道可是真麻烦啊”。

0x6904说: "其实这个通道设计的挺精致的, 你看只要走一遍, 像参数处理, 表单验证,国际化等事情都搞定了。 "

我问他: “每个Action 都有这么多拦截器吗?”

"不一定, 这是可以定制的,每个Action都可以不同 "

“那我们走了, 这个通道还会让别的人用吗”

“绝对不会, 一人一个, 用过就销毁, 垃圾回收了”

我虽然有些吃惊, 但仔细想想 ,很正常, 这个通道其实保存了我的信息 , 别人确实不能用啊。

第五 尾声

正和0x6904说着, 大喇叭又响了: “0x6904,你在那儿磨叽啥, 顾客都排大队了,人手不够, 快点回来”

0x6904神色立刻就紧张了, 指着一个通道对我说:“从这里可以回到Nginx 大厦,我得赶紧接待别人去了, 再见”

回到Nginx大厦, 和Tomcat相比,这里就是另外一个世界,人声鼎沸,04号长工还是一如既往的忙。

看到我回来,他就说:"怎么样,Tomcat那里感觉如何? "

我感慨的说:“那里比你这里复杂多了”

04号长工帮忙把返回的包裹装进了小保险柜, 告诉我说: “好了, 我这儿的事情也处理完了,一会儿你就可以坐车回老IE那里去了”

是啊, 我出来这么长时间,确实有点想老IE了。

漫长的旅途又要开始, 带着保险柜, 跨越千山万水, 乘坐各种交通工具, 虽然累但也挺有趣, 下次再讲吧。

历险通道

原文  https://segmentfault.com/a/1190000020320260
正文到此结束
Loading...