1

I have 2 ruby on rails app sitting on 2 different domains (say www.exampleA.com and www.exampleB.com. I want to share resources between the 2 apps and I'm using CORS:

exampleA.com sends http POST request to exampleB.com.

At exampleB.com I'm checking request.env['HTTP_ORIGIN'] to make sure that the request comes from exampleA.com. If true I respond by setting the response headers to allow the http post request.

My question is can I use request.env['HTTP_ORIGIN'] as the only check to verify the identity of requester?

Is it possible for someone from www.exampleC.com to fake their HTTP_ORIGIN to look like www.exampleA.com and post malicious data? If so what's the best way to verify requester identity?

Byron Singh
  • 1,408
  • 1
  • 13
  • 15

2 Answers2

3

Origin is one of several header fields that cannot be set for a XHR request by page authors. So you’re safe to trust the Origin information of XHR requests.

But it is still possible for an attacker to send forged requests with malicious data directly. So you’re still required to validate incoming requests.

Gumbo
  • 643,351
  • 109
  • 780
  • 844
  • "Safe" is relative. Consider if someone *was* able to send any data they they liked (such as from a malicious native application, vuln in Flash or Java, or so on), and if that would expose you to security risk or them execute actions on your behalf – Tom McKenzie Mar 04 '13 at 11:05
0

Sorry, but it is trivially easy to fake most client-provided data, origin included, and hence it should not be used for any type of security.

Brad Werth
  • 17,411
  • 10
  • 63
  • 88
  • However this is client-side anyway and the OP is enabling a client-side mechanism (CORS) so if the client faked a referer they are only reducing _their own protection_. – SilverlightFox Jul 11 '14 at 07:23
  • @SilverlightFox - from op "Is it possible for someone from www.exampleC.com to fake their HTTP_ORIGIN to look like www.exampleA.com and post malicious data?" – Brad Werth Jul 11 '14 at 15:36
  • Yes they could make a request directly, but not one that also includes the victim's auth cookie on the client side. – SilverlightFox Jul 11 '14 at 15:53
  • I'm not making any assumptions. – SilverlightFox Jul 11 '14 at 16:10
  • Where in the OP does it say "auth cookie", then? I'm done discussing this with you. If you require further clarification, present it as a question so it can be handled by people that care a lot more than I do right now... – Brad Werth Jul 11 '14 at 16:15
  • I commented to inform in case anyone else comes across your answer, not to argue. After all, this is what SO is about. First point is that you're commenting on the `referer` header, the OP mentions the `Origin` header - this is different. If you are saying not to trust the `Origin` header then you are essentially saying not to use CORS at all as it is insecure. The `Origin` header is what everything hinges on within [CORS](http://www.html5rocks.com/en/tutorials/cors/). Making a request from a browser is different than making a pure HTTP request because the DOM is at stake here. – SilverlightFox Jul 11 '14 at 16:45