轉自:碼農翻身(微訊號: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了。
漫長的旅途又要開始, 帶著保險櫃, 跨越千山萬水, 乘坐各種交通工具, 雖然累但也挺有趣, 下次再講吧。