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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jan 2007 08:38:44 +0100
From: Florian Weimer <>
To: Jim Manico <>
Subject: Re: Circumventing CSFR Form Token Defense

* Jim Manico:

> CONJECTURE: An attacker could write a hybrid "html inspection, CSRF
> attack" mimicking an exact important form (like the funds transfer
> form for an exact bank) **even if the form in question uses form
> tokens**.

I'm not sure what you mean by "form tokens", but correctly generated
tokens are unique to the user's session.

>   a) The javascript makes a simple HTTP/S request to the form it is
>   trying to mimic and inspects the returned HTML for the purpose of
>   pulling out a valid form key since the form key NAME is known from
>   (1).

To work, this requires a cross-site scripting vulnerability in the web
application (or lack of enforcement of the same-origin policy by the
browser).  (The rule of thumb is: XSS for read access, CSRF for write

Powered by blists - more mailing lists