Hacker News Reader

Comment by relkor | Hacker News Reader

My concern would be getting a link that I am supposed to follow where I input my debit card number. Can someone explain how I know that text message -- which can be sent by anyone to me -- has a valid link to money? I would be extremely suspicous if I got a message saying "Hey its Peter, I can pay you back for $THING, just follow <link> and enter your debit card number to recieve $AMOUNT right now"

View on HN

I'd assume <link> is a google.com domain, which one could, in theory, trust. The page, on the trusted domain, would also clearly state the same information, "enter your debit card number to receive $AMOUNT from $PERSON (and profile pic probably) for $THING

You're right, but the average person isn't very discriminating or very able to keep track of who can and cannot be trusted, so I would expect problems to occur.

Is the concern here phishing? Checking that the page is HTTPS and the domain is *.google.com should be sufficient to thwart phishing attempts. Of course, your attack would still work against uninformed users, but you can protect yourself by always being sure to check the URL.

It is not always enough. For example, recently I have found several ways to spoof the URL and HTTPS lock on Google Chrome. So phishing seems to be a concern.

If you found a way to have the address bar show an HTTPS lock on a Google domain despite actually being on one, then you've found a big hole and you could make a lot of money by reproducing/reporting this security flaw.

The fact that you have found "several ways" is intriguing. You are either mistaken, or you're one of the greatest security researchers out there.

I already did report them. The first one was fixed (CVE-2015-6782), got $1k from Google. There are three more they are working on.

In that case, way to go, that is very impressive! I'm surprised the bounty was so low, honestly.

In response to your first comment, I should clarify that checking for a valid HTTPS URL SHOULD be sufficient, barring implementation errors in the browser. Of course, if the browser is insecure, all bets are off wrt web security. Implications may range far beyond phishing attacks in that case.

Thank you! I got involved with the security world recently and I'm really enjoying it. And I would like to clarify myself, the comment I made earlier was a little ambiguous. The bug that got fixed only spoofs the omnibox and not the HTTPS lock. The others spoof both. That said, when I am able to disclose these vulnerabilities, I intend to write a post about them.

You should, I would love to read that :)

>Of course, if the browser is insecure, all bets are off wrt web security.

I guess this is a no go for now, then?

>There are three more they are working on.

Wow, this thread reminded me of the "best HN comeback of all time":

https://news.ycombinator.com/item?id=35079

Reply on news.ycombinator.com