共计 3520 个字符，预计需要花费 9 分钟才能阅读完成。
转自：码农翻身（微信号：coderising）
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，把数据发到我们这里。”
我赶紧禁声。
检查很快，他很快就放行了：“我们这也是为了大家安全, 好了，通过了，等会儿见。”
（点开图片，放大看，很多细节噢）
经过了 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 之后再拦截我们一下。
像这样：
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 了。
漫长的旅途又要开始，带着保险柜，跨越千山万水，乘坐各种交通工具，虽然累但也挺有趣，下次再讲吧。
历险通道