其他
Http历险记(下)-- Struts的秘密
0x6904说： "奥，我刚刚在线程池里睡觉， 刚起床，犯傻了， 我们想见LoginAction, 得经过特定的ActionProxy通道， 你等等，我去问问Filter老大，我们具体到哪个通道去。 "
（码农翻身注： 关于线程池参见《我是一个线程》）
我在那儿无聊的等0x6904, 饶有兴趣的看着大家都是从通道的这头进去， 从另外一头出来。 有的快，有的慢。
有个贼头贼脑的家伙刚从一个通道出来， 突然凄厉的警报大声想起来： 注意， 有javascript 攻击。
一群卫兵跑过来把他给按住了， 带头的领导打开这个家伙的包裹， 仔细的检查里边的数据：
"报告Filter老大， 这个返回包裹里要把用户输入的数据送回浏览器， 但是这个用户输入的数据包含<javascript>..</javascript> 这样的代码，怎么处理，请指示”
"按规定消毒吧， 把这些‘<’ '>' 字符做转义操作， 这样发送到浏览器就只是显示，而不会执行了"
（码农翻身注： 转义指的是吧 < , > , & 等字符转成 < > & 这样的转义字符）
怪不得Filter老大这么忙， 这么细的事情都管啊。
这时候0x6904气喘吁吁的回来了: "快， 走0xa84d通道"
我说： "刚才那个警报是咋回事， 为什么要把<javascript> 做转义操作？"
"这么说吧， 这些javascript 的脚本不是我们系统产生的， 可能是黑客精心构造的， 通过参数发送到我们这里， 如果我们不消毒， 直接发到用户的浏览器，这些javascript 就有可能在浏览器执行，会把用户的cookie (里边有session id ） 偷走， 然后黑客就可以假装成用户来干坏事了， 例如：把你的钱转走！ "
我心里暗暗吃惊： "这么厉害啊"
"是啊， 很多网站如果不对用户的输入和输出消毒， 就可能出乱子， 这种黑客攻击叫做 XSS, 跨站点脚本攻击"
后面几个柜台上也写着“拦截器”，但没有人在那里。这到底是要干嘛呢？
我和0x6904来到第一个柜台， 他对我们说："我是Exception 拦截器， 不过现在没啥事儿， 等会儿见"
我心里犯嘀咕：没事你一本正经的待在这儿干嘛？ 第二个柜台的拦截器对我们说：
"我是I18n 拦截器， 你们从哪里来啊"
"中国北京中关村软件园"， 我说
"不用那么详细， 我就记个国家和语言， 你们用zh_CN吧， 等会儿见"
第三个柜台是FileUpload 拦截器， 他看了一眼就放行了， 我这儿实在是没有任何文件上传的东西。
到了第四个柜台， 有个家伙笑着对我说："我是Parameter 拦截器， 打劫了，把你包裹里的参数全给我 "
我心想: 我靠， 又要要钱了。
但0x6904见怪不怪： "我们这儿有 user.name 和user.password , 拿去吧”
Parameter 拦截器说 : "好的， 我会把他们放到ValueStack中， LoginAction 会用到， 等会儿见，伙计们。"
怎么都是等会儿见？
下一个柜台是Validation 拦截器。
我有些不满： "我从老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></action>
后面的柜台就让我大跌眼镜了， 这些人不都是刚刚见过的吗， 怪不得他们都说等会儿见。
只是次序和刚才不同： 先是Validation, 然后是Parameter, FileUpload, I18n , Exception ， 和刚才进来的时候完全倒过来了！
（点开图片，放大看， 很多细节噢）
我有点明白了， 这些家伙们只是都是在LoginAction执行之前拦截我们一下， 在LoginAction 之后再拦截我们一下。
Validation，Parameter ，FileUpload， I18n 只是对我们笑了笑就放行了， 我们已经执行完了， 他们确实没啥可拦截的。
又到了Exception 拦截器， 他问我们： "有什么异常吗？"
我想了想， 整个过程确实没有异常： “一切顺利”
Exception拦截器说： "好，那我也不用再做什么事儿了， 你们可以离开这个通道了"
（码农翻身注： 实际的Struts 拦截器比这里列的要更多）
终于走了出来 ， 我感慨的对0x6904说： "这个ActionProxy通道可是真麻烦啊"。
0x6904说： "其实这个通道设计的挺精致的， 你看只要走一遍， 像参数处理， 表单验证，国际化等事情都搞定了。 "
我问他： "每个Action 都有这么多拦截器吗?"
"不一定， 这是可以定制的，每个Action都可以不同 "
"那我们走了， 这个通道还会让别的人用吗"
"绝对不会， 一人一个， 用过就销毁， 垃圾回收了"
我虽然有些吃惊， 但仔细想想 ，很正常， 这个通道其实保存了我的信息 ， 别人确实不能用啊。
0x6904神色立刻就紧张了， 指着一个通道对我说： "从这里可以回到Nginx 大厦，我得赶紧接待别人去了， 再见"
回到Nginx大厦， 和Tomcat相比，这里就是另外一个世界， 人声鼎沸，04号长工还是一如既往的忙。 看到我回来， 他就说： "怎么样，Tomcat那里感觉如何？ "
我感慨的说："那里比你这里复杂多了"
04号长工帮忙把返回的包裹装进了小保险柜， 告诉我说： "好了， 我这儿的事情也处理完了，一会儿你就可以坐车回老IE那里去了"
是啊， 我出来这么长时间，确实有点想老IE了。
漫长的旅途又要开始， 带着保险柜， 跨越千山万水， 乘坐各种交通工具， 虽然累但也挺有趣， 下次再讲吧。
特别感谢： 网友blindingdark 提供的形神具备的配图， 这可是先在纸上手绘， 然后扫描变成图片编辑，很不容易啊 :-)
相关阅读：
Http历险(上)我是一个线程IE为什么把Chrome和火狐打伤了对浏览器村的第二次采访