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

[Peter W <peterw () usa net>]

On Mon, Jul 30, 2001 at 03:46:29PM -0400, Aaron Bentley wrote:

> I have also noted that cgi-generated PDF files are not handled correctly
> in some IE/Acrobat combinations, yet normal PDF files are handled
> properly.  By configuring an alias for the cgi program with a PDF 
> extension, I was able to get IE to launch Acrobat properly.

One good trick for this (and some security issues; see below) is to use
the PATH_INFO slot to fool the browser. E.G., instead of referencing
/cgi-bin/download.cgi, use /cgi-bin/download.cgi/data.pdf which will run
the same app, but pass it /data.pdf as $PATH_INFO. The browser thinks it's
retrieving data.pdf from the /cgi-bin/download.cgi/ directory. So life is
good, even for goofy browsers like IE. This also helps all Web browsers
choose better "save as" filenames. No server alias configuration needed.

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.