DVWA之跨站请求伪造(CSRF)

CSRF全称是Cross site request forgery ,翻译过来就是跨站请求伪造。

CSRF是指利用受害者尚未失效的身份认证信息(cookie,会话信息),诱骗其点击恶意链接或者访问包含攻击代码的页面,

在受害人不知情的情况下,以受害人的身份向(身份信息所对应的)服务器发送请求,从而完成非法操作,比如转账,改密码。

CSRF和XSS攻击的区别

CSRF没有盗取用户的cookie信息,而是直接利用用户cookie;相比之下,XSS是盗取用户的cookie信息。

Low级别

首先我用burp suite抓了一下这个改密码的数据包提交的参数有哪些。

http://www.dvwa.com/vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change

可以发现,这个改密码的接口直接使用GET方法传参。我们在另一个网站(www.a.com)。伪造一个网页在网页中嵌入恶意链接。网页代码

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>恶意修改密码</title>
</head>
<body>
    <h1>当你打开这个网页的时候,你在DVWA网站的密码可能已经修改了</h1>
    <img src=" http://www.dvwa.com/vulnerabilities/csrf/?password_new=hack&password_conf=hack&Change=Change"/>
</body>
</html>

关闭DVWA的标签页后访问,www.a.com站点

之后,打开DVWA的网站,退出登录(按照理论上讲,修改密码的接口应该清除之前的session会话,等待新密码重新建立会话,但是这里并没有)

重新使用之前的密码登陆,已经无法登陆

使用hack这个密码可以正常登陆。

分析一下,这个链接太过明显了,如果是我不小心打开了这个页面,我的密码被改了,那么很简单,我看一下这个网页的源码,

发现原来密码是hack,我再改回来不就行了,其实不是这样的,真正的CSRF攻击不会有这么明显的纰漏,可以伪造这个链接。

我这里的长链是本地的,所以无法生成在线的短链。

大家可以使用上边的短网址生成工具。将链接伪造一下。实测一下。百度》输入关键字》百度云盘》回车》cp长链》生成新浪短网址

访问新浪短网址,这个短链的效果和长链是一样的。

这样的话,就很难定位是哪个假链接修改了密码。

medium级别

在这个级别中检查了保留变量HTTP_REFERER(来源地址)中是否包含SERVER_NAME(包括HOST参数和访问的主机名)。

我抓了一下此级别下正常修改密码的报文和伪造的修改的密码报文做比较

正常的修改密码的数据包。

伪造的修改密码的数据包。

通过比较这俩个数据包,明显的referer不一样,Cookie信息也一样,由此可见,如果不检查referer这个信息,就会被当成合法的操作。

int eregi(string pattern, string string)

大家首先了解一下这个PHP函数,这个函数使用了匹配字符串的,如果在string这个字符中出现了字符串pattern,则返回true,否则返回false。

在这个级别中,就是通过这个函数检查cookie的。所以,我们只需要在我们的主机名中伪造这样一个字符串就可以了。

我在伪造网站上建立一个目录,并将我们伪造的网页放进去。

现在我的伪造的网页地址是

www.a.com/httpwww.dvwa.comvulnerabilitiescsrf/index.html

密码被成功修改(这里就不截图了,大家可以自行测试)

High级别

在High级别中加入了Anti-CSRF token验证机制,用户每次访问一个页面,都会返回一个随机的token,向服务器提交修改密码请求需要提交token,

服务器收到请求会优先检测token,token通过才会执行修改密码。

要想在这一步中成功修改密码需要拿到用户的token,

按照正常的思路应该是,伪造一个页面,诱骗用户打开这个页面,在这个页面偷偷加载一个iframe到修改密码的页面,然后获取这个页面的token,然后执行修改密码的操作。

但其实这个涉及另一个问题,iframe属于跨域操作,所以这个页面没有权限获取iframe框架中的token。除非是iframe中主动发送token出来。

这种情况下只能使用别的方法了,查看其它页面的是否存在XSS注入,通过注入的XSS恶意代码,获取token之后再执行修改密码的操作(XSRF攻击)

impossible级别

修改密码需要提供原密码,在不知道原密码的情况下就放弃吧。

原文地址:https://www.cnblogs.com/smallsima/p/8799033.html

时间: 2024-08-30 09:57:02

DVWA之跨站请求伪造(CSRF)的相关文章

跨站请求伪造CSRF原理

跨站请求伪造CSRF原理 CSRF是Cross Site Request Forgery的缩写,CSRF是伪造成合法用户发起请求 先了解下session: 用户登录时服务器端生成一个Session 返回给用户session_id在cookie中 用户下次登录带着有session_id的cookie登录 跨站请求伪造例子 只有session的话,如果有一个网站可以访问所有的cookie,那么就会获取到所有的session,然后带着你的session去访问别的网站. 比如:在一些诱骗性的网站上,可以

跨站请求伪造CSRF(Cross-site request forgery)

CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用 一般被攻击步骤: 1.登录受信任网站A,并在本地生成Cookie. 2.在不登出A的情况下,访问危险网站B. 所以没事的时候不要乱点链接不是随便说着玩的. 常见场景分析: 假设你有一个这样的Action,因为已经加了[Authorize(Roles = "Admins")]标记

跨站请求伪造 CSRF / XSRF&lt;一:介绍&gt;

跨站请求伪造(英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法. ***跟跨网站脚本(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任. 攻击的细节 跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执

跨站请求伪造(csrf)

跨站请求伪造(csrf) 钓鱼网站 ? 就类似于你搭建了一个跟银行一模一样的web页面 ? 用户在你的网站转账的时候输入用户名 密码 对方账户 ? 银行里面的钱确实少了 但是发现收款人变了 最简单的原理 你写的form表单中 用户的用户名 密码都会真实的提交给银行后台 但是收款人的账户却不是用户填的 你暴露给用户的是一个没有name属性的input框 你自己提前写好了一个隐藏的带有name和value的input框 真正的网站 前端 <h1>真正的网站</h1> <form

跨站请求伪造CSRF

CSRF是Cross Site Request Forgery的缩写,乍一看和XSS差不多的样子,但是其原理正好相反,XSS是利用合法用户获取其信息,而CSRF是伪造成合法用户发起请求. 在XSS危害--session劫持中我们提到了session原理,用户登录后会把登录信息存放在服务器,客户端有一个用户标识存在cookie中,只要用户不关闭浏览器或者退出登录,在其有效期内服务器就会把这个浏览器发送的请求当作当前客户,如果这时候用户被欺骗,使用浏览器打开了某些恶意网址,里面就会包含一些不是用户希

跨站请求伪造(CSRF攻击)理解

一  概念 你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求.CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全. 二  过程 1  受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到

跨站请求伪造 CSRF / XSRF&lt;二:应用&gt;

防御的方法主要有两种<java示例> 1.检查Referer字段 HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址.在处理敏感数据请求时,通常来说,Referer字段应和请求的地址位于同一域名下.以上文银行操作为例,Referer字段地址通常应该是转账按钮所在的网页地址,应该也位于www.examplebank.com之下.而如果是CSRF攻击传来的请求,Referer字段会是包含恶意网址的地址,不会位于www.examplebank.com之下,这时候服务器就能识别出

防止跨站请求伪造(CSRF)攻击 和 防重复提交 的方法的实现

CSRF的概率可以参考:http://netsecurity.51cto.com/art/200812/102951.htm 本文介绍的是基于spring拦截器的Spring MVC实现 首先配置拦截器: <mvc:interceptors> <mvc:interceptor> <!-- 匹配的是url路径, 如果不配置或/**,将拦截所有的Controller --> <mvc:mapping path="/xxx/**" /> <

第十篇:跨站请求伪造csrf

钓鱼网站 钓鱼网站和正规网站的页面一模一样,提交网页数据的url也一样,但是会在页面中设置隐藏属性的form表单.例如转账:给用户书写的form表单,对方账号的input没有name属性,然后另外写一个具有默认的并且是隐藏的具有name属性的input框. form表单如何通过csrf校验 为了防止此类事情的发生,我们使用csrf_token生成随机字符串 在form表单内添加: {% csrf_token %} browser客户端向服务端发动get请求,服务端返回给browser一串随机的字