Hacker News Reader

Comment by reginold | Hacker News Reader

Is there any sort of within-a-page HTTPS "secured" function?

Like how banks have that "only type your password if we show your correct profile picture". Almost like if embedded tweets could be "signed" by twitter in a way that would register in my browser in a graphical way that would not be known to the server itself (ie putting the twitter logo next to a tweet is easily faked). But if content appearing to be from twitter was verified instead, and had my custom chosen avatar next to each showing both my key and twitter's key had signed the text.

Maybe not making sense, if anyone wants to play this back clearer go for it :)

View on HN

I think it's difficult-to-impossible to do anything secure within a page, because a malicious page can emulate virtually any kind of behaviour within the page. https://textslashplain.com/2017/01/14/the-line-of-death/

(For example, if you had some sort of "signed iframe", the page would probably find a way to show the part from twitter that says "verified" but cover up the part that it's supposed to be actually verifying with something else).

Wow, this is a really great article. Thank you for sharing!

It discusses a fascinating point about browser UI: when the browser displays something inside its chrome, where a malicious page could render arbitrary pixels, it must establish a visual bridge back to the "trusted zone" (the chrome), providing proof that is in fact trusted content.

(The author points out that new APIs allowing writing to the entire screen means it's hopeless and we're all doomed though.)

> (For example, if you had some sort of "signed iframe", the page would probably find a way to show the part from twitter that says "verified" but cover up the part that it's supposed to be actually verifying with something else).

This is the part where I imagined having a custom client side image. That way the server doesn't know what the "verified" image actually looks like. Could be a picture of my face, for example.

> That way the server doesn't know what the "verified" image actually looks like.

Right, but it doesn't need to - it just has to construct a page that has the "verified" image on the left and the malicious URL on the right. Which is very difficult to rule out.

How would it construct a page that has the verified image if it doesn't know what the image looks like?

It would construct a page that includes a part that's genuinely verified (so the browser displays the verified image) and a part that's malicious, but arrange it so that it looks like the verification goes with the malicious part.

signed web bundles [1] let you package up a page as a fixed resource, distributed with a signature to verify that the content of that page is what the author intended it to be, so a site like twitter that is embedding it can be sure that what they're embedding is always the original resource.

however, this is part of AMP, and so web developers who prefer the "do whatever the fuck you want" aspect of the internet push back against it. the ability to ensure that a web link contains the same content at a future date as it did when it was initially crawled was one of the things we destroyed along with AMP.

[1] https://github.com/WICG/webpackage

> Like how banks have that "only type your password if we show your correct profile picture".

Do they? My banks did that years ago, and they also stopped doing it years ago.

Some still do. I don't see the point though - a determined attacker could just make http requests to your bank and substitute the parts they want to. Would be on the attack domain still so still technically phishing... But if the image is an anti phish measure it's not a great one. I suppose it could raise the bar to a successful attack a bit but certainly doesn't make it impossible.

Isnt't that what CORS/same-origin policies prevent? The attacker domain can be prevented from loading the bank resources within the same context by the browser. If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification.

In either case, the "correct profile picture" would not load.

Most people would not question having to type in their username for a fresh login - Banks sign you out so quickly and their "remember me" is often intentionally gimped. So users are trained to type their username into the field, and the bad site can proxy that to the bank and send back the image just fine.

Okta still includes this "feature" by default, and is among the reasons I will never trust Okta or any client of theirs.

You can keep iterating on this if you like, and some banks did, but ultimately the bad guy has the exact same information you've presented to the bank to get this "correct profile picture". Cookies. CORS headers. None of that matters. If you get the "correct profile picture" so does the bad guy and then they just forward it to you.

We already know how to actually solve this problem. WebAuthn.

> If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification.

Why is that a concern? You try to log in on a phishing site. The phishing site tries to log in as you at your bank's actual website. Your bank sends the phishing site your picture. The phishing site displays your picture to you.

The bank can and will use quite sophisticated request flow analysis to prevent one party from making too many attempts, so this means an attacker must grab a botnet or similar and be careful to avoid detection.

They are ineffective.

>Of the 63 participants whose responses to prior tasks had been verified, we were able to corroborate 60 participants’ responses to the removal of their site-authentication images. 58 of the 60 participants (97%) entered their passwords, de-spite the removal of the site-authentication image

See https://security.stackexchange.com/a/19801 which summarises https://sites.google.com/site/ianfischercv/emperor.pdf

Reply on news.ycombinator.com