Ebay API Question posted in
The official documentation of all the APIs offered by Ebay can be found here.

JASIG CAS CORS what should happen when Origin == "null"? – Ebay API

I am using a CAS server to secure my Spring applications which includes REST and HttpInvoker APIs.

When an application redirects to a CAS server in a different domain we get CORS
‘issues’. I have added the eBay Cors-Filter https://github.com/eBay/cors-filter to the applications and the CAS server.

However…

when the application redirects to the CAS server for authentication, the Origin header is changed to ‘null’. This is due to a “privacy-sensitive” context noted in the CORS spec (page 14, section 7.3).

…and, now at last…the question!

If the server receives an Origin header of ‘null’ can it proceed as normal, just returning ‘null’ in the Access-Control-Allow-Origin header?

Does this break anything?

Is it unsafe?

Cheers

Tags:

2

Answers


  1. 0

    Yes, I believe you can return null or the wildcard * to allow any origin.

    Does this break anything?

    If you’re only returning null when Origin: null is received then it shouldn’t affect anything else.

    Is it unsafe?

    I’m not familiar with CAS, however as long as you aren’t sending Access-Control-Allow-Credentials too, and your CAS isn’t restricted by IP or on the local network only, then this doesn’t open up your system any more than anonymous access does. See this answer for technical details.

    If you are, then setting Access-Control-Allow-Origin will allow other domains and origins to read data from CORS that the user visits, using their cookies for CAS.

    Login or Signup to reply.
  2. 0

    Allowing null origins is unsafe. This blog post does a pretty good job of breaking down why. The short version is, it enables a form of CSRF. An allowed origin of null means “any page that redirects to me” (or any code running from a file:/// URL, but that’s another topic).

    Let’s say your app at app.example.com uses a service at service.example.com, protected with CAS on auth.example.com. Also, let’s assume you set up service with Access-Control-Allow-Origin: null so that you can make a fetch from app that points to auth with a redirect to service. Got all that? Good, you make a fetch for auth.example.com/cas/login?service=service.example.com, login happens (session cookie set on auth.example.com), redirect happens (session cookie set on service.example.com), app gets data from service. Because of your Access-Control headers, the browser lets your app read the response.

    Now, imagine that you visit a malicious page (evil.com/hello) that knows about your service. They run a 302 page on evil.com/redir that points to service.example.com. Now, this malicious code can fetch evil.com/redir with credentials="include". The browser will request the redirect page, getting a 302 with ACA-Origin=https://evil.com and ACA-Credentials=true, Location of service.example.com. The browser follows the 302, requesting service.example.com and including the relevant session cookie. In this request, Origin is set to null but you’ve whitelisted that value, so your service sends an ACA-Origin value of null and the browser lets the (malicious) requesting code see the response. You just leaked authenticated data from your service to the injected script, which can send it home to the attacker.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search