| 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
| ||
|
Message-ID: <4ef5fec60712122233x46409f0ci13efd27d4ad9581@mail.gmail.com> Date: Wed, 12 Dec 2007 22:33:04 -0800 From: coderman <coderman@...il.com> To: steven@...urityzone.org Cc: full-disclosure@...ts.grok.org.uk Subject: Re: Google / GMail bug, all accounts vulnerable On Dec 12, 2007 1:27 PM, Steven Adair <steven@...urityzone.org> wrote: > ... if you simply > had a 302 or mod_rewrite rule for any image that you actually had written > into the source of your page, you could achieve the same result. no, that would only trigger a request when the page is loaded. a refresh on the page is likely to get filtered, but that works too. (and was used to implement an attack against Tor clients without entry guards to good effect, for example.) > Maybe the favicon.ico method is slightly transparent to the user as it's > not present when you view the source. the key difference of the favicon method (on fetchy ffoxes) is not just the source, but the frequent repeated requests triggered by the presence of a non-cached favicon. this is a versatile vector, as a tainted favicon need only be viewable (not actually on that page, in tabs, in bookmarks, etc) to trigger the requests. > Explain to me what I am missing here. perhaps you were expecting remote r00t in openbsd ip stack? :P~ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists