bugtraq - Re: squirrelmail CSRF vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.BSI.4.64.0705110738170.27703@malasada.lava.net>
Date: Fri, 11 May 2007 07:41:41 -1000 (HST)
From: Tim Newsham <newsham@...a.net>
To: Josh Zlatin-Amishav <josh@...at.cc>
Cc: p3rlhax@...il.com, bugtraq@...urityfocus.com
Subject: Re: squirrelmail CSRF vulnerability

>> II. Application should use CSRF token which is random enough to identify 
>> every legitimate post login request.
>
> According to: http://squirrelmail.org/security/issue/2006-12-02 version
> 1.4.8-4 is vulnerable to a XSS vulnerability, so an attacker could use the
> XSS vector to grab the session token ("CSRF token") and continue the CSRF 
> attack.

This might just be semantics:  I wouldn't consider the XSS attack to be a 
CSRF attack.  The XSS script runs in the same context that the user or any 
legitimate script running on behalf of the user runs.  When it makes a 
reference, it has access to things like the CSRF token.  It's not forging 
a reference.  It's creating one in the same way as any legitimate script 
action would.

summary:
   CSRF - forging a reference blindly.
   XSS script - acting on behalf of the user after same-origin policy
        protections have been compromised

> - Josh

Tim Newsham
http://www.thenewsh.com/~newsham/