REST 和 CSRF（跨站请求伪造）
针对无状态 RESTful 服务是否可以进行跨站点请求伪造？
我不是在谈论伪 REST，服务器会记住您是通过 cookie 登录的。我说的是没有 cookie 的纯服务器上无应用程序状态 REST。
我正在使用 SSL 和基本身份验证。对于每个请求，授权标头都必须存在。尽管在 SSL 级别上存在某种会话，但在 JSP 意义上并不存在“会话”。
因此，假设我正在查看发出 Ajax 请求的合法网页，并且不知何故我转到同一选项卡或不同选项卡中的不同页面，并且该页面发出相同的 Ajax 请求。 （我假设合法网页上没有恶意代码；这是完全不同的事情，在这种情况下一切皆有可能。）
当第二个页面发出 Ajax 请求时，浏览器是否会放置相同的授权标头？即浏览器会说“哦，你想再去那里吗？嘿，我只是碰巧还有钥匙！”？
另外，恶意脚本不能执行 xhr 请求，然后在回调中从 ioargs 获取请求，获取授权标头并对名称和密码进行 Un-Base64 处理吗？
Is Cross-Site Request Forgery possible against a stateless RESTful service?
I'm not talking about pseudo-REST where the server remembers that you're logged in via a cookie. I'm talking about pure no-application-state-on-the-server REST with no cookies.
I'm using SSL and Basic Authentication. For every request, that Authorization header has to be there. There is no "session" in the JSP sense, although there is some sort of session at the SSL level.
So let's assume I'm viewing the legitimate web page that makes Ajax requests, and somehow I go to a different page in the same tab or a different tab, and that page makes the same Ajax request. (I'm assuming there is no malicious code on the legitimate web page; that's a different thing entirely and anything is possible in that case.)
When the second page makes the Ajax request, will the browser put on the same Authorization header? i.e. will the browser say "Oh, you want to go THERE again? Hey, I just happen to still have the key!"?
Also, couldn't the malicious script do the xhr request, then in the callback take the request from the ioargs, get the Authorization header and un-Base64 the name and password?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
免责声明：我不是安全专家。
使用 HTTP 基本身份验证并不能防止通过 GET 请求进行 CSRF 攻击。例如，其他人可以在他们的 HTML 页面中包含一个 img 标签，该标签对一些众所周知的 URI 执行 GET，并且您的浏览器将很乐意发送基本的身份验证信息。如果 GET 操作是“安全的”（这是任何声称 RESTful 的第一条规则），那么这不会产生问题（除了浪费带宽之外）。
由于同源策略，Ajax 不是问题。
仅在您生成的 HTML 中包含服务器生成的令牌，并验证其在表单提交请求中的存在，才能保护您免受其他人在其页面中简单包含“外来”表单的影响。您可以将其限制为浏览器生成的内容类型；对于 XHR 请求无需这样做。
Disclaimer: I am not a security expert.
Using HTTP Basic Auth does not prevent CSRF attacks via GET requests. E.g. somebody else can include an img tag in their HTML page that does a GET on some well-known URI, and your browser will happily send along the basic auth info. If the GET operation is "safe" (which is the #1 rule for anything claiming to be RESTful), this will not create a problem (beyond wasted bandwidth).
Ajax is not a problem because of the same-origin policy.
Only including a server-generated token in the HTML you generate, and validating its presence in form submission requests, will protect you from somebody else simply including a "foreign" form in their pages. You might limit this to the content types generated by browsers; no need to do so for XHR requests.
是否需要 CSRF 保护取决于 2 个因素： -
请求是否执行状态更改操作（与 REST API 无状态性不同） - 状态更改操作是指任何会执行以下操作的操作：更改应用程序的状态..例如删除某些内容、添加某些内容、更新某些内容。应用程序将使用这些操作来更改用户的支持状态。所有 Post 请求和一些 Get 请求都属于此类别。 REST API 可以具有状态更改操作。
是否由浏览器提供身份验证（不限于 cookie） - CSRF 发生是因为浏览器的请求中包含身份验证信息，无论该请求是由用户发起的，还是其他开放的选项卡。因此，浏览器可以自行包含信息的任何类型的身份验证都需要 CSRF 保护。这包括基于 cookie 的会话和基本身份验证。
对于属于以上 2 类的所有请求，都需要 CSRF 保护。
正如 Stephan 上面的回答，Ajax 请求由于同源策略 (SOP) 而受到保护。 SOP 防止其他域读取目标域发送的内容。因此恶意脚本无法读取授权标头。但 SOP 不会阻止另一个域向目标域发送请求。因此，恶意脚本仍然可以向目标域发出状态更改请求。浏览器会在这个请求中包含身份验证信息和cookie，因此服务器需要知道这个请求是来自恶意域还是来自用户。因此需要 CSRF 保护。
Whether or not CSRF protection is needed is based on 2 factors: -
Is the request doing a state changing action (not the same as REST API Statelessness) - State changing actions are any action that will change the state of the application.. for example delete something, add something, update something. These are actions using which the application will change the backed state of the user. All Post requests and a few Get requests will come under this category. REST APIs can have state changing actions.
Is the authentication provided by browser (not limited to cookies) - CSRF happens because authentication information is included in the request by browser irrespective of whether the request was started by the user, or some other open tab. So any kind of authentication in which browser can self include information needs CSRF protection. That includes both cookie based sessions and basic authentication.
For all requests that fall in above 2 categories CSRF protection is needed.
As answered by Stephan above, Ajax requests are protected because of Same Origin Policy (SOP). SOP prevents another domain from reading the content sent by target domain. So the malicious script can't read the authorization header. But SOP doesn't prevent another domain from sending requests to the target domain. So the malicious script can still make state changing requests to the target domain. Browser will include authentication information and cookies in this request, so server needs to know whether this request originated from the malicious domain or the user. Because of this CSRF protection is needed.