Don't use request URI for signing requests with the GBIF authentication scheme

13042
Reporter: mdoering
Assignee: mdoering
Type: Improvement
Summary: Don't use request URI for signing requests with the GBIF authentication scheme
Priority: Blocker
Resolution: Fixed
Status: Closed
Created: 2013-03-20 12:11:42.246
Updated: 2013-12-06 12:06:38.673
Resolved: 2013-09-05 15:14:46.174
        
Description: Currently the gbif authentication scheme in proxied user requests, e.g. from the portal, signs the http request by looking at various http  headers of the request. In particular it includes the request uri which can be modified by varnish thereby breaking the signature.

Consider to remove the request uri from the signature? This might be a bit dangerous as the same DELETE request can then be used for various resources as the id is in the requested uri]]>
    

Author: mdoering@gbif.org
Created: 2013-03-20 12:23:45.517
Updated: 2013-03-20 12:23:45.517
        
Modified headers by varnish as in the attached logs:
b=backend, c=client
{noformat}
16 TxRequest    b POST
16 TxURL        b /occurrence-download-ws/occurrence/download/
16 TxHeader     b Content-Type: application/json
16 TxHeader     b x-gbif-date: 20 Mar 2013 11:01:07 GMT
16 TxHeader     b x-gbif-user: markus
16 TxHeader     b x-gbif-content-hash: 2124300471


15 RxRequest    c POST
15 RxURL        c /occurrence/download/
15 RxHeader     c Content-Type: application/json
15 RxHeader     c x-gbif-date: 20 Mar 2013 11:01:07 GMT
15 RxHeader     c x-gbif-user: markus
15 RxHeader     c x-gbif-content-hash: 2124300471
{noformat}
    

Author: trobertson@gbif.org
Created: 2013-08-28 08:02:11.252
Updated: 2013-08-28 08:08:39.134
        
Is the signing that you refer to happening here please?
https://code.google.com/p/gbif-common-resources/source/browse/gbif-common-ws/trunk/src/main/java/org/gbif/ws/security/GbifAppAuthService.java#177

which is subsequently calling:
https://code.google.com/p/gbif-common-resources/source/browse/gbif-common-ws/trunk/src/main/java/org/gbif/ws/security/GbifAppAuthService.java#100

If so...

Should we consider getting a bit smarter and in varnish do the likes of:
{code}
set    req.http.X-Original-Url = req.url
{code}

and then in the signing look for that custom header, and if present use it, otherwise use the observed URL?

Have we inspected all the HEADERS that the backend sees?  It could be varnish already does something like this, or perhaps there is a standard way of doing this with Varnish (or at least a common header name to use for this when things are proxying and url rewriting)

    

Author: mdoering@gbif.org
Comment: A good idea, much better than to simply remove the URL from the hash as it would allow with simple manipulations to send a validly signed request to a totally different URL. I'll see if varnish add some header already or if we can configure it to copy the original (I think thats possible)
Created: 2013-08-28 09:30:41.226
Updated: 2013-08-28 09:30:41.226

Author: mdoering@gbif.org
Created: 2013-09-05 15:14:46.206
Updated: 2013-09-05 15:14:46.206
        
works in general, but we now face POST problems with chunked encodings in varnish, see related issue.

https://code.google.com/p/gbif-common-resources/source/detail?r=1674
https://code.google.com/p/gbif-common-resources/source/detail?r=1676