full-disclosure - Re: The email that hacks you

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD6s_XsgJV0gwTr2sAzzf--wuet+cNq5evsP62gBsD4kSEZCaA@mail.gmail.com>
Date: Wed, 28 Nov 2012 12:37:19 +0100
From: Christian Sciberras <uuf6429@...il.com>
To: Bogdan Calin <bogdan@...netix.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: The email that hacks you

>>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@...netix.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@...tname/ 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@...tname/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
> 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/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/