iphone's ambiguous http-auth

I'm a little disappointed at Apple. While I think the iPhone is a pretty nice piece of work and their browser is pretty nice too, I don't like the way it handles HTTP-AUTH. (There are other gripes I have, like no "find" feature in safari or the mail app, but we'll stick with a security problem for now). Most browsers are kind enough to display on the "safe" pop-up login box which which website requested the authentication. This is not so with iPhone Safari.

Not only does the pop-up "enter your password" box fill the whole screen (a rather necessary evil), but it doesn't display the domain, URL or any information about the website where you're sending your credentials. If I had some free time, I would hack together a quick demo to show how, using iframes (suitably) or images, I can make you think you're logging into one site but you are actually sending your password to another one entirely. It does indicate whether you are sending your password in the clear or if the connection is secured with TLS/SSL, but in a subtle gray font under the login boxes.

I want to know where my password goes!

bad security assumption

Good assumption:

My domain (DNS) name is not safe from forgery. Bad people might "hijack" it and use it to pretend they are me.

Bad assumption:

If my domain name is hijacked or spoofed, then I lose control of all the subdomains too. This means that if someone else pretends to be sidstamm.com then they will also take control over blog.sidstamm.com, mail.sidstamm.com and ohcrap.sidstamm.com.

Bad: DNS spoofing is done on the record level, and since each subdomain happens to be a different record, an attacker might control one subdomain and let you retain control over the rest.

Consequence of this: The same-origin policy enforced by most browsers says this: scripts served by one host cannot access, execute or change data served by another host. In this case b.a.com and a.com are considered different hosts.

There is one exception to the rule: a website may change its "document.domain" property to a suffix of what it currently might be. For example, a page served by b.a.com may set its domain to a.com AFTER it is served. In this case, b.a.com can play with a.com's data.

Your data is no longer safe, unless you control all of your subdomains. The case used to be simpler: a phisher or pharmer must create a complete duplicate of a site to fool with it. Now, he just creates a parasite frame, and watches you interact with the real thing. Beware of visiting update-security.yourbank.com.

Scary.

(Link to Abe Fettig's explanation)
(Link to Same-Origin Policy info)