W3C home > Mailing lists > Public > public-appformats@w3.org > May 2008

Re: [AC] URI canonicalization problem with Access-Control-Policy-Path

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Wed, 14 May 2008 15:15:18 -0700
To: Jonas Sicking <jonas@sicking.cc>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <OF7A85E332.BEC247A3-ON88257449.0078CB5A-88257449.007A4036@us.ibm.com>

Sorry for beating a dead horse, but IMO the policy manager (i.e., the
software that decides whether to allow a request to go through, aka the
PEP) shouldn't be on the client anyway. The client should just make
cross-domain requests and the server should enforce which requests are
allowed to go through. Instead of the server delegating to the client the
responsibility for only allowing certain requests (e.g., only to /api/*),
the server should itself take responsibility for permitting or denying
requests. (JSONRequest in contrast has no client-side mechanisms for
deciding which requests should be allowed or denied and assumes that any
such logic would be on the server.)

Jon



                                                                           
             Jonas Sicking                                                 
             <jonas@sicking.cc                                             
             >                                                          To 
             Sent by:                  "WAF WG (public)"                   
             public-appformats         <public-appformats@w3.org>          
             -request@w3.org                                            cc 
                                                                           
                                                                   Subject 
             05/14/08 02:46 PM         [AC] URI canonicalization problem   
                                       with Access-Control-Policy-Path     
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Hi folks,

Mozilla has received input that some servers canonicalize URIs in ways
that are incompatible with rfc2396. This can lead to security issues
with the Access-Control-Policy-Path header. Consider the following:

A server uses the following uri space to serve a number of cross-site
http-based APIs:

http://example.com/apis

The server wants all resources under this uri-space to be accessible for
cross-site POSTs. So for the preflight OPTIONS request to this uri it
replies:

Access-Control: allow <*>
Access-Control-Policy-Path: /apis
Access-Control-Max-Age: 36000

This means that the UA will not do any more preflight requests for any
uri under "/apis".

However, apparently there are servers out there that canonicalize URIs
differently from rfc2396 by treating "\" characters as path separators.
An attacker can use this to attack a server configured as above.

It first sends a POST to "/apis", this makes the UA cache the above
policy for 10h. It then sends a POST to "/apis/..\admin.cgi"

To a UA it looks like this is a POST to the file "..\admin.cgi" in the
"apis" directory. However there are apparently servers out there that
will canonicalize the above to /admin.cgi and thus treat it as a POST to
that URI, which may not be safe.

Not really sure how to fix this short of disabling the whole
Access-Control-Policy-Path feature. Especially if we assume that there
are other canonicalization behaviors out there as well.

If anyone has more info on this issue we would very much appreciate
that. Apparently this has come up in connection with the flash policy
file in the past.

/ Jonas










graycol.gif
(image/gif attachment: graycol.gif)

pic11616.gif
(image/gif attachment: pic11616.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Wednesday, 14 May 2008 22:17:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 May 2008 22:17:48 GMT