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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070513192740.13DE.0@paddy.troja.mff.cuni.cz>
Date: Sun, 13 May 2007 20:14:22 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: bugtraq@...urityfocus.com
Subject: Re: squirrelmail CSRF vulnerability

On Sat, 12 May 2007, Josh Zlatin-Amishav wrote:

> On Fri, 11 May 2007, Tim Newsham wrote:
> 
> > This might just be semantics:  I wouldn't consider the XSS attack to be a 
> > CSRF attack.
> 
> The point is, if the application is vulnerable to an XSS vulnerability
> then having a CSRF token wont protect you from a CSRF attack. The
> attacker could use the XSS vector to steal the CSRF token, much like the
> Samy worm worked.

Let's have an HTTP server with a buffer overflow vulnerability making it
possible to run arbitrary code. We can use the vulnerability to read
files outside the document root (perhaps using relative pathnames like
"../../../file") but I don't think this means we should call such an
attack "a path traversal".

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."