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

From: Marc Slemko (marcsat_private)
Date: Tue Jul 31 2001 - 12:40:32 PDT

  • Next message: IBM MSS Advisory Service: "IBM AIX 4.3.x and 5.1: Buffer overflow vulnerability in telnet daemon"

    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.
    



    This archive was generated by hypermail 2b30 : Tue Jul 31 2001 - 15:26:30 PDT