Comment Re:Look for the "https:" (Score 1) 205
Please prove me wrong on this one if you are able, but to all my knowledge, changing the address bar with JavaScript is impossible. JavaScript can read the URI, and can write a new URI via the "window.opener.parent.location" object, but cannot change the address bar without changing the URI (thus executing the new request). This would have to be accomplished via URL rewriting software or modules on the Web server, which the attacker has control over, but I'm not 100% sure (as in, I have not done so myself) if you can change the protocol using rewrites, though it's been suggested via documentation that you can. Even if you could, I don't see why any modern browser wouldn't still verify the existence/validity of an SSL Certificate, even with a rewritten URL. That's just faith-based, though :).
I've worked with WebApp security for a few years now, and the worst I've seen JavaScript capable of in this time has been XSS, which is not exactly a vulnerability of JavaScript. I'd also love someone to provide some examples if JS is indeed so vulnerable.
Regardless of the SSL Certificate issue you brought up, though an entirely valid point, I could think of many social engineering methods around the need to technically "break" SSL here. For example, they've already connected to my Web server via my localized DNS attack, and I simply need the "secure" login page to be hosted on a domain which I have authority over. As those of us who work with SSL know too well, you only need to own a domain name to register a certificate to it. If the attacker is concerned with people not accepting the site due to a bad certificate (which the majority of users still will not understand as a breach), they simply change the login page to a valid SSL domain, fooling the majority of the remaining users who simply look for validated SSL. Many banks do not use trademarked domain names for login pages, so I myself have a hard time verifying the validity of some SSL sites I end up on.
I was shocked to hear this attack had never been witness "in the wild." Of course it has been theorized for a long time, but I gave our blackhat counterparts a little more credit than that.
I've worked with WebApp security for a few years now, and the worst I've seen JavaScript capable of in this time has been XSS, which is not exactly a vulnerability of JavaScript. I'd also love someone to provide some examples if JS is indeed so vulnerable.
Regardless of the SSL Certificate issue you brought up, though an entirely valid point, I could think of many social engineering methods around the need to technically "break" SSL here. For example, they've already connected to my Web server via my localized DNS attack, and I simply need the "secure" login page to be hosted on a domain which I have authority over. As those of us who work with SSL know too well, you only need to own a domain name to register a certificate to it. If the attacker is concerned with people not accepting the site due to a bad certificate (which the majority of users still will not understand as a breach), they simply change the login page to a valid SSL domain, fooling the majority of the remaining users who simply look for validated SSL. Many banks do not use trademarked domain names for login pages, so I myself have a hard time verifying the validity of some SSL sites I end up on.
I was shocked to hear this attack had never been witness "in the wild." Of course it has been theorized for a long time, but I gave our blackhat counterparts a little more credit than that.
