OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [security-services] Changes for Core 26



Eve,

[...stuff...]

> I'm not sure I understand this...

I'm probably not using the latest concepts here since it was
a couple of years ago when I was debugging this, but the 
following happens:

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".

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.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC