当您处理网络服务（并且您需要使该 API 跨源工作）时，情况会有所不同。这里的关键防御是设计 API，以便：
凭证发送到不会自动发送的地方（例如，在授权标头中），以便攻击者无法使用它们发出请求。
该请求的格式需要发送 CORS 预检请求（例如，使用 Content-Type: application/json 请求标头）。
……或者两者兼而有之。
A traditional CSRF attack works by placing a pre-populated form on the the attacker's site and submitting it cross-origin. It then uses credentials that are automatically sent with the request to send the attacker's data under the guise of the browser owner's identity.
By putting a token in both the cookies (or session) and the form and checking to see if they match, you can defend against this. The attacker can't just send a request to get the CSRF token because:
If they get the user to make the request then the Same Origin Policy prevents them from reading the response with the token in it
If they make the request directly then they won't have the user's cookies so will get a different (non-matching) token
When you are dealing with a web service (and you need to make that API work across origins), things are different. The key defence here is to design the API so either:
The credentials go somewhere where they won't be sent automatically (e.g. in an Authorization header) so the attacker can't make the request with them.
The request is in a format where it requires a CORS preflight request to send (e.g. with a Content-Type: application/json request header).
发布评论
评论（1）
传统 CSRF 攻击的工作原理是在攻击者的站点上放置预先填充的表单并跨域提交。然后，它使用随请求自动发送的凭据，以浏览器所有者的身份为幌子发送攻击者的数据。
通过在 cookie（或会话）和表单中放入令牌并检查它们是否匹配，您可以防御这种情况。攻击者不能只是发送请求来获取 CSRF 令牌，因为：
当您处理网络服务（并且您需要使该 API 跨源工作）时，情况会有所不同。这里的关键防御是设计 API，以便：
Content-Type: application/json请求标头）。……或者两者兼而有之。
A traditional CSRF attack works by placing a pre-populated form on the the attacker's site and submitting it cross-origin. It then uses credentials that are automatically sent with the request to send the attacker's data under the guise of the browser owner's identity.
By putting a token in both the cookies (or session) and the form and checking to see if they match, you can defend against this. The attacker can't just send a request to get the CSRF token because:
When you are dealing with a web service (and you need to make that API work across origins), things are different. The key defence here is to design the API so either:
Content-Type: application/jsonrequest header).… or both.