1

I'm consuming OData services from JQuery and running into a typical scenario of Same Origin Policy. I do not have control over the server and therefore I can not implement CORS so the only thing I can do is to use a proxy in order to bypass the same origin policy. In particular I use cors-anywhere. But I tried others and still having the same issue.

So, anyway, until then it is all cool, I'm able to save the situation with the proxy and to execute my ajax call with no problem, but, this only works for GET requests. Because, now the server also requires a CSRF token for POST, PATCH, etc and it looks like the token I obtain through a call to the server through the proxy:

resuest csrf

is not valid for my next consecutive requests to the server. Moreover, I notice that every time I request a CSRF token like this(http://localhost:9191/https://my-server) I obtain a different one, which is not happening if I do the request without using the proxy(https://my-server). So, my question is:

Would anyone be able to explain why this is happening and if so, is there any way to overcome this problem in order to be able to make requests from JS?

So far I've tried a number of things such as rewriting Host, Referrer, Origin and other headers in the proxy without success and though I could really use some help from this wise community here. Any comments or suggestions welcome.

Cheers,

  • 2
    You probably need the withCredentials option on the XMLHttpRequest, and Access-Control-Allow-Credentials in the server headers – paj28 May 19 '17 at 19:39
  • Could you try to pass some traffic captures here? From client-proxy and proxy-server communication? Its hard to tell something without such information. – Fis May 26 '17 at 17:46
  • Are you sure the token you add to headers on client side correctly passes the proxy including referrer and/or origin headers? – Fis May 26 '17 at 18:03
1

I'm not sure if this applies in this case but I thought it may be useful to some people.

CSRF tokens are sometimes rejected because each consecutive request doesn't preserve the cookies which were set on the previous request. This is likely because the CSRF token is either stored as its own cookie or more often, inside a session cookie which will change if Set-Cookie is ignored.

1

As far as I can tell, it sounds like cors-anywhere is caching the CSRF token when it should not be. I would run wireshark on your node server, and confirm that your requests are being forwarded on to the target server every time.

If that doesn't work, I would try running cors-anywhere on a different machine. I've seen some unexpected behavior with cookies from browsers when using local host, and there might be something similar happening with request headers.

-2

Have you tried $ npm install cors ?? easy documentation here :-https://www.npmjs.com/package/cors

  • Welcome on the Security SE! I think at least a little explanation, why and how would this solve his specific problem would be highly useful. Here is a quick tutorial, how to write a good, upvotable answer. – peterh May 26 '17 at 12:18
  • 1
    Correct me if I'm wrong but unfortunately this package you mention is for enabling cors in the backened, which, as explained above, does not solve my problem as it is impossible for me to change anything on the server side. – megalucio May 26 '17 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.