轉自：碼農翻身（微訊號：coderising）
原文連結： https://mp.weixin.qq.com/s/-Ddar1s2IBTQDtQw01r6zA
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 交給了我。
1 <action name="login" class="example.LoginAction">2 <result name="success">/WEB-INF/home.jsp</result>3 </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了。
漫長的旅途又要開始， 帶著保險櫃， 跨越千山萬水， 乘坐各種交通工具， 雖然累但也挺有趣， 下次再講吧。