揭秘 CSRF？
Demystifying CSRF?
我通读了很多 long explanations of CSRF 和 IIUC，使攻击成为可能的核心是基于 cookie 的服务器会话识别。
所以换句话说，如果浏览器（请注意，我在这里专门将范围缩小到网络浏览器）不使用基于 cookie 的会话密钥来识别服务器上的会话，那么 CSRF 攻击就不会发生。我理解正确吗？
例如，假设有人创建了一个 link，例如：
href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=0">Read more!
您在登录 http://notsosecurebank.com 时被诱骗点击此 link，但是 http://notsosecurebank.com 不使用 cookie 来跟踪您的登录会话，因此 link不会造成任何伤害，因为请求无法通过身份验证，只会被扔进垃圾箱？
假设
- OpenID Connect 服务器/OAuth 授权服务器已正确实施，不会将身份验证重定向发送到您要求的任何 URL。
- 攻击者不知道客户端id和客户端密码
脚注
我在这个问题中针对的场景是最常被谈论的CSRF场景。还有其他符合CSRF标签的场景。这些情况极不可能发生，但最好注意并做好准备。 One of them 具有以下组成部分：
- 1) 攻击者能够将您引导至恶意客户端
- 2) 攻击者拥有该客户端
- 3) 攻击者拥有在 OAuth 授权服务器上注册的客户端的秘密
- 4) 攻击者能够在您通过正确的服务器进行身份验证后告诉对您进行身份验证的授权服务器重定向回不良客户端。
所以设置这个有点像闯入诺克斯堡，但一定要注意。例如，OpenID Connect 或 OAuth 授权提供程序最有可能标记注册重定向 URL 的客户端指向其他客户端也已注册的重定向 URL。
最常见/经常讨论的 CSRF Cross Site Request Forgery 场景只会在浏览器存储凭据（作为 cookie 或基本身份验证凭据）时发生。
OAuth2 实现（客户端和授权服务器）必须小心 CSRF 攻击。 CSRF 攻击可能发生在客户端的重定向 URI 和授权服务器上。根据 specification (RFC 6749):
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.
[...]
A CSRF attack against the authorization server's authorization
endpoint can result in an attacker obtaining end-user authorization
for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its
authorization endpoint and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of
the resource owner
理论上，CSRF 与身份验证方法无关。如果对手可以让受害者用户在另一个应用程序中执行受害者不想要的操作，那么该应用程序就容易受到 CSRF 的攻击。
这可以通过多种方式表现出来，最常见的是受害用户访问恶意网站，该网站反过来从受害者的浏览器向另一个应用程序发出请求，从而执行用户不想要的操作。这样，如果凭据是由受害者浏览器自动发送的，就有可能。到目前为止，最常见的情况是 session cookie，但也可以有其他情况，例如 HTTP Basic 身份验证（浏览器也会记住），或域中的 Windows 身份验证（Kerberos/SPNEGO)，或客户端证书，甚至在某些情况下是某种 SSO。
此外，有时应用程序身份验证是 cookie-based，并且所有 non-GET（POST、PUT 等）请求都受到 CSRF 保护，但 GET 不是出于显而易见的原因。在像 PHP 这样的语言中，很容易使旨在成为 POST 请求的调用也可以作为 GET（考虑在 PHP 中使用 $_REQUEST）。在这种情况下，任何其他网站都可以包含类似 <img src='http://victim.com/performstuff¶m=123> 的内容以静默执行操作。
在复杂的系统或流程中也存在不太明显的 CSRF 攻击，例如 CSRF attacks against oauth。
因此，如果 Web 应用程序使用 say 令牌（作为请求 headers 而不是 session cookie 发送）进行身份验证，这意味着客户端必须将令牌添加到每个请求，即可能不容易受到 CSRF 攻击，但一如既往，细节决定成败。
我通读了很多 long explanations of CSRF 和 IIUC，使攻击成为可能的核心是基于 cookie 的服务器会话识别。
所以换句话说，如果浏览器（请注意，我在这里专门将范围缩小到网络浏览器）不使用基于 cookie 的会话密钥来识别服务器上的会话，那么 CSRF 攻击就不会发生。我理解正确吗？
例如，假设有人创建了一个 link，例如：
href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=0">Read more!
您在登录 http://notsosecurebank.com 时被诱骗点击此 link，但是 http://notsosecurebank.com 不使用 cookie 来跟踪您的登录会话，因此 link不会造成任何伤害，因为请求无法通过身份验证，只会被扔进垃圾箱？
假设
- OpenID Connect 服务器/OAuth 授权服务器已正确实施，不会将身份验证重定向发送到您要求的任何 URL。
- 攻击者不知道客户端id和客户端密码
脚注
我在这个问题中针对的场景是最常被谈论的CSRF场景。还有其他符合CSRF标签的场景。这些情况极不可能发生，但最好注意并做好准备。 One of them 具有以下组成部分：
- 1) 攻击者能够将您引导至恶意客户端
- 2) 攻击者拥有该客户端
- 3) 攻击者拥有在 OAuth 授权服务器上注册的客户端的秘密
- 4) 攻击者能够在您通过正确的服务器进行身份验证后告诉对您进行身份验证的授权服务器重定向回不良客户端。
所以设置这个有点像闯入诺克斯堡，但一定要注意。例如，OpenID Connect 或 OAuth 授权提供程序最有可能标记注册重定向 URL 的客户端指向其他客户端也已注册的重定向 URL。
最常见/经常讨论的 CSRF Cross Site Request Forgery 场景只会在浏览器存储凭据（作为 cookie 或基本身份验证凭据）时发生。
OAuth2 实现（客户端和授权服务器）必须小心 CSRF 攻击。 CSRF 攻击可能发生在客户端的重定向 URI 和授权服务器上。根据 specification (RFC 6749):
A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g., a hash of the session cookie used to authenticate the user-agent). The client SHOULD utilize the "state" request parameter to deliver this value to the authorization server when making an authorization request.
[...]
A CSRF attack against the authorization server's authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its authorization endpoint and ensure that a malicious client cannot obtain authorization without the awareness and explicit consent of the resource owner
理论上，CSRF 与身份验证方法无关。如果对手可以让受害者用户在另一个应用程序中执行受害者不想要的操作，那么该应用程序就容易受到 CSRF 的攻击。
这可以通过多种方式表现出来，最常见的是受害用户访问恶意网站，该网站反过来从受害者的浏览器向另一个应用程序发出请求，从而执行用户不想要的操作。这样，如果凭据是由受害者浏览器自动发送的，就有可能。到目前为止，最常见的情况是 session cookie，但也可以有其他情况，例如 HTTP Basic 身份验证（浏览器也会记住），或域中的 Windows 身份验证（Kerberos/SPNEGO)，或客户端证书，甚至在某些情况下是某种 SSO。
此外，有时应用程序身份验证是 cookie-based，并且所有 non-GET（POST、PUT 等）请求都受到 CSRF 保护，但 GET 不是出于显而易见的原因。在像 PHP 这样的语言中，很容易使旨在成为 POST 请求的调用也可以作为 GET（考虑在 PHP 中使用 $_REQUEST）。在这种情况下，任何其他网站都可以包含类似 <img src='http://victim.com/performstuff¶m=123> 的内容以静默执行操作。
在复杂的系统或流程中也存在不太明显的 CSRF 攻击，例如 CSRF attacks against oauth。
因此，如果 Web 应用程序使用 say 令牌（作为请求 headers 而不是 session cookie 发送）进行身份验证，这意味着客户端必须将令牌添加到每个请求，即可能不容易受到 CSRF 攻击，但一如既往，细节决定成败。