返回介绍
文江博客 开发文档 Bug Bounty Bootcamp 中文版 文章详情

Mechanisms

发布于 2024-10-11 20:33:58 字数 10351 浏览 0 评论 0 收藏 0

Remember from Chapter 3 that most modern web applications authenticate their users and manage user sessions by using session cookies. When you first log in to a website, the web server establishes a new session: it sends your browser a session cookie associated with the session, and this cookie proves your identity to the server. Your browser stores the session cookies associated with that website and sends them along with every subsequent request you send to the site. This all happens automatically, without the user’s involvement.

大多数现代 Web 应用程序使用会话 cookie 对其用户进行认证和管理用户会话。当您首次登录网站时，Web 服务器会建立一个新会话：它向您的浏览器发送与该会话相关联的会话 cookie，并且该 cookie 可以向服务器证明您的身份。您的浏览器存储与该网站关联的会话 cookie，并将它们与您发送到该网站的每个后续请求一起发送。这一切都是自动完成的，无需用户介入。

For example, when you log into Twitter, the Twitter server sends your browser the session cookie via an HTTP response header called Set-Cookie :

例如，当您登录 Twitter 时，Twitter 服务器通过称为 Set-Cookie 的 HTTP 响应标头向您的浏览器发送会话 cookie。

Set-Cookie: session_cookie= YOUR_TWITTER_SESSION_COOKIE ;

Your browser receives the session cookie, stores it, and sends it along via the Cookie HTTP request header in every one of your requests to Twitter. This is how the server knows your requests are legit:

你的浏览器接收会话 cookie，并将其存储。在向 Twitter 发送的请求中，它通过 Cookie HTTP 请求标头将其发送。这就是服务器如何知道您的请求是合法的。

Cookie: session_cookie= YOUR_TWITTER_SESSION_COOKIE ;

Armed with your session cookie, you can carry out authenticated actions like accessing confidential information, changing your password, or sending a private message without reentering your password. To get ahold of your own session cookies, intercept the requests your browsers send to the site after you’ve logged in.

使用您的会话 cookie，您可以执行身份验证操作，如访问机密信息、更改密码或发送私信，而无需重新输入密码。要获取自己的会话 cookie，请拦截浏览器在登录后发送到网站的请求。

Now let’s say there’s a Send a Tweet HTML form on Twitter’s web page. Users can enter their tweets by using this form and clicking the Submit button to send them ( Figure 9-1 ).

现在假设 Twitter 网页上有一个“发送推文”的 HTML 表单。用户可以使用该表单输入他们的推文，并点击提交按钮发送它们（图 9-1）。

f09001

Figure 9-1 : An example HTML form that allows users to send a tweet

图 9-1：一个允许用户发送推文的 HTML 表单的示例

Note that Twitter doesn’t really use this form (and Twitter’s actual Send a Tweet functionality isn’t vulnerable to CSRF attacks). The source code of the example HTML form looks like this:

请注意，Twitter 实际上并不使用这种形式（且 Twitter 的“发送推文”功能不易受到 CSRF 攻击）。示例 HTML 表单的源代码如下：

<html>
1 <h1>Send a tweet.</h1>
2 <form method="POST" action="https://twitter.com/send_a_tweet">
  3 <input type="text" name="tweet_content" value="Hello world!">
  4 <input type="submit" value="Submit">
  </form>
</html>

The <h1> tags denote a first-level HTML heading 1 , whereas the <form> tags define the beginning and end of an HTML form 2 . The form has the method attribute POST and the action attribute https://twitter.com/send_a_tweet . This means that the form will submit a POST request to the https://twitter.com/send_a_tweet endpoint when the user clicks Submit. Next, an <input> tag defines a text input with the default value of Hello world! . When the form is submitted, any user input in this field will be sent as a POST parameter named tweet_content 3 . A second input tag defines the Submit button 4 . When users click this button, the form will be submitted.

<h1>标签代表 HTML 一级标题 1，而<form>标签定义了 HTML 表单 2 的开头和结尾。 表单具有方法属性 POST 和动作属性 https://twitter.com/send_a_tweet。这意味着当用户单击提交时，表单将向 https://twitter.com/send_a_tweet 端点提交 POST 请求。接下来，<input>标签定义了一个带有默认值 Hello world！的文本输入。当表单被提交时，用户在该字段中的任何用户输入都将作为 POST 参数 tweet_content 3 发送。第二个输入标签定义了提交按钮 4。当用户单击此按钮时，表单将被提交。

When you click the Submit button on the page, your browser will send a POST request to https://twitter.com/send_a_tweet . The browser will include your Twitter session cookie with the request. You could see the request generated by the form in your proxy. It should look something like this:

当您在页面上点击提交按钮时，您的浏览器将向 https://twitter.com/send_a_tweet 发送一个 POST 请求。浏览器将在请求中包含您的 Twitter 会话 cookie。您可以在代理中查看表单生成的请求。它应该类似于这样：

POST /send_a_tweet
Host: twitter.com
Cookie: session_cookie= YOUR_TWITTER_SESSION_COOKIE 

(POST request body)
tweet_content="Hello world!"

This functionality has a vulnerability: any site, and not just Twitter, can initiate this request. Imagine that an attacker hosts their own website that displays an HTML form like Figure 9-2 .

这个功能存在漏洞：任何网站，而不仅仅是 Twitter，都可以发起这个请求。想象一下，一个攻击者托管了自己的网站，显示一个类似于图 9-2 的 HTML 表单。

f09002

Figure 9-2 : An example HTML form that an attacker uses to exploit a CSRF vulnerability

图 9-2：攻击者利用 CSRF 漏洞实施攻击的一个 HTML 表单示例。

The page’s source code is the following:

页面的源代码如下：

<html>
  <h1>Please click Submit.</h1>
  <form method="POST" action="https://twitter.com/send_a_tweet" id="csrf-form">
    <input type="text" name="tweet_content" value="Follow @vickieli7 on Twitter!">
    <input type='submit' value="Submit">
  </form>
</html>

When you click the Submit button on this page, your browser will send a POST request. Because the browser automatically includes your Twitter session cookies in requests to Twitter, Twitter will treat the request as valid, causing your account to tweet Follow @vickieli7 on Twitter! Here’s the corresponding request:

当您在此页面上单击“提交”按钮后，您的浏览器将发送一个 POST 请求。由于浏览器会自动将您的 Twitter 会话 cookie 包含在对 Twitter 的请求中，Twitter 会将该请求视为有效，导致您的帐户发布推文“在 Twitter 上关注 @vickieli7！这是相应的请求：”

POST /send_a_tweet
Host: twitter.com
Cookie: session_cookie= YOUR_TWITTER_SESSION_COOKIE 

(POST request body)
tweet_content="Follow @vickieli7 on Twitter!"

Even though this request doesn’t come from Twitter, Twitter will recognize it as valid because it includes your real Twitter session cookie. This attack would make you send the tweet every time you click Submit on the malicious page.

即使此请求并非来自 Twitter，Twitter 仍会将其视为有效，因为它包含您的真实 Twitter 会话 cookie。这种攻击将使您每次单击恶意页面上的提交按钮时都发送推文。

It’s true that this attack page isn’t very useful: it requires the victim to click a button, which most users probably won’t do. How can attackers make the exploit more reliable? Realistically, a malicious CSRF page would look more like this:

这个攻击页面实际上并不是很有效：它需要受害者点击一个按钮，而大多数用户可能不会这么做。攻击者如何能够使攻击更加可靠？实际上，一个恶意的 CSRF 页面会看起来更像这样：

<html>
      <iframe style="display:none" name="csrf-frame">  1
    <form method="POST" action="https://twitter.com/send_a_tweet" 
    target="csrf-frame" id="csrf-form"> 2
      <input type="text" name="tweet_content" value="Follow @vickieli7 on Twitter!">
      <input type='submit' value="Submit">
    </form>
      </iframe> 
  
      <script>document.getElementById("csrf-form").submit();</script>  3
</html>

This HTML places the form in an invisible iframe to hide it from the user’s view. Remember from Chapter 8 that an iframe is an HTML element that embeds another document within the current HTML document. This particular iframe’s style is set to display:none , meaning it won’t be displayed on the page, making the form invisible 1 . Then, JavaScript code between the script tags 3 will submit the form with the ID csrf-form 2 without the need for user interaction. The code fetches the HTML form by referring to it by its ID, csrf-form . Then the code submits the form by calling the submit() method on it. With this new attack page, any victim who visits the malicious site will be forced to tweet.

这个 HTML 代码将表单嵌入一个不可见的 iframe 中，以隐藏它，不让用户看到。你可能还记得第 8 章讲到过，iframe 是一种 HTML 元素，用于在当前 HTML 文档中嵌入另一个文档。这个特定的 iframe 样式设置为 display:none，意味着它不会在页面上显示，使得表单不可见。然后，script 标签之间的 JavaScript 代码将在不需要用户交互的情况下提交 ID 为 csrf-form 的表单。代码通过引用 ID csrf-form 来获取 HTML 表单，然后通过调用 submit() 方法提交表单。有了这个新的攻击页面，任何访问恶意网站的受害者都将被迫发推文。

What attackers can actually accomplish with a real CSRF vulnerability depends on where the vulnerability is found. For example, let’s say a request that empties a user’s online shopping cart has a CSRF vulnerability. When exploited in the wild, this vulnerability can at most cause annoyance to the site users. It doesn’t have the potential to cause any major financial harm or identity theft.

攻击者能利用真实的 CSRF 漏洞实际上取决于漏洞的位置。例如，假设清空用户在线购物车的请求存在 CSRF 漏洞。当在野外利用此漏洞时，它最多只能对网站用户造成烦恼，没有潜在的造成任何重大的财务损失或身份盗窃。

On the other hand, some CSRFs can lead to much bigger issues. If a CSRF vulnerability is present on requests used to change a user’s password, for example, an attacker can change other users’ passwords against their will and take over their entire accounts! And when a CSRF appears in functionalities that handle user finances, like account balance transfers, attackers can potentially cause unauthorized balance transfers out of the victim’s bank account. You can also use CSRFs to trigger injection vulnerabilities such as XSS and command injections.

另一方面，有些 CSRF 可能会导致更大的问题。例如，如果请求中存在 CSRF 漏洞用于更改用户密码，攻击者可以未经其同意更改其他用户的密码并接管其整个帐户！而当 CSRF 出现在处理用户财务的功能中，例如帐户余额转账时，攻击者可能会导致未经授权的余额转账从受害者的银行账户中进行。您还可以使用 CSRF 触发 XSS 和命令注入等注入漏洞。

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。
列表为空，暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文