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

From: Peter W (peterwat_private)
Date: Tue Jul 31 2001 - 03:52:06 PDT

  • Next message: Ogle Ron (Rennes): "RE: CERT Advisory CA-2001-18, Critical Path directory products ar e vulnerable"

    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.
    



    This archive was generated by hypermail 2b30 : Tue Jul 31 2001 - 11:57:32 PDT