Re: [security-services] Changes for Core 26

["Eve L. Maler" <eve.maler@sun.com>]

At 06:31 PM 2/11/02 +0000, Stephen Farrell wrote:
>1) Webmaster puts some private stuff at "http://foo.com/private"
>on a web server that treats filenames as case insensitive (they
>do exist!)
>2) Web server has saml plug-in that sends an authorization
>query to its favorite PDP
>3) That PDP is setup so that access to "http://foo.com/private"
>is subject to some rules (say some authentication and maybe
>only certain punters). Say the PDP treats URLs are being
>case-sensitive as the current spec suggests. Everything else
>(except "/private") is public.
>4) Bad guy at browser types "HTTP://Foo.coM:80/PrIvAtE"
>5) PEP asks PDP
>6) PDP checks compares off-the-wire value: "HTTP://Foo.coM:80/PrIvAtE"
>against stored value: "http://foo.com/private". They don't
>match.
>7) The PDP says "ok" to the PEP.
>8) The bad guy gets to see what's in "/private".

I see.  If the PDP is configured to say "allow access to everything except the
resource corresponding to this exact case sensitive string: 
'http://foo.com/private'",
it will indeed do a bad bad thing.

>Now, that's not good. but someone might say: "that's a dumb
>PDP - it should have run toupper() over the URI string the
>PEP fed it, and the stored version, then it wouldn't have
>given the wrong answer", which is true in this case, but
>however, if the webmaster also has another web server that
>treats filenames as case sensitive then (they also exist)
>then "/Private" may indeed be different from "/PRIVATE",
>so the PDP wasn't dumb, its just caught in a bind - as are
>we since the two most popular web servers running on their
>most common servers running on their most common OSes actually
>represent these two different cases.
>
>Another variation arises where the authorization response
>from the PDP contains the URI in some "canonical" form, (say
>after toupper()). Now a number of PEPs would like to be able
>to cache that information or do some other clever stuff. The
>example of "http://foo.com/gifs" might come to mind as one
>where caching at the PEP would be useful for efficiency.
>In this case, the PEP has to do the comparison between the
>off-the-wire and the "stored" form.
>
>The situation's even worse if the PEP is integrated into
>an http proxy (more generally, an ALG) since then the PEP
>doesn't necessarily have the case-sensitivity information.
>
>The extension of this case, where the URI contains escaped
>characters has been used to successfully attack the built-in
>access control in at least one of the major web servers. (In
>that case the PDP has to realize that "http://foo.com/foo%20bar"
>is the "same" as "http://foo.com/foo bar", (even though the
>latter isn't a good URL, it can get sent over the wire!).
>
>I think the best we can do is regard 2396 (or something as
>good, I don't care) as defining our "c14n" algorithm for
>URIs.
>
>Case-sensitive-compare-over-the-entire-URI-string-off-the-wire
>is not however, "as good". In the case of http URLs in the
>wild, its just plain bad, unfortunately.
>
>Hope I've made it clear,
>Stephen.

Originally, we were talking about matching URIs on attribute/action 
namespaces,
and in that case, we'd be following a common XML precedent (XML Namespaces, to
be exact) if we prescribed case sensitivity.  But for actual resolvable 
resources
in authorization decision queries and statements, I can now see where case
sensitivity would be a problem.  Do we want to have two different rules for
different kinds of URIs?  (Geez, I really wish XML namespaces hadn't reused 
the
concept of URI syntax for its identifiers.)  It would be extremely weird to
allow both of the following (and the infinite number of variations) as 
"the" action namespace:

   http://www.oasis-open.org/committees/security/docs/draft-sstc-core-25/rwedc
   http://www.oasis-open.ORG/committees/security/../security/docs/draft-sstc-core-25/rwedc

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com