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 <uuf6429 () gmail com<mailto:
uuf6429 () 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 <bogdan () acunetix com
<mailto:bogdan () 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
