Some use cases for GWC rely on CSRF. about girder_web_components

[zachmullen]

I'm a little confused about the title, do you mean CORS rather than CSRF?

In your case, how would you get hold of a valid DKC token on your app?

[jbeezley]

It shouldn't be necessary. If you hit the login endpoint, girder sets the auth cookie for the server's domain via a response header.

[subdavis]

Sorry, I mean CSRF because an active session cookie with data.kitware.com is necessary for domain.example.com to run the above application and load the video.

My app gets a token when a user logs in with GWC's own Auth component and stores that token in domain.example.com's cookie jar. This does require CORS to be enabled for domain.example.com, but that isn't enough to load the video.

@jbeezley what are the conditions required for this? When I hit /user/authenticaton, the Set-Cookie header only appears if my request originates from data.kitware.com. If I hit /user/authentication from another domain, no Set-Cookie header is present.

[jbeezley]

Good point. I think it will work if you add this:
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Sending_a_request_with_credentials_included

[subdavis]

I'm not quite sure how to use that to fix this issue.

I tried making the authentication request with fetch instead, and I get Access to fetch at 'https://data.kitware.com/api/v1/user/authentication' from origin 'http://localhost:8081' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

I believe this is a regular browser CORS issue: Chrome won't set cookies for data.kitware.com when a request originates from another domain. I don't think you can force a browser to do with fetch.

Does that make sense, or have I used fetch wrong?

fetch('https://data.kitware.com/api/v1/user/authentication', {
      headers: {
        'Girder-Authorization': 'Basic ......',
        'Girder-Token': null,
        'Origin': 'http://localhost:8081',
        'User-Agent': 'Mozilla',
      },
      credentials: 'include',
      mode: 'cors',
      method: 'GET',
    }

[jbeezley]

Yeah, I guess it will only allow you to do that if you white list a specific domain.

[zachmullen]

My app gets a token when a user logs in with GWC's own Auth component and stores that token in domain.example.com's cookie jar. This does require CORS to be enabled for domain.example.com, but that isn't enough to load the video.

Is this authenticating against DKC, or against domain.example.com?

[subdavis]

App running on domain.example.com, authenticating against DKC using gwc/Auth/Authentication.vue

[zachmullen]

Ah yes. In that case you'd need to white list the domain explicitly, which makes sense when you consider the security implications here (if you pretend your site was a malicious site, for instance)

[zachmullen]

If this is for a demo site or something, or an app, I'm fine with whitelisting it on DKC.

[subdavis]

I think you addressed that by allowing cookie-authentication only for downloads endpoints. As it stands, any malicious site could already display protected data in girder if it knows the URI.

Rather than relying on the girderToken cookie set by DKC, girder could allow query string based authentication for media on a page.

From domain.example.com, I want to be able to do this:

<img src="https://data.kitware.com/file/:fileid/download?token=mytoken">

This is easier than having to white-list domain.example.com explicitly, especially if the person developing domain.example.com isn't a DKC admin, or even some other entity not endorsed or managed by Kitware.

One of the major strengths I see in GWC is that it allows non-privileged users to develop and deploy apps that use any instance of girder. This feature would enable developers to embed girder-managed data into their own apps on any domain where CORS is enabled.

I suppose what I'm confused about is why you would enable CORS for * (such as DKC does) when you really want to restrict CORS capabilities to a white list.

The security implications are, as far as I can tell, no different with or without this feature.

[zachmullen]

I suppose what I'm confused about is why you would enable CORS for * (such as DKC does) when you really want to restrict CORS capabilities to a white list.

We don't want to restrict allowed origins to a white list, but browsers insist on white list policies for certain functionalities like the one you're trying to do. As such, I'm happy to add a whitelist in addition to * to enable your use case. (Girder lets us have both * and explicit domains in a list IIRC.)

[subdavis]

I'll follow up if it turns out the whitelist addition is needed. Mostly I'm just trying to figure out if allowing cookie auth for video and img resources is the best way to grant access to protected resources for every use case.

I think there are times when token-based auth would be more convenient, but those cases may be rare enough to deter this addition. Going to close this issue for now.

Thanks, @zachmullen!

Edit for historical record: Token-based auth would allow a developer to reliably display content without being domain-whitelisted, but using/reading/modifying the resource with a canvas still wouldn't be possible.

The ability for non-whitelist origins to display authenticated content from girder when a session is active is probably more of a harmless by-product than an actual feature.