SSLStrip的未來——HTTPS前端劫持(1)

0x00 前言在之前介紹的流量劫持文章裡，曾提到一種『HTTPS 向下降級』的方案 —— 將頁面中的 HTTPS 超連結全都替換成 HTTP 版本，讓使用者始終以明文的形式進行通信。 看到這，也許大家都會想到一個經典的中間人攻擊工具 —— SSLStrip，通過它確實能實現這個效果。 不過今天講解的，則是完全不同的思路，一種更有效、更先進的解決方案 —— HTTPS 前端劫持。 0x01 後端的缺陷在過去，流量劫持基本通過後端來實現，SSLStrip就是個典型的例子。 類似其他中間人工具，純後端的實現只能操控最原始的流量資料，這嚴重阻礙了向更高層次的發展，面臨眾多難以解決的問題。 動態元素怎麼辦?如何處理資料包分片?性能消耗能否降低?...... 動態元素在 Web 剛出現的年代裡，SSLStrip 這樣的工具還是大有用武之地的。 那時的網頁都以靜態為主，結構簡單層次清晰。 在流量上進行替換，完全能夠勝任。 然而，如今的網頁日益複雜，腳本所占比重越來越多。 如果僅僅從流量上著手，顯然力不從心。 varprotocol='HTTPs'; document.write('<ahref="'+protocol+'://www.alipay.com/">Login</a>');即使非常簡單的動態元素，後端也毫無招架之力。 分片處理分塊傳輸的道理大家都明白。 對於較大的資料，一口氣是無法傳完的。 用戶端依次收到各個資料塊，最終才能合併成一個完整的網頁。 498)this.width=498;' onmousewheel = 'javascript:return big(this)' border="0" alt="SSLStrip的未來 —— HTTPS前端劫持" width="521" height="205" src="HTTP://s3.51cto.com/wyfs02/M00/4D/AA/wKiom1RW6ZWT-0h1AAAswwGQRzU074.png" />由於每次收到的都是殘缺的碎片， 這給連結替換帶來很大的麻煩。 加上不少頁面並非標準的 UTF-8 編碼，因此更是難上加難。 為了能順利進行，中間人通常先收集資料，等到頁面接收完整，才開始替換。 498)this.width=498;' onmousewheel = 'javascript:return big(this)' style="width: 491px; height: 132px" border="0" alt="SSLStrip的未來 —— HTTPS前端劫持" width="823" height="200" src="HTTP://s7.51cto.com/wyfs02/M01/ 4D/A9/wKioL1RW6gGA3mUGAABCNseanxs927.png" />如果把資料比作水流，這個代理就像大壩一樣，攔截了源源不斷往下流的水，直到蓄滿了才開始釋放。 因此，下游的人們需忍受很久的乾旱，才能等到水源。 性能消耗由於 HTML 相容眾多歷史遺留規範，因此替換工作並非是件輕鬆事。 各種複雜的正則運算式，消耗著不少的 CPU 資源。 儘管使用者最終點擊的只是其中一兩個連結，但中間人並不知道將會是哪個，因此仍需分析整個頁面。 這不得不說是個悲哀。 1 2 3 4 5 6 下一頁>>查看全文 內容導航第 1 頁：後端的缺陷 第 2 頁：前端的優勢 第 3 頁：更多攔截 第 4 頁：後端配合 第 5 頁：防範措施 第 6 頁：攻擊演示 原文：SSLStrip的未來——HTTPS前 端劫持(1) 返回網路安全首頁