整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
之前在漏洞掃描中發(fā)現(xiàn)的漏洞，上網(wǎng)學(xué)習(xí)了一下如何在apache服務(wù)器中配置。雖然在華為云漏洞檢測(cè)中完美的解決了（小公司無(wú)測(cè)試，我們也不會(huì)測(cè)），把我的方式發(fā)出來(lái)。希望有明白的能看看指點(diǎn)一下。
SetEnvIfNoCase Referer "^http://localhost/" local_ref
<Location "/">
Order Allow,Deny
Allow from env=local_ref
</Location>
<Location "/index.html">
Order Allow,Deny
Allow from all
</Location>
<Location "/dp">
Order Allow,Deny
Allow from all
</Location>
<Location "/app">
Order Allow,Deny
Allow from all
</Location>
主要就是規(guī)定好允許訪問(wèn)的 Referer地址，如果地址不對(duì)則不可訪問(wèn)，地址正確也只可以訪問(wèn)到定好的入口。
在現(xiàn)有的測(cè)試工具中測(cè)試，華為云漏洞掃描是解決了bug，而且只能掃描到規(guī)定的入口。但是遇到更專業(yè)的工具是可以繞過(guò)的。
希望有更好辦法的hxd能指點(diǎn)指點(diǎn)
.Referer就是上一個(gè)頁(yè)面的地址，這個(gè)是瀏覽器會(huì)在點(diǎn)擊一個(gè)鏈接時(shí)自動(dòng)添加到請(qǐng)求頭中的
查看一個(gè)request信息頁(yè)面：
按F12調(diào)試工具可查看
2.referer的作用：
防止盜連，比如我是個(gè)下載軟件的網(wǎng)站，在下載頁(yè)面我先用referer來(lái)判斷上一頁(yè)面是不是自己網(wǎng)站，如果不是，說(shuō)明有人盜連了你的下載地址
防盜鏈方法代碼：
3.通過(guò)設(shè)置referer不是安全的，在Java中獲取一個(gè)網(wǎng)站的HTML內(nèi)容可以通過(guò)HttpURLConnection來(lái)獲取.我們?cè)贖ttpURLConnection中可以設(shè)置referer來(lái)偽造referer,輕松繞過(guò)這類防采集的網(wǎng)站請(qǐng)看下面代碼：
4.設(shè)置user-agent讓服務(wù)器識(shí)別我們的身份,上面的例子中,我們就告訴瀏覽器我是用的maxthon遨游瀏覽器.通過(guò)設(shè)置useragent大部分的防采集的網(wǎng)站可以通過(guò)了,第二中比較嚴(yán)格的防采集的網(wǎng)站是通過(guò)請(qǐng)求頭的referer和cookie來(lái)判斷的.使用jetty的HttpClient的可以通過(guò)ContentExchange的addRequestHeader來(lái)設(shè)置請(qǐng)求頭代碼：
5.在 Java 中攔截器是由 Filter 來(lái)實(shí)現(xiàn)的。我們可以編寫一個(gè) Filter，并在 web.xml 中對(duì)其進(jìn)行配置，使其對(duì)于訪問(wèn)所有需要 CSRF 保護(hù)的資源的請(qǐng)求進(jìn)行攔截。 在 filter 中對(duì)請(qǐng)求的 Referer 驗(yàn)證代碼如下 ：
6.在 filter 中驗(yàn)證請(qǐng)求中的 toke代碼：
【IT科技之家-itkeji綜合 -文章版權(quán)聲明】
非特殊說(shuō)明，本文版權(quán)歸 [ IT科技之家-itkeji綜合 -ITMFB] 所有，轉(zhuǎn)載請(qǐng)注明出處.
更多文章請(qǐng)關(guān)注：itkeji綜合
HTTP的無(wú)狀態(tài)性，導(dǎo)致Web應(yīng)用程序必須使用會(huì)話機(jī)制來(lái)識(shí)別用戶。一旦與Web站點(diǎn)建立連接(訪問(wèn)、登錄)，用戶通常會(huì)分配到一個(gè)Cookie，隨后的請(qǐng)求，都會(huì)帶上這個(gè)Cookie，這樣Web站點(diǎn)就很容易分辨請(qǐng)求來(lái)自哪個(gè)用戶，該修改哪個(gè)用戶的數(shù)據(jù)。如果從第三方發(fā)起對(duì)當(dāng)前站點(diǎn)的請(qǐng)求，該請(qǐng)求也會(huì)帶上當(dāng)前站點(diǎn)的Cookie。正是這是這個(gè)缺陷，導(dǎo)致了CSRF的產(chǎn)生，利用這個(gè)漏洞可以劫持用戶執(zhí)行非意愿的操作。
CSRF的利用場(chǎng)景常常是在用戶已登錄的情況下，偽造用戶意愿從站外發(fā)起請(qǐng)求。更深入剖析：請(qǐng)求能從站外發(fā)起(跨站)、請(qǐng)求的參數(shù)和值可以偽造(偽造請(qǐng)求)，因此，CSRF的檢測(cè)也是從這兩點(diǎn)入手。
以轉(zhuǎn)賬為例，輸入賬戶和金額，點(diǎn)擊Transfer即可完成轉(zhuǎn)賬。我們檢測(cè)該功能是否存在CSRF。
是否可跨站
要檢測(cè)是否可跨站，只需要操作請(qǐng)求頭中的referer字段即可。referer字段記錄了請(qǐng)求的來(lái)源，如果請(qǐng)求頭中沒(méi)有referer字段，或者刪掉請(qǐng)求頭中的referer字段，均響應(yīng)成功，那么服務(wù)器就沒(méi)有校驗(yàn)請(qǐng)求來(lái)源，存在“跨站”。
首先正常提交請(qǐng)求包，發(fā)現(xiàn)轉(zhuǎn)賬成功。
我們可以看到請(qǐng)求頭中有個(gè)Referer字段，其中的值表示我們是從哪個(gè)頁(yè)面請(qǐng)求過(guò)來(lái)的。我們?cè)囍鴮eferer字段刪除并再次提交，查看賬戶余額有沒(méi)有變化。
發(fā)現(xiàn)賬戶余額從990變成980，說(shuō)明服務(wù)器并沒(méi)有驗(yàn)證請(qǐng)求來(lái)源，可以“跨站”。
是否可偽造請(qǐng)求
偽造請(qǐng)求的前提是，我們知道如何去偽造請(qǐng)求中的參數(shù)和值，也就是說(shuō)我們知道請(qǐng)求中包含哪些參數(shù)，知道參數(shù)的準(zhǔn)確值或者范圍。因此，檢測(cè)是否可偽造請(qǐng)求，只需要查看請(qǐng)求中是否有我們無(wú)法偽造的參數(shù)和值即可。
可以看到，請(qǐng)求中有4個(gè)參數(shù)，account表示賬號(hào)，amount表示轉(zhuǎn)賬金額，這兩個(gè)很好偽造，action表示執(zhí)行的動(dòng)作，不需要偽造，直接使用即可。token是什么東西？(Token令牌了解一下)
token參數(shù)的值這么長(zhǎng)，一看就知道不好偽造。那刪掉token試試，萬(wàn)一和referer字段一樣，服務(wù)器沒(méi)有對(duì)token進(jìn)行校驗(yàn)?zāi)亍?/p>
反復(fù)重放了幾次請(qǐng)求，發(fā)現(xiàn)賬戶余額保持不變，很顯然，token參數(shù)必須有。那我們隨便改一下token的值，看請(qǐng)求中是不是只要有token參數(shù)就行了，但服務(wù)器并不會(huì)校驗(yàn)token的值。
反復(fù)重放幾次，發(fā)現(xiàn)賬戶余額依然保持不變，說(shuō)明服務(wù)器對(duì)Token做了校驗(yàn)，請(qǐng)求中不能缺失token或token錯(cuò)誤。
正打算放棄的時(shí)候，無(wú)聊的重放著原始請(qǐng)求包，突然發(fā)現(xiàn)賬戶余額變成了900。
WTF，同一個(gè)token值好像可以反復(fù)使用，均能通過(guò)校驗(yàn)，難道這token是永久的？后來(lái)發(fā)現(xiàn)只要不退出重新登錄，token會(huì)一直有效，了解了，這叫“韓式半永久”。
驗(yàn)證CSRF
既能“跨站”，又能偽造請(qǐng)求，那CSRF的驗(yàn)證就很簡(jiǎn)單了。重新抓包，利用抓包工具生成CSRF的POC。
復(fù)制其中的HTML代碼，在本地新建一個(gè)HTML頁(yè)面，將復(fù)制的代碼保存其中，然后在同一個(gè)瀏覽器中打開(kāi)(不懂的請(qǐng)gun去學(xué)習(xí)Cookie方面的知識(shí))。
點(diǎn)擊CSRF頁(yè)面中的按鈕，發(fā)現(xiàn)會(huì)跳轉(zhuǎn)到轉(zhuǎn)賬頁(yè)面，且賬戶余額只有400，少了500。
CSRF的檢測(cè)到此圓滿結(jié)束。至于CSRF的利用，簡(jiǎn)單說(shuō)兩句，可以構(gòu)造一個(gè)鏈接(GET)、隱藏的表單(POST)、圖片等，然后想方設(shè)法讓用戶點(diǎn)擊或訪問(wèn)就可以了。
請(qǐng)求來(lái)源驗(yàn)證；HTTP請(qǐng)求頭中有個(gè)referer字段，該字段記錄了當(dāng)前HTTP請(qǐng)求的來(lái)源。可以通過(guò)檢查請(qǐng)求是否來(lái)自站外，來(lái)防御站外發(fā)起的CSRF，但不能防御從站內(nèi)發(fā)起的CSRF，且存在被繞過(guò)的風(fēng)險(xiǎn)。
Token驗(yàn)證；在請(qǐng)求中添加攻擊者無(wú)法預(yù)測(cè)的Token令牌，當(dāng)請(qǐng)求中缺失Token或Token值不對(duì)時(shí)，則拒絕請(qǐng)求。請(qǐng)使用一次性的Token，而且記得及時(shí)更新，不然還是可以繞過(guò)。(這種情況工作中已經(jīng)遇到過(guò)無(wú)數(shù)次了)
使用圖形驗(yàn)證碼，但可能會(huì)影響用戶體驗(yàn)。
我這里舉了一個(gè)既包含referer又包含token的例子，為了讓大家更好的理解CSRF的檢測(cè)，排版可能會(huì)與實(shí)際情況有些出入。實(shí)際工作中，我個(gè)人習(xí)慣先多次重放，看token是否可重復(fù)使用，如果可重復(fù)使用，自然不用修改token值或刪除，只需要檢測(cè)是否可“跨站”即可；如果不能重復(fù)使用，說(shuō)明會(huì)校驗(yàn)token值，那么就不必修改token值，只需直接刪除token試試，最后再測(cè)試是否可“跨站”。而且在實(shí)際利用中，token值的獲取沒(méi)有這么簡(jiǎn)單。只是在檢測(cè)過(guò)程中，我們發(fā)現(xiàn)token機(jī)制存在缺陷，那我們應(yīng)該防患于未然，將風(fēng)險(xiǎn)降低到零。這里簡(jiǎn)要解釋一下文章內(nèi)容與實(shí)際工作中相出入的幾點(diǎn)。
文章風(fēng)格，盡量簡(jiǎn)單明了，再以幽默風(fēng)趣的方式給大家介紹漏洞的檢測(cè)。個(gè)人覺(jué)得我的校友們應(yīng)該能看懂，如果實(shí)在是忙于做菜和開(kāi)挖掘機(jī)，沒(méi)時(shí)間看懂，可以在公眾號(hào)里留言，有時(shí)間我就會(huì)回復(fù)。新開(kāi)的公眾號(hào)，文章底部暫不支持留言，這個(gè)有點(diǎn)頭疼。每日漏洞系列需要校友們有一定基礎(chǔ)，定位也是定在如何檢測(cè)，所以理論的東西不會(huì)介紹太多，校友們平時(shí)可以適當(dāng)補(bǔ)充理論知識(shí)，這樣更容易消化每日漏洞的內(nèi)容。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
