CODEWITHSUNDEEP
securityhttpcors
Skylar Saveland
Skylar Saveland

Reputation: 11464

Domain-based "authentication" of a CORS request

I don't think that what I'm hoping to do is possible. I'll describe the idea.

User requests foo.com and gets a html page with a script. The script makes a CORS request to bar.com. The server at bar.com restricts access to / to requests that really came from a script served by foo.com. Is there a way that the server can securely deduce that the request really came from a script on foo.com?

The Referer and Origin headers contain the information I would like to use. But, obviously these can be easily faked.

Is there a trustworthy aspect of the request that can be used by bar.com to change its behavior based on where the request originated?

Let's say I have control over the script on foo.com and the server on bar.com. Is there any way that I can insert something into the script that could not be replayed/forged by an attacker mimicking the script? The attacker has access to the script as let's say foo.com is public.

Any ideas or discussion would be appreciated.

Upvotes: 0

Views: 64

Answers (1)

bobince
bobince

Reputation: 536399

The point of an Origin check is to prevent a third-party attacker forcing the target user's browser to do something dangerous. (And Referer does the same just much worse, to the point where it is unlikely to be of any value.)

But you cannot prevent the user themselves from sending any kind of request by playing with their browser. Even if you somehow made it impossible for them to send an inaccurate Origin header, they could still interfere with the entire operation of the script inside the page from foo.com (eg using the F12 debugger) to make it do something you didn't intend whilst still sending foo.com in the Origin.

You cannot rely on scripts you send the user being executed without changes, you cannot rely on information inside scripts you send the user being kept secret, you cannot be sure that the request is even coming from a real browser.

The user completely controls the client environment, so you need to design your trust model with that in mind. The implications depend on what you are trying to do, but a possible general-purpose authorisation scheme would be to create a token representing what actions the user is permitted to take on bar.com, and sign it with a secret key on foo.com, then give the signed token to the user to pass to bar.com when doing the CORS request.

Upvotes: 2

Related Questions