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-next>] [day] [month] [year] [list]
Date: 10 Jan 2007 00:20:43 -0000
Subject: Re: Circumventing CSFR Form Token Defense

If there is a method which enables JavaScript to set up arbitrary HTTP requests and read the server's answers, you could implement an "autonomic browser" which requests any pages (using the user's cookies to authenticate) and saves them somehow to an internal string. From then, there's no barrier for transmitting this data to the attacker's server. Alternatively, the script may perform all the work the attacker wants it to (download all gmail messages...) and send this to the attacker. Therefore I agree that any tokens do not add security.

Testing (only with IE, Firefox, Opera and Konqueror so far) I found no way how to circumvent the restrictions of *reading* requested pages from JS - setting up the request works, but attempts to read the document (embedded in an frame/object*/iframe) failed with some "access denied" exception (FF,Opera: exception, Konqueror: undefined values, IE: Strange errors) when domain names do not match. (So that the potential of the attack is still there - think eBay and their JS policy - but limited to sites allowing users to write JS - || browsers not taking extensive precautions in handling JS between frames/objects)

XMLHttpRequest et al are limited in the same way.

So "The javascript makes a simple HTTP/S request to the form (...)" turns out to be the critical problem. Any ideas how to set up and somehow read a HTTP request to another server in JavaScript?

*except IE

Powered by blists - more mailing lists