ring-anti-forgery and web services

[mynomoto]

On the readme there is a caveat about using ring-anti-forgery with web services. But it can work with those just fine and would even work out of the box if the default access-denied response included the token on the header - if the client just send the token back with its request.

Could this header be in the access-denied response by default? Or can you think about reasons not to do it?

Thanks.

I'd also like to know, if returning the anti-forgery-token in the access-denied response could be harmful. One scenario I could think of, is that your site isn't XSS-secure, makes a faulty request on purpose and just sends the token from the response off to some third party for CSRF attacks.

[weavejester]

CSRF is a form of confused deputy attack that targets websites secured via a session cookie. Your web service shouldn't be authenticating with session cookies, so anti-forgery protection does not apply. There's literally no point to including ring-anti-forgery on any part of your site not sitting behind a secured session.

[jayp]

Hi @weavejester - I believe @mynomoto may be requesting this somewhat abstruse feature because webservices and user-facing webapp can't coexist in the same ring-app when using ring-anti-forgery. From the README:

Caveats

This middleware will prevent all HTTP methods except for GET and HEAD from accessing your
handler without an anti-forgery token that matches the one in the current session.

You should therefore only apply this middleware to the parts of your application designed to be
accessed through a web browser. This middleware should not be applied to handlers that define
web services.

As a clojure noob, I would like to make an attempt at a patch that adds an optional parameter (let's say :protect-urls) to wrap-anti-forgery. Or is there a better way to address the caveat? (If so, we should update the README for all noobs alike).

[weavejester]

You don't need to apply wrap-anti-forgery at the top level of your app. For instance, in Compojure you could write:

(routes
 api-routes
 (wrap-anti-forgery site-routes))

[jayp]

Ha! Thanks @weavejester.

To help out fellow noobs, I will submit a small patch noting this in the README.

[Parth-Brahmbhatt]

I still don't get this. In apache storm we have same post route being used by our web page and the rest api. In order to use CSRF protection I will now have to create duplicate routes?

[weavejester]

CSRF attacks come about because form POSTs can be triggered across domains. If the same URI is intended to receive authenticated POST requests from both a browser and an API client, then you need some way of determining whether or not the request comes from the browser or API client.

For example, perhaps you use cookie-based sessions to authenticate browsers, and HTTP Basic Auth to authenticate API clients. You could have some custom middleware that checks to see how the user is authenticating; if it's via a session, then the anti-forgery middleware is added, otherwise it leaves it out.