.Referer就是上一個頁面的地址，這個是瀏覽器會在點擊一個鏈接時自動添加到請求頭中的

查看一個request信息頁面：

按F12調試工具可查看

2.referer的作用：

防止盜連，比如我是個下載軟件的網站，在下載頁面我先用referer來判斷上一頁面是不是自己網站，如果不是，說明有人盜連了你的下載地址

防盜鏈方法代碼：

3.通過設置referer不是安全的，在Java中獲取一個網站的HTML內容可以通過HttpURLConnection來獲取.我們在HttpURLConnection中可以設置referer來偽造referer,輕松繞過這類防采集的網站請看下面代碼：

4.設置user-agent讓服務器識別我們的身份,上面的例子中,我們就告訴瀏覽器我是用的maxthon遨游瀏覽器.通過設置useragent大部分的防采集的網站可以通過了,第二中比較嚴格的防采集的網站是通過請求頭的referer和cookie來判斷的.使用jetty的HttpClient的可以通過ContentExchange的addRequestHeader來設置請求頭代碼：

5.在 Java 中攔截器是由 Filter 來實現的。我們可以編寫一個 Filter，并在 web.xml 中對其進行配置，使其對于訪問所有需要 CSRF 保護的資源的請求進行攔截。 在 filter 中對請求的 Referer 驗證代碼如下 ：

6.在 filter 中驗證請求中的 toke代碼：

【IT科技之家-itkeji綜合 -文章版權聲明】

非特殊說明，本文版權歸 [ IT科技之家-itkeji綜合 -ITMFB] 所有，轉載請注明出處.

更多文章請關注：itkeji綜合

1 漏洞描述

HTTP的無狀態性，導致Web應用程序必須使用會話機制來識別用戶。一旦與Web站點建立連接(訪問、登錄)，用戶通常會分配到一個Cookie，隨后的請求，都會帶上這個Cookie，這樣Web站點就很容易分辨請求來自哪個用戶，該修改哪個用戶的數據。如果從第三方發起對當前站點的請求，該請求也會帶上當前站點的Cookie。正是這是這個缺陷，導致了CSRF的產生，利用這個漏洞可以劫持用戶執行非意愿的操作。

02 漏洞檢測

CSRF的利用場景常常是在用戶已登錄的情況下，偽造用戶意愿從站外發起請求。更深入剖析：請求能從站外發起(跨站)、請求的參數和值可以偽造(偽造請求)，因此，CSRF的檢測也是從這兩點入手。

以轉賬為例，輸入賬戶和金額，點擊Transfer即可完成轉賬。我們檢測該功能是否存在CSRF。

是否可跨站

要檢測是否可跨站，只需要操作請求頭中的referer字段即可。referer字段記錄了請求的來源，如果請求頭中沒有referer字段，或者刪掉請求頭中的referer字段，均響應成功，那么服務器就沒有校驗請求來源，存在“跨站”。

首先正常提交請求包，發現轉賬成功。

我們可以看到請求頭中有個Referer字段，其中的值表示我們是從哪個頁面請求過來的。我們試著將Referer字段刪除并再次提交，查看賬戶余額有沒有變化。

發現賬戶余額從990變成980，說明服務器并沒有驗證請求來源，可以“跨站”。

是否可偽造請求

偽造請求的前提是，我們知道如何去偽造請求中的參數和值，也就是說我們知道請求中包含哪些參數，知道參數的準確值或者范圍。因此，檢測是否可偽造請求，只需要查看請求中是否有我們無法偽造的參數和值即可。

可以看到，請求中有4個參數，account表示賬號，amount表示轉賬金額，這兩個很好偽造，action表示執行的動作，不需要偽造，直接使用即可。token是什么東西？(Token令牌了解一下)

token參數的值這么長，一看就知道不好偽造。那刪掉token試試，萬一和referer字段一樣，服務器沒有對token進行校驗呢。

反復重放了幾次請求，發現賬戶余額保持不變，很顯然，token參數必須有。那我們隨便改一下token的值，看請求中是不是只要有token參數就行了，但服務器并不會校驗token的值。

反復重放幾次，發現賬戶余額依然保持不變，說明服務器對Token做了校驗，請求中不能缺失token或token錯誤。

正打算放棄的時候，無聊的重放著原始請求包，突然發現賬戶余額變成了900。

WTF，同一個token值好像可以反復使用，均能通過校驗，難道這token是永久的？后來發現只要不退出重新登錄，token會一直有效，了解了，這叫“韓式半永久”。

驗證CSRF

既能“跨站”，又能偽造請求，那CSRF的驗證就很簡單了。重新抓包，利用抓包工具生成CSRF的POC。

復制其中的HTML代碼，在本地新建一個HTML頁面，將復制的代碼保存其中，然后在同一個瀏覽器中打開(不懂的請gun去學習Cookie方面的知識)。

點擊CSRF頁面中的按鈕，發現會跳轉到轉賬頁面，且賬戶余額只有400，少了500。

CSRF的檢測到此圓滿結束。至于CSRF的利用，簡單說兩句，可以構造一個鏈接(GET)、隱藏的表單(POST)、圖片等，然后想方設法讓用戶點擊或訪問就可以了。

03 漏洞修復

請求來源驗證；HTTP請求頭中有個referer字段，該字段記錄了當前HTTP請求的來源。可以通過檢查請求是否來自站外，來防御站外發起的CSRF，但不能防御從站內發起的CSRF，且存在被繞過的風險。

Token驗證；在請求中添加攻擊者無法預測的Token令牌，當請求中缺失Token或Token值不對時，則拒絕請求。請使用一次性的Token，而且記得及時更新，不然還是可以繞過。(這種情況工作中已經遇到過無數次了)

使用圖形驗證碼，但可能會影響用戶體驗。

04 PS

我這里舉了一個既包含referer又包含token的例子，為了讓大家更好的理解CSRF的檢測，排版可能會與實際情況有些出入。實際工作中，我個人習慣先多次重放，看token是否可重復使用，如果可重復使用，自然不用修改token值或刪除，只需要檢測是否可“跨站”即可；如果不能重復使用，說明會校驗token值，那么就不必修改token值，只需直接刪除token試試，最后再測試是否可“跨站”。而且在實際利用中，token值的獲取沒有這么簡單。只是在檢測過程中，我們發現token機制存在缺陷，那我們應該防患于未然，將風險降低到零。這里簡要解釋一下文章內容與實際工作中相出入的幾點。

文章風格，盡量簡單明了，再以幽默風趣的方式給大家介紹漏洞的檢測。個人覺得我的校友們應該能看懂，如果實在是忙于做菜和開挖掘機，沒時間看懂，可以在公眾號里留言，有時間我就會回復。新開的公眾號，文章底部暫不支持留言，這個有點頭疼。每日漏洞系列需要校友們有一定基礎，定位也是定在如何檢測，所以理論的東西不會介紹太多，校友們平時可以適當補充理論知識，這樣更容易消化每日漏洞的內容。