0

I'll try to make the explanation simple and to the point (keyword try). And if that's not sufficient, then maybe I can expand on the question.

Imagine two sites: resources.example.com and www.example.com. I only have direct control over resources.example.com. www.example.com ultimately wants access to resource.example.com/dashboard. The idea here is the resource should be protected; secured.

I also cannot validate www.example.com user credentials for authentication (i.e. username, password). I don't have access to their user store. Ultimately, above all else, my priority is ensuring that www.example.com is the identity of the resource requester.

My first thought was having www.example.com issue a CORS request to resources.example.com for authorization and send back a token. Token expiry is small (<5 seconds). I check that the request is POST, validate the origin header and the referrer, if it exists. If no origin header is passed, authorization fails. User then passes back token with standard POST request to resources.example.com/dashboard.

The problem is this is a very bad authorization scheme. Origin header is resistant to spoofing but it absolutely can be spoofed. Referrer is even easier to bypass.

www.example.com wants to keep effort minimal, which probably means it's up to me to code their piece because I don't know if there's a simple solution here. They are open to CORS request.

My question is how can I secure the resource on my site in a CORS request and ensure the identity of the client is www.example.com, knowing the origin header can be spoofed?

Is there some way I can possibly leverage, i.e. aJSON Web Token (JWT) using asymmetric cryptography in order to prove the identity of the requester is www.example.com, even if the origin header is compromised? If so, who would generate the JWT, me or www.example.com?

1

You are focused for user will access your server directly. Same data can be represented by www (proxy) and authorization validation can be done. Following list will describe a solution for you, could you please review.

  • www.example.com will map resource.example.com as www.example.com/resource/. For example "profile.jpeg" will be at place "resource.example.com/profile.jpeg" but will be able to access with "www.example.com/resource/profile.jpeg"
  • Write proxy configuration to your HTTPd (if there is a load balancer it will be better of course). You will need configuration described below. When resource directory tried to access, this request will be proxied to resource.example.com.
  • If authorization will be given by www.example.com so it have to validate it. There is couple of authorization validation technique, I suggest something like subrequest feature of Nginx. If users are not be authorized for access this data, forget this step.
  • Deploy ip filter & be sure only www is able to communicate (tcp/ip) with resource.

You can see flow representation.

User requests www.example.com/x/y/z    =>  Nginx (Proxy)  => www.example.com
----------------------------------------------------------------------------------
User requests www.example.com/resource =>  Nginx (Proxy)  => resource.example.com
                                                ||
                                         Auth SubRequest
                                                ||
                                                \/
                                     www.example.com/auth-check

This should solve your problem.

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.