最近在前端異常監控系統中，發現一些異常資訊，從中做了一些分析，得到一些體會，是以作文。
某天早上打開監控系統發現，當天淩晨1點過測試環境有2個前端上報的異常，報錯的原因都是由于沒有擷取到 url 中的參數，比如正常的位址應該是 www.xx.com?a=1&b=2, 但是實際通路的是 www.xx.com%3Fa%3D1%26b%3D2。 很明顯路徑被 encode 了，導緻程式沒有拿到參數。
2個異常的通路路徑是不一樣的，并且以上2個位址 decode 之後再通路，能夠正常打開頁面，參數全部都是正确的。 這些通路的 url 是我們在做跳轉的時候，入口配置的，我們的邏輯中不會 encode，這個地方非常讓人疑惑，為什麼會出現這樣的請求，猜測很可能是人為修改了再通路的。 後來把參數擷取出來，去查詢一些資訊，發現這條請求是都來自于我們的測試同學的賬戶，但是私下詢問過，1點過同僚根本什麼都沒有做。 也排除了有其他人用他手機通路的情況。 再對參數裡的資訊做查詢，發現這2個參數對應的資料是在2個多月前，我們項目測試階段的資料，這就更奇怪了，2個月前的版本我們已經沒有再測試了，同僚也很久沒有通路過這幾個入口。 是不是有人在刷我們的頁面，但為什麼幾個參數都是如此精确，都是正确的。
一定有其他人在通路。因為各方面情況看起來都很不正常：
1. 淩晨1點過通路的
2. 通路路徑被 encode 了
3. 資料是測試同僚的，他自己卻沒有通路過。
4. 通路的位址的資料都是2個月前生成的，如果有三方黑客擷取到了通路記錄之後，延遲到最近批量通路也符合行為邏輯
再看看上報的其他異常資訊，更奇怪了，浏覽器的版本無從得知，User-Agent 隻有 Go-http-client/1.1 ， 怎麼看都像是爬蟲腳本在做請求。 說到爬蟲，爬蟲一般會針對已知的接口進行資料拉取，以擷取他人的資訊； 又或者不停的周遊不同的路徑，查找可通路的路由（隐藏的後門），路徑周遊很容易發現，如果有日志的話，就能看到很多 404， 大量的通路一些奇怪的路徑。 那我們遇到的，是前期通過某種方式攔截到我們的網頁請求，收集起來，到一定時間再去通路，這種方式叫做：重播攻擊。
我們在伺服器又查詢了 IP 等一些相關的資訊，發現有幾個 IP 時不時的在做這樣的通路攻擊，而且也看得出對方很謹慎，沒有同時做大批量的請求。 又發現了更多的異常行為，首先比如一個 www.x.com/page 的頁面路徑，它使用 post 方法去請求了一次。
所有的異常資料，被通路的路徑都是測試環境的位址，使用的 http，而我們的正式環境使用的 https，對方似乎并沒有能力擷取到 https 的請求。 通過查詢這幾個 IP 在正式環境通路，又發現了一條記錄，而剛好這條記錄的通路位址沒有 https（因為有時候，我們的開發自己可能會手動把 https 改成 http 去通路）。 到目前的結論是黑客方的監聽是和我們的項目環境沒有關系的，隻是因為我們正式環境使用了 https 他才沒有擷取到。
最初以為隻是一個同僚的手機被監聽了，但是因為又出現了另一個同僚的請求，是以覺得爬蟲在路由器層攔截的機率更大，而且剛好這兩個同僚有一個用的是安卓，有一個用的是蘋果，是以看起來所有的裝置都有命中的可能。 但是如果是公司路由器的問題，那為什麼目前為止就隻發現了兩個同僚的通路被爬取了，這些網頁其他同僚也都通路過，而且頻率也不低。 對方的政策具體是什麼，到底在哪裡攔截的，我有點束手無策了。 而後詢問過另一個同僚後，得知對方大概是在20多天前通路的，爬蟲通路的記錄全部集中在這幾天。 種種迹象表明确實是前期收集了一段時間，這兩天才開始出來集中通路的。
前面通過查詢 IP，發現爬蟲的伺服器都在國内，但是對方也可能隐藏掉了真實 IP 。 如果對方的行為對公司造成了傷害，也許可以進一步去查對方伺服器歸屬人。 但是因為從對方通路量和攻擊程式來說，對我們幾乎沒有傷害。 甚至能感覺到對方不是定向要攻擊我們。 看起來更像是對方的程式遊離在網際網路上，收集到了什麼，就幹點什麼的意思。
再來說說安全性問題，我們常常在通路 url 的時候，帶上一些參數，比如在 app 中，内嵌一些 h5，h5 的參數中需要帶上一些識别身份的 token。 如果說、我們沒有使用 https，黑客在中間層監聽了我們的請求，就能擷取到我們的資料，甚至對方萬一得到了 token，還能擷取更多我們的隐私資訊。 這就給重播攻擊提供了安全漏洞。
那麼防禦重播攻擊，有什麼辦法呢？ 常用的辦法有兩種
（1）加随機數保障隻被使用一次，但是需要額外空間存儲曆史使用過的值；
（2）加時間戳，不用額外儲存資訊，但是需要同步時間，但同步時間并不能達到各種情況下的準确。 總之大概方向就是需要一個參數，來判斷是否失效。
網上文章很多，這裡就不做一一解釋了，簡單說兩點，https 利用非對稱加密和對稱加密、保障資料安全；利用數字證書做雙向身份校驗、保障不被釣魚。
以前知道抓包工具通過一定配置就能抓取到 https 請求，這樣一想，那 https 是不是就不安全啊，抓包工具都能攔截到。 首先我們需要先了解它的原理，才能做下一步分析。
抓包工具抓取 https 的原理是利用抓包工具做中間代理人，和用戶端建立信任連接配接以後，再代用戶端去向服務端發送和接受請求，達到中間商的效果，這樣抓包工具既能看到資料，用戶端也能正常使用。
用戶端向伺服器發起HTTPS請求
Charles攔截用戶端的請求，僞裝成用戶端向伺服器進行請求
伺服器向“用戶端”（實際上是Charles）傳回伺服器的CA憑證
Charles攔截伺服器的響應，擷取伺服器證書公鑰，然後自己制作一張證書，将伺服器證書替換後發送給用戶端。（這一步，Charles拿到了伺服器證書的公鑰）
用戶端接收到“伺服器”（實際上是Charles）的證書後，生成一個對稱密鑰，用Charles的公鑰加密，發送給“伺服器”（Charles）
Charles攔截用戶端的響應，用自己的私鑰解密對稱密鑰，然後用伺服器證書公鑰加密，發送給伺服器。（這一步，Charles拿到了對稱密鑰）
伺服器用自己的私鑰解密對稱密鑰，向“用戶端”（Charles）發送響應
Charles攔截伺服器的響應，替換成自己的證書後發送給用戶端
至此，連接配接建立，Charles拿到了 伺服器證書的公鑰 和 用戶端與伺服器協商的對稱密鑰，之後就可以解密或者修改加密的封包了
是以前提是用戶端需要選擇信任并安裝 Charles 的證書，否則抓包工具也無法攔截 https，在網際網路上大部分惡意腳本程式，想要抓取使用者資料，也大都是和抓包工具一樣的工作原理，是以 https 還是比較安全的。
記得以前公司還沒使用 https 的時候，可能大家都經曆過惡心的流量劫持，我們自己線上上環境使用都挺正常的，時不時其他地區的同僚會告訴我們說，頁面上漂浮了一個按鈕，點開就跑到其他地方去了。 甚至說有些注入的代碼有問題，導緻我們的界面也出現了問題，當時各種研究後，最後的辦法就是上 https， 到現在就再也不用擔心這個問題了。 現在一些浏覽器通路非 https 的頁面，都會提示不安全，平時也看得到一些他人的網站都還是沒用 https，進去就會報警告。 也如我們發現的重播攻擊，這些安全問題确實存在于網絡中，甚至無人能避免，是以沒用 https 的站點，還是快點更新吧！
有沒有人打賞？沒有的話，那我晚點再來問問。
關注大詩人公衆号，第一時間擷取最新文章。
如果你有購買鋼琴的打算，可以從這裡了解到在售資訊，價格實惠品質保障。
---轉發請标明，并添加原文連結---