[cap-talk] Polaris tickle, POLA for Internet access, URLs
jed at nersc.gov
Fri Dec 10 22:42:23 EST 2004
At 03:51 PM 12/9/2004, David Mercer wrote:
>On Thu, 9 Dec 2004, Jed at Webstart wrote:
> > It seems to me that because http is a stateless protocol, any notion
> > of state shared across transactions must be contained in information
> > associated with a "connection" by the client or server. The only notion
> > of "connection" that I know of in clients involve shared state
> > retransmitted with repeated http requests to a single site. Amongst the
> > mechanisms I am familiar with are:
> > 1. Basic authentication - where the client browser remembers
> > username/password information and repeatedly sends it with
> > each transaction to the same IP address. Certificated access
> > works similarly. This has nothing to do with "automatic login",
> > but happens after a manual login in order to keep the user
> > from having to re login with every request to the server - clearly
> > impractical.
> > 2. Cookies - where again the client remembers cookie information
> > and resends it with every request to an IP or IP/path combination
> > (I've forgotten the details, but one can adjust that to some extent
> > when saving a cookie).
>State is often encoded in urls and/or form fields. The stateless nature
>of the http protocol has spawned countless emulations of a stateful
>connection to have been hacked on top of it. Parameter passing vis POST
>form fields or GET requests is typical and common.
>If cookies hadn't been so maligned and feared due to bad press, perhaps
>they would have become a universal, rather than merely popular, way to
>encode state across http requests. As it stands you can't really ever
>tell algorithmicly whether any given url transmits state.
Perhaps not in general because of course any portion of something like
a method GET URL could be considered "state". However, some forms
of 'state' are clearly known about by the user's browser and are often
relevant for authentication. In particular the basic authentication
mechanism has as an explicit part of its mechanism to resent
username/password information on every request to the same
site (DNS is I believe what it is based on). Does it seem to be asking
too much to have my browser warn me or even not include that
authentication information if it is directed to a site by virtue of
a redirection from another site? With cookies the rules are a bit
more complex but I believe the same reasoning applies.
I've spent some time recently reminding myself of the issues with
what's generally called a "cross site scripting" vulnerability (to
avoid confusion with cascading style sheets this is abbreviated
XSS). I believe that issue to be distinct from this problem
resulting from redirection to a site with assumed state (e.g.
basic authentication or cookies).
>I've administered over a dozen different web server platforms in my past as
>an admin in commercial production environments, and believe me it is
>completely trivial to map any url to anything you want.
I also do mostly system administration these days and have had
the "webmaster" moniker in my title a few times and am quite familiar
with many ways to do redirection - which is why this particular threat
got me going.
>I can make http://www.EvilServer.com/images/Jed.png call a cgi.
You mean by redirection in the server? Of course I assume you aren't talking
about something in a real .png file. That would be interesting (shades of
the Microsoft .jpg problem).
>can make any png that the server recieves a GET request for in that
>/images directory map to the same cgi, and have EvilProgram interpret each
>filename requested as data returned to it, and it can even hand you back a
>png standard conformant 1x1 image that you won't ever see, and your
>browser will happily not raise an 'invalid image' dialog.
All well and good, but you haven't gotten their database updated
according to your evil intent - as I claim to do below.
>My point is that any http GET request, even if it looks harmless, may be
>an unauthorized data transmission. Encapsulating the browser in a
>restricted execution environment built with POLA in mind will limit what
>can be transmitted.
>But you can't ever tell by looking what's an evil url.
I believe I understand what you are getting at.
However, I believe the threat that I've brought up here is distinct
(and off topic I readily admit).
It doesn't require any cgi's or anything. I assume that somebody I know
is often logged in to some site where I know the form of a (let's say)
method GET command which, if authorized, could do something I want
but they don't to their authorized site.
Then I just get them to visit:
and I have it redirect to:
Their browser takes them there and I set things up so the
returned results show up on an invisible frame with something
innocuous showing up in the main frame.
It's the fact that the above request happens from their browser
which sends in their username/password or cookie or whatever
it is that authenticates them on every Web request to their
site that causes the problem. I believe this isn't the XSS
problem, but it still seems like a significant problem to me.
More information about the cap-talk