在本节中，将解释什么是跨站请求伪造（CSRF），描述一些常见的CSRF漏洞示例，并解释如何防止CSRF攻击。
什么是CSRF？
跨站请求伪造（也称为CSRF）是一种Web安全漏洞，允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者部分规避同源策略，该策略旨在防止不同网站相互干扰。
CSRF攻击的影响是什么？
在成功的CSRF攻击中，攻击者会导致受害者用户无意中执行某项操作。
例如，这可能是更改其账户上的电子邮件地址、更改密码或进行资金转账。根据操作的性质，攻击者可能能够完全控制用户的账户。如果受感染的用户在应用程序中拥有特权角色，那么攻击者可能能够完全控制应用程序的所有数据和功能。
CSRF是如何工作的？
要使CSRF攻击成为可能，必须具备三个关键条件：
●一个相关的动作
应用程序中存在攻击者有理由诱导的操作，这可能是特权操作（例如修改其他用户的权限）或对用户特定数据的任何操作（例如更改用户自己的密码）。
●基于Cookie的会话处理
执行该操作涉及发出一个或多个HTTP请求，并且应用程序仅依赖会话cookie来识别发出请求的用户，没有其他机制可用于跟踪会话或验证用户请求。
●没有不可预测的请求参数
执行该操作的请求不包含攻击者无法确定或猜测其值的任何参数。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，则该功能不会受到攻击。
例如，假设一个应用程序包含一个允许用户更改其账户上电子邮件地址的功能，当用户执行操作时，他们会发出如下HTTP请求：
这符合CSRF所需的条件：
●攻击者对更改用户账户上电子邮件地址的操作很感兴趣。执行此操作后，攻击者通常能够触发密码重置并完全控制用户的账户。
●应用程序使用会话cookie来识别发出请求的用户，没有其他令牌或机制来跟踪用户会话。
●攻击者可以轻松确定执行操作所需请求参数的值。
有了这些条件，攻击者就可以构建一个包含以下HTML的网页：
如果受害者用户访问攻击者的网页，将会发生以下情况：
●攻击者的页面将触发对易受攻击网站的HTTP请求。
●如果用户登录到易受攻击的网站，他们的浏览器将自动在请求中包含他们的会话cookie（假设未使用SameSite Cookie）
●易受攻击的网站将以正常方式处理请求，将其视为由受害者用户发出，并更改其电子邮件地址。
尽管CSRF通常被描述为与基于cookie的会话处理相关，但它也出现在应用程序自动将一些用户凭据添加到请求的其他环境中，例如HTTP基本身份验证和基于证书的身份验证。
XSS和CSRF有什么区别？
XSS允许攻击者在受害者用户的浏览器中执行任意JavaScript。
CSRF允许攻击者诱使受害者用户执行他们不打算执行的操作。
通常来说，XSS漏洞的后果比CSRF更严重：
●CSRF通常仅适用于用户能够执行的操作子集。许多应用程序通常会实施CSRF防御，但会忽略一两个暴露的操作。相反，成功的XSS漏洞利用通常可以诱使用户执行用户能够执行的任何操作，而不管出现漏洞的功能如何。
●CSRF可以被描述为“单向”漏洞，虽然攻击者可以诱导受害者发出HTTP请求，但他们无法从该请求中检索响应。相反，XSS是“双向”的，攻击者注入的脚本可以发出任意请求、读取响应并将数据泄漏到攻击者选择的外部域。
CSRF令牌可以防止XSS攻击吗？
通过有效使用CSRF令牌，确实可以防止一些XSS攻击，假设服务器正确验证了CSRF令牌，并拒绝了没有有效令牌的请求，那么该令牌确实阻止了XSS漏洞的利用。
但这里有几点要注意：
●如果反射型XSS漏洞存在于站点上不受CSRF令牌保护的函数内的任何其他位置，则可以以正常方式利用该XSS。
●如果站点上的任何地方都存在可利用的XSS漏洞，则可以利用该漏洞使受害用户执行操作，即使这些操作本身受CSRF令牌保护。在这种情况下，攻击者的脚本可以请求相关页面获取有效的CSRF令牌，然后使用该令牌执行受保护的操作。
●CSRF令牌不能防止存储型XSS漏洞，如果一个受CSRF令牌保护的页面也是存储型XSS漏洞的输出点，那么该XSS漏洞可以以通常的方式被利用，并且XSS的Payload将在用户访问该页面时执行。
如何防止CSRF攻击？
防御CSRF攻击最可靠的方法是在相关请求中包含CSRF令牌。
令牌应该可以做到：
●对于一般的会话令牌，高随机性是不可预测的。
●绑定到用户的会话。
●在执行相关操作之前，在每种情况下都经过严格验证。
什么是CSRF令牌？
CSRF令牌是唯一的、秘密的、不可预测的值，由服务器端应用程序生成并以包含在客户端发出的后续HTTP请求中的方式传输到客户端。
当发出后面的请求时，服务器端应用程序验证请求是否包含预期的令牌，如果令牌丢失或无效，则拒绝请求。
CSRF令牌可以防止CSRF攻击，因为攻击者无法构建提供受害者用户完全有效的HTTP请求，由于攻击者无法确定或预测用户CSRF令牌的值，因此他们无法使用应用程序履行请求所需的所有参数构造请求。
CSRF令牌如何生成？
CSRF令牌应该包含明显的随机性并且是高度不可预测的，具有与一般会话令牌相同的属性。
应该使用加密强度伪随机数生成器（PRNG），使用创建时的时间戳和静态密钥作为种子。
如果需要超过PRNG强度的进一步保证，可以通过将其输出与一些特定于用户的随机性连接起来生成单个令牌，并对整个结构进行强散列。这为试图根据样本分析令牌的攻击者提供了额外的障碍。
CSRF令牌如何传输？
CSRF令牌应被视为机密，并在其整个生命周期中以安全的方式进行处理。通常有效的方法是在使用POST方法提交的HTML表单的隐藏字段中将令牌传输到客户端。表单提交时，令牌将作为请求参数包含在内：
为了更加安全，包含CSRF令牌的字段应尽早放置在HTML文档中，最好是在任何非隐藏输入字段之前以及在HTML中嵌入用户可控数据的任何位置之前。这样可以缓解攻击者使用精心制作的数据来操纵HTML文档并捕获其部分内容的各种技术。
另一种方法，将令牌放入URL查询字符串不大安全，因为查询字符串有以下几个问题：
●在客户端和服务器端的不同位置登录
●有可能在HTTP Referer标头内传输给第三方
●可以在用户浏览器的屏幕上显示
一些应用程序在自定义请求标头中传输CSRF令牌，这为设法预测或捕获另一个用户令牌的攻击者提供了进一步的防御，因为浏览器通常不允许跨域发送自定义标头。但是，该方法将应用程序限制为使用XHR（而不是HTML表单）发出受CSRF保护的请求，并且在许多情况下可能被认为过于复杂。
CSRF令牌不应在cookie中传输。
CSRF令牌应该如何验证？
当生成CSRF令牌时，它应该存储在服务器端用户会话数据中。当接收到需要验证的后续请求时，服务器端应用程序应验证该请求是否包含与存储在用户会话中的值匹配的令牌。无论请求的HTTP方法或内容类型如何，都必须执行此验证。如果请求根本不包含任何令牌，则应该以与存在无效令牌时相同的方式拒绝它。
SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：跨站请求伪造（CSRF）-概念梳理
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论