[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