01?漏洞描述

HTTP的無狀態(tài)性滤馍，導(dǎo)致Web應(yīng)用程序必須使用會(huì)話機(jī)制來識(shí)別用戶。一旦與Web站點(diǎn)建立連接(訪問配乓、登錄)仿滔，用戶通常會(huì)分配到一個(gè)Cookie，隨后的請(qǐng)求犹芹，都會(huì)帶上這個(gè)Cookie崎页，這樣Web站點(diǎn)就很容易分辨請(qǐng)求來自哪個(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í)行非意愿的操作。

02?漏洞檢測(cè)

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)求的來源，如果請(qǐng)求頭中沒有referer字段洁奈，或者刪掉請(qǐng)求頭中的referer字段间唉，均響應(yīng)成功，那么服務(wù)器就沒有校驗(yàn)請(qǐng)求來源利术，存在“跨站”呈野。

首先正常提交請(qǐng)求包，發(fā)現(xiàn)轉(zhuǎn)賬成功印叁。

我們可以看到請(qǐng)求頭中有個(gè)Referer字段被冒，其中的值表示我們是從哪個(gè)頁面請(qǐng)求過來的。我們?cè)囍鴮eferer字段刪除并再次提交喉钢，查看賬戶余額有沒有變化姆打。

發(fā)現(xiàn)賬戶余額從990變成980，說明服務(wù)器并沒有驗(yàn)證請(qǐng)求來源肠虽，可以“跨站”。

是否可偽造請(qǐng)求

偽造請(qǐng)求的前提是玛追，我們知道如何去偽造請(qǐng)求中的參數(shù)和值税课，也就是說我們知道請(qǐng)求中包含哪些參數(shù)，知道參數(shù)的準(zhǔn)確值或者范圍痊剖。因此韩玩，檢測(cè)是否可偽造請(qǐng)求，只需要查看請(qǐng)求中是否有我們無法偽造的參數(shù)和值即可陆馁。

可以看到找颓，請(qǐng)求中有4個(gè)參數(shù)，account表示賬號(hào)叮贩，amount表示轉(zhuǎn)賬金額击狮，這兩個(gè)很好偽造，action表示執(zhí)行的動(dòng)作益老，不需要偽造彪蓬，直接使用即可。token是什么東西捺萌？(Token令牌了解一下)

token參數(shù)的值這么長(zhǎng)档冬，一看就知道不好偽造。那刪掉token試試，萬一和referer字段一樣酷誓，服務(wù)器沒有對(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)賬戶余額依然保持不變琐旁，說明服務(wù)器對(duì)Token做了校驗(yàn)涮阔，請(qǐng)求中不能缺失token或token錯(cuò)誤。

正打算放棄的時(shí)候灰殴，無聊的重放著原始請(qǐng)求包敬特，突然發(fā)現(xiàn)賬戶余額變成了900。

WTF牺陶，同一個(gè)token值好像可以反復(fù)使用伟阔，均能通過校驗(yàn)，難道這token是永久的掰伸？后來發(fā)現(xiàn)只要不退出重新登錄皱炉，token會(huì)一直有效，了解了狮鸭，這叫“韓式半永久”合搅。

驗(yàn)證CSRF

既能“跨站”，又能偽造請(qǐng)求歧蕉，那CSRF的驗(yàn)證就很簡(jiǎn)單了灾部。重新抓包，利用抓包工具生成CSRF的POC惯退。

復(fù)制其中的HTML代碼赌髓，在本地新建一個(gè)HTML頁面，將復(fù)制的代碼保存其中催跪，然后在同一個(gè)瀏覽器中打開(不懂的請(qǐng)gun去學(xué)習(xí)Cookie方面的知識(shí))锁蠕。

點(diǎn)擊CSRF頁面中的按鈕，發(fā)現(xiàn)會(huì)跳轉(zhuǎn)到轉(zhuǎn)賬頁面叠荠，且賬戶余額只有400匿沛，少了500。?

CSRF的檢測(cè)到此圓滿結(jié)束榛鼎。至于CSRF的利用逃呼，簡(jiǎn)單說兩句鳖孤，可以構(gòu)造一個(gè)鏈接(GET)、隱藏的表單(POST)抡笼、圖片等苏揣，然后想方設(shè)法讓用戶點(diǎn)擊或訪問就可以了。??

03?漏洞修復(fù)

請(qǐng)求來源驗(yàn)證推姻；HTTP請(qǐng)求頭中有個(gè)referer字段平匈，該字段記錄了當(dāng)前HTTP請(qǐng)求的來源〔毓牛可以通過檢查請(qǐng)求是否來自站外增炭，來防御站外發(fā)起的CSRF，但不能防御從站內(nèi)發(fā)起的CSRF拧晕，且存在被繞過的風(fēng)險(xiǎn)隙姿。

Token驗(yàn)證；在請(qǐng)求中添加攻擊者無法預(yù)測(cè)的Token令牌厂捞，當(dāng)請(qǐng)求中缺失Token或Token值不對(duì)時(shí)输玷，則拒絕請(qǐng)求。請(qǐng)使用一次性的Token靡馁，而且記得及時(shí)更新欲鹏，不然還是可以繞過。(這種情況工作中已經(jīng)遇到過無數(shù)次了)

使用圖形驗(yàn)證碼臭墨，但可能會(huì)影響用戶體驗(yàn)赔嚎。

04?PS

我這里舉了一個(gè)既包含referer又包含token的例子，為了讓大家更好的理解CSRF的檢測(cè)胧弛，排版可能會(huì)與實(shí)際情況有些出入尽狠。實(shí)際工作中，我個(gè)人習(xí)慣先多次重放叶圃，看token是否可重復(fù)使用，如果可重復(fù)使用践图，自然不用修改token值或刪除掺冠，只需要檢測(cè)是否可“跨站”即可；如果不能重復(fù)使用码党，說明會(huì)校驗(yàn)token值德崭，那么就不必修改token值，只需直接刪除token試試揖盘，最后再測(cè)試是否可“跨站”眉厨。而且在實(shí)際利用中，token值的獲取沒有這么簡(jiǎn)單兽狭。只是在檢測(cè)過程中憾股，我們發(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è)人覺得我的校友們應(yīng)該能看懂，如果實(shí)在是忙于做菜和開挖掘機(jī)粉渠，沒時(shí)間看懂分冈，可以在公眾號(hào)里留言，有時(shí)間我就會(huì)回復(fù)霸株。新開的公眾號(hào)雕沉，文章底部暫不支持留言，這個(gè)有點(diǎn)頭疼淳衙。每日漏洞系列需要校友們有一定基礎(chǔ)蘑秽，定位也是定在如何檢測(cè)，所以理論的東西不會(huì)介紹太多箫攀，校友們平時(shí)可以適當(dāng)補(bǔ)充理論知識(shí)肠牲，這樣更容易消化每日漏洞的內(nèi)容。