启用内容类型协商后，JAXRS静态服务是否容易受到CSRF攻击? [英] Are JAXRS restful services prone to CSRF attack when content type negotiation is enabled?

问题描述

我有一个带有RESTful API的API，该API带有@Consumes(MediaType.JSON)之类的注释-在这种情况下，在这样的服务上仍然可能发生CSRF攻击吗?我一直在努力通过服务器端的CSRFGuard来保护我的服务，或者从客户端进行两次提交.但是，当我尝试使用带有enctype ="text/plain"的FORM来发布请求时，此方法不起作用. 此处对此技术进行了解释如果我的消费注释中包含MediaType.APPLICATION_FORM_URLENCODED.当我使用POST/PUT/DELETE动词但仍可以访问GET时(可能需要进行调查)，内容协商非常有用.

I have a RESTful API which has annotations like @Consumes(MediaType.JSON) - in that case, would the CSRF attack still be possible on such a service? I've been tinkering with securing my services with CSRFGuard on server side or having a double submit from client side. However when I tried to POST requests using FORM with enctype="text/plain", it didn't work. The technique is explained here This works if I have MediaType.APPLICATION_FORM_URLENCODED in my consumes annotation. The content negotiation is useful when I'm using POST/PUT/DELETE verbs but GET is still accessible which might need looking into.

任何建议或建议都会很棒，如果您需要更多信息，也请告诉我.

Any suggestions or inputs would be great, also please let me know if you need more info.

欢呼

推荐答案

JAX-RS旨在创建应该是无状态的REST API. 跨站点请求伪造对于无状态应用程序不是问题.

JAX-RS is designed to create REST API which is supposed to be stateless. The Cross Site Request Forgery is NOT a problem with stateless applications.

跨站点请求伪造的工作方式是有人可能诱骗您单击链接或在浏览器中打开链接，这些链接会将您定向到您登录的网站，例如某个在线论坛.由于您已经在该论坛上登录，攻击者可以构建一个URL，这样说:someforum.com/deletethread?id=23454

The way Cross Site Request Forgery works is someone may trick you to click on a link or open a link in your browser which will direct you to a site in which you are logged in, for example some online forum. Since you are already logged in on that forum the attacker can construct a url, say something like this: someforum.com/deletethread?id=23454

经过精心设计的论坛程序将基于会话cookie识别您，并确认您具有删除该线程的能力，并且实际上将删除该线程.

That forum program, being badly designed will recognize you based on the session cookie and will confirm that you have the capability to delete the thread and will in fact delete that thread.

全部是因为程序基于会话cookie(甚至基于记住我" cookie)对您进行了身份验证

All because the program authenticated you based on the session cookie (on even based on "remember me" cookie)

使用RESTful API时，没有cookie，请求之间不会保持任何状态，因此无需防御会话劫持.

With RESTful API there is no cookie, no state is maintaned between requests, so there is no need to protect against session hijacking.

您通常使用RESTFul api进行身份验证的方式是发送一些其他标头.如果有人诱骗您单击指向静态API的URL，则浏览器将不会发送多余的标头，因此没有风险.

The way you usually authenticate with RESTFul api is be sending some additional headers. If someone tricks you into clicking on a url that points to restful API the browser is not going to send that extra headers, so there is no risk.

简而言之-如果REST API是按无状态设计的，那么就不会有跨站点伪造的风险，也不需要CSRF保护.

In short - if REST API is designed the way it supposed to be - stateless, then there is no risk of cross site forgery and no need to CSRF protection.

这篇关于启用内容类型协商后，JAXRS静态服务是否容易受到CSRF攻击?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！