3

We recently got an API for security audit. The CORS headers of the API seems mis-configured as when we tried requesting the endpoint with http://attacker.com as origin the server returned the following in the response headers:

access-control-allow-credentials: true    
access-control-allow-methods: GET, POST, DELETE, PUT    
access-control-allow-origin: http://attacker.com

Though the site is vulnerable, but the problem which is blocking us from creating an exploit impact is that the site send an authorization token in each request, which is unique for each user. Any ideas on how to go ahead in a situation like this?

  • Where in the request would teh authorization token be? In a cookie? In a header? If so, what header? – Anders Feb 7 '17 at 12:18
  • Its in the headers, named Authorization: Bearer – StackB00m Feb 7 '17 at 12:32
2

Cross origin requests are dangerous because it makes it possible to use the session of the user to make requests as that user. This works because a cookie is sent along with the request and implicitly authenticates the user to the web application under attack.

If your application does not use cookies but instead uses a header to keep the session token in, the danger of cross origin requests is mitigated. You can still do requests to the server, but not under the session of the user.

  • Requests without the auth bearer are all requests that doesn't leak anything in response, nor that does perform any sensitive action, so there's no point in performing them – StackB00m Feb 7 '17 at 12:37
  • But this attack can only be done if XSS is done on your website right? – majidarif Nov 4 '17 at 4:55

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.