Thanks aditya, The code is not published on the blog post but it's visible in the video. It's very simple to reproduce this problem.
On 11/28/2012 1:53 PM, aditya wrote: > I totally agree with Christian, it is as insane as passing username and > passwords using GET > requests. But congrats Bogdan for the bringing to us a nice hack. > > Have u shared the code as well Bogdan? > > On Wed, Nov 28, 2012 at 5:07 PM, Christian Sciberras <uuf6...@gmail.com > <mailto:uuf6...@gmail.com>> > wrote: > > From an architectural perspective, "auto logins" or whatever they're > called should work through > a random string, just as most providers already do. > There is absolutely no reason to pass the username/password from a URL, > especially when in plain > text as in these cases. > Since there is no loss of features (there are safer, saner, sensible > alternatives), I think this > is better considered a bug, since it is never actually needed in the > first place. > > Also, with the random token system, I think it is best to still require > the user/pass when the > URL the user is directed to is going to do something such as > modifying/updating stuff. > > > Chris. > > > > On Wed, Nov 28, 2012 at 12:15 PM, Bogdan Calin <bog...@acunetix.com > <mailto:bog...@acunetix.com>> wrote: > > Yes, I agree with you. > > However, my opinion it that it should be fixed once and for all in > iOS/Webkit (and the other > browsers) by disabling resources loaded with credentials. > > At some point, as a protection for phishing, URLs with the format > scheme://username:password@hostname/ were disabled. > When you enter in the browser bar something like that it doesn't work > in most browsers. > > I was surprised to see that doing something like <image > src='scheme://username:password@hostname/path'> works in Chrome and > Firefox but if you enter the > same URL in the browser bar it doesn't work. This doesn't work in > Internet Explorer, which > is the > right behavior in my opinion. > > I don't see any good reason why something like this should work. > Closing this in browsers > will solve > this problem once and for all. > > On 11/28/2012 1:00 PM, Guifre wrote: > > Hello, > > > > "I can also confirm that this attack works on iPhone, iPad and Mac's > > default mail client." > > > > Of course, it works anywhere where arbitrary client-side code can be > > executed... IMAHO, the issue here is not your iphone loading images, > > there are millions of attack vectors to trigger this attack... The > > problem is the CSRF weaknesses of your router admin panel that > should > > be fixed by synchronizing a secret token or by using any other well > > known mitigation strategy against these attacks. > > > > Best Regards, > > Guifre. > > > > -- > Bogdan Calin - bogdan [at] acunetix.com <http://acunetix.com> > CTO > Acunetix Ltd. - http://www.acunetix.com > Acunetix Web Security Blog - http://www.acunetix.com/blog > Follow us on Twitter - http://www.twitter.com/acunetix > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > -- > Regards > Aditya Balapure > > -- Bogdan Calin - bogdan [at] acunetix.com CTO Acunetix Ltd. - http://www.acunetix.com Acunetix Web Security Blog - http://www.acunetix.com/blog Follow us on Twitter - http://www.twitter.com/acunetix _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
