Http歷險記(下)-- Struts的祕密

轉自：碼農翻身（微信號：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了。

漫長的旅途又要開始， 帶着保險櫃， 跨越千山萬水， 乘坐各類交通工具， 雖然累但也挺有趣， 下次再講吧。

歷險通道