從監控異常發現網絡安全

前言

　　最近在前端異常監控系統中，發現一些異常信息，從中作了一些分析，獲得一些體會，所以做文。

發現異常

　　某天早上打開監控系統發現，當天凌晨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 是否是就不安全啊，抓包工具都能攔截到。 首先咱們須要先了解它的原理，才能作下一步分析。

　　抓包工具抓取 https 的原理是利用抓包工具作中間代理人，和客戶端創建信任鏈接之後，再代客戶端去向服務端發送和接受請求，達到中間商的效果，這樣抓包工具既能看到數據，客戶端也能正常使用。

如下是抓包工具抓取 https 的流程（拷貝的他人的總結，也不知道最初是誰寫的，由於網上太多一樣的了，做者勿怪，沒法署名）

1. 客戶端向服務器發起HTTPS請求

2. Charles攔截客戶端的請求，假裝成客戶端向服務器進行請求

3. 服務器向「客戶端」（其實是Charles）返回服務器的CA證書

4. Charles攔截服務器的響應，獲取服務器證書公鑰，而後本身製做一張證書，將服務器證書替換後發送給客戶端。（這一步，Charles拿到了服務器證書的公鑰）

5. 客戶端接收到「服務器」（其實是Charles）的證書後，生成一個對稱密鑰，用Charles的公鑰加密，發送給「服務器」（Charles）

6. Charles攔截客戶端的響應，用本身的私鑰解密對稱密鑰，而後用服務器證書公鑰加密，發送給服務器。（這一步，Charles拿到了對稱密鑰）

7. 服務器用本身的私鑰解密對稱密鑰，向「客戶端」（Charles）發送響應

8. Charles攔截服務器的響應，替換成本身的證書後發送給客戶端

9. 至此，鏈接創建，Charles拿到了 服務器證書的公鑰 和 客戶端與服務器協商的對稱密鑰，以後就能夠解密或者修改加密的報文了

　　因此前提是客戶端須要選擇信任並安裝 Charles 的證書，不然抓包工具也沒法攔截 https，在互聯網上大部分惡意腳本程序，想要抓取用戶數據，也大都是和抓包工具同樣的工做原理，因此 https 仍是比較安全的。

未使用 https ？

　　記得之前公司還沒使用 https 的時候，可能你們都經歷過噁心的流量劫持，咱們本身在線上環境使用都挺正常的，時不時其餘地區的同事會告訴咱們說，頁面上漂浮了一個按鈕，點開就跑到其餘地方去了。 甚至說有些注入的代碼有問題，致使咱們的界面也出現了問題，當時各類研究後，最後的辦法就是上 https， 到如今就不再用擔憂這個問題了。 如今一些瀏覽器訪問非 https 的頁面，都會提示不安全，平時也看獲得一些他人的網站都仍是沒用 https，進去就會報警告。 也如咱們發現的重放攻擊，這些安全問題確實存在於網絡中，甚至無人能避免，因此沒用 https 的站點，仍是快點升級吧！

關注大詩人公衆號，第一時間獲取最新文章。