You're missing the point

Shared hosting? Privilege escalation? Even if there were no MySQL installations in existance with an Internet facing network interface, this would still be a massive problem.

Macbook vs Thinkpad

I had two IBM Thinkpads, then a Macbook, and now a Lenovo Thinkpad (T420). I haven't noticed any difference in quality between the Thinkpads. They've all been great pieces of reliable kit. The Macbook on the other hand had numerous hardware failures in the 3 years I had it. The power supply died, the battery died, the hard drive died, and the plastic casing started flaking off.

SSL vs TLS

SSL v1.0 was never released to the public, SSL v1.1 and v1.2 never existed. I think you mean TLS. There's a really good summary of the history of SSL and TLS on Wikipedia:

https://secure.wikimedia.org/wikipedia/en/wiki/Transport_Layer_Security#History_and_development

TLS 1.0, otherwise known as SSL 3.1, came after SSL 3.0.

Irrelevant

Most sites don't check to make sure that the request was a POST rather than a GET. This is unimportant anyway, because creating cross-site POSTs is almost as easy as creating cross-site GETs:

<form method="post" action="https://target.site.example.com/changepassword.cgi">

<input type="hidden" name="newpassword" value="foo">

<input type="submit" id="submit" value="submit">

</form>

<script type="text/javascript">document.getElementById('submit').click();

There are defenses against this attack, but 99% of sites don't use them. And before you go off on one about sites requiring you to enter your old password as well, stop attacking the particular example, and think about the "class" of attacks that are available.

"That's a choice."

"That's a choice."

I know that you *can* enable certificate verification. I've done it myself in Exim. That only happens in very limited and minor cases though. Where the two communicating systems know each other and the administrators of both systems have a reason to want to enforce it.

I'd bet at least 99.9999% of SMTP traffic is either not encrypted, or encrypted without certificate verification.

No

In this attack, the cookies aren't being read using JavaScript. HttpOnly doesn't help.

"How does your browser know that a request from another tab to the same site should be blocked?"

It doesn't need to block anything. The "secure tab" gets its own cookie store. When you log into a site inside that secure tab, the secure tabs cookie store contains your session cookie. Any other tab that tries to launch an attack against the site, will be launching it against a site which it isn't logged into.

This would also allow people with multiple accounts at the same site to log in multiple times from different secure tabs.

I'm not convinced that the attack will *require* javascript to work. Will have to wait and see when it's demonstrated on Friday. If all it requires is lots of slightly different cross site requests, it can probably be initiated by injecting lots of hidden img tags or similar into the launch page, rather than injecting javascript.

He will only be susceptible to this attack if he visits other sites at the same time as being logged into the bank website. You shouldn't be doing this anyway because of the prevalence of XSS and CSRF vulnerabilities. This attack just gives you another reason.

SMTP can already be trivally MITMd

SMTP can already be trivially MITM'd because SMTP servers don't do any sort of certificate verification. Basically the majority of SMTP is unencrypted, and even that which is protected by TLS is "protected" by self signed certificates that aren't even checked/verified.

SMTP TLS is good for defending against passive observers opportunistically, but if somebody can intercept the connection, on either the sending *or* receiving side, you're screwed.

You misunderstood the attack

The javascript is being slipped into a http response from a site other than the target https site.

The trouble is, people visit https and http sites at the same time. If the target is logged into a https page, and then visits a http page on a different site. You can inject stuff into that http page that will initiate requests against the target site.

Eg, you could stick this bit of code in the http page if the target site is vulnerable to CSRF:

<img src="https://target.site.example.com/changepassword.cgi?newpassword=foo">

And if the target site doesn't use Strict-Transport-Security, and hasn't set the Secure flag on their cookie, you can cause the browser to initiate a non-ssl http request against the target to leak their cookie by simply slipping this into some unrelated http request to a different site:

<img src="http://target.site.example.com/">

You'll notice how both of those attacks work against browsers that have javascript disabled. This is why I use the Firefox addon RequestPolicy alongside NoScript.

This is incorrect

My understanding of the attack is that the attacker MITM's a random non secure http response body, and injects javascript into it, which initiates cross site requests from the target browser to the target https page. The attacker then watches the https traffic and can learn interesting information from it.

The fact that your bank has javascript in their pages doesn't help or hinder the attack.

As I use the Firefox addon RequestPolicy, I should be immune from this attack. The attacker wont be able to initiate the cross site requests unless I tell RequestPolicy to allow them.

PGP Email

Also, to use PGP on Android install APG (Android Privacy Guard). Then to use PGP with email install K-9. It's much better than the standard email client anyway, but it also plugs in to APG.

Solutions

"Or rather, no sign-up is needed. After all, every time you use a search engine (ANY search engine AFAIK), you give away data for free that ad agencies will use to slam targeted ads in your face."

https://ssl.scroogle.org/

https://duckduckgo.com/

"If you're on the Internet, they probably know all about you already"

https://www.torproject.org/

Firefox + AdBlock + Beef Taco + Flash Block + HTTPS Everywhere + NoScript

Worrying

Bugs are to be expected, but there's no reason to have things like XSS flaws and bad user input validation, even in "pre-alpha" software. That just suggests bad coding practice and generally sloppy programming.

Re: T-Mobile

Is that enforced? Ie, do they block ports/ips to prevent you from doing it?

VOIP != Streaming Music

"I already drive around streaming spotify without issues...until I go out to the countryside that is."

Streaming music over 3G bares no resemblance to VOIP over 3G. If you're streaming music, latency isn't an issue because it can buffer the content. You can't buffer VOIP though, even a small amount of latency would cause gaps in the conversation. You need a constant, stable, low latency connection in order to have a reasonable quality conversation and 3G simply doesn't provide that in practice.

VOIP over 3G works, but it sucks badly. I don't know why anyone would choose to use it. In fact, I doubt anybody does. Does anyone here do it? Has anyone here tried it and then gave up because of how shit it is?

Re: Free?

> Is this "free" as in "uses data allowance" for those not on an unlimited contract?

I would assume so. I'm on T-Mobile UK PAYG and with their £20/six months Internet booster I get "unlimited" (1GB) of bandwidth each month for £3.33, which is practically free.

JS not required

The flaw can be, and is, exploited without any javascript. It can be done entirely with css.