每日漏洞 | 跨站请求伪造

01 漏洞描述

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机制存在缺陷,那我们应该防患于未然,将风险降低到零。这里简要解释一下文章内容与实际工作中相出入的几点。

文章风格,尽量简单明了,再以幽默风趣的方式给大家介绍漏洞的检测。个人觉得我的校友们应该能看懂,如果实在是忙于做菜和开挖掘机,没时间看懂,可以在公众号里留言,有时间我就会回复。新开的公众号,文章底部暂不支持留言,这个有点头疼。每日漏洞系列需要校友们有一定基础,定位也是定在如何检测,所以理论的东西不会介绍太多,校友们平时可以适当补充理论知识,这样更容易消化每日漏洞的内容。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容