Re: CGI, PATH_INFO, convenience/security (TXT or HTML? -- IE NEW BUG)

[Marc Slemko <marcs () znep com>]

On Tue, 31 Jul 2001, Peter W wrote:

> Security trick: The 2.2.3beta version of the "acmemail" Webmail
> application that's in CVS at Sourceforge uses similar PATH_INFO tricks for
> security reasons. The application sets multiple cookies, one with a path
> of the CGI name plus "/control/" (e.g. "/cgi-bin/acmemail.cgi/control/").
> All interesting/dangerous options (logging out, sending mail, deleting
> messages, etc.) are offered only from URLs that include /control/ in
> PATH_INFO. And functions that display potentially hostile content
> (displaying messages, displaying attachments) *refuse* to do so if
> /control/ is present. The end result is that even if a piece of email
> contains Javascript that slips through the "defang" routines, that
> Javascript will be unable to get the "control" cookie, and therefore won't
> give the attacker the ability to do anything beyond using acmemail to read
> the message which contains the Javascript.[0] Since the attacker 
> presumably had a role in sending the hostile message, reading the message 
> is not an interesting "attack" by any means.
>
> http://sf.net/projects/acmemail/
>
> -Peter
>
> [0] If anyone sees problems beyond that, e.g., a hostile message opening a
> second window with a "/control/" URL and then manipulating that "/control/"
> window via Javascript/DOM, I would appreciate the feedback.

Unfortunately, this doesn't really add much security aside from a bit of
obfuscation.

For example, if you have a page with two frames, one for /foo and
one for /foo/secure, then javascript on the /foo page can read any
cookies set for /foo/secure by using a construct similar to
parent.frames[1].document.cookie.  Access restrictions across frames
only apply on a per domain basis, in general.

The folks at commtouch implemented their web based email system in
a similar way to what you describe, only they then declared that
there was no reason to even bother about preventing the display of
random HTML or scripting in messages.  This was pointed out to
them, but I don't think they understood or cared...  not sure if
their system is still this way, this was some time ago.

Using a different domain name or just the IP address (yuck) when 
displaying potentially hostile content can sometimes help in some 
situations.