Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google AdWords Exploit Seen in the Wild

wp.josh.com

Post reply on HN
Print view View original

91–100 of 163 posts

Re: Google AdWords Exploit Seen in the Wild

#91

Post by ocdtrekkie »

ariwilson wrote: post #85
ocdtrekkie wrote: post #49

I've reported this back in 2017: https://news.ycombinator.com/item?id=13413399 (Though the screenshot was on G+, so RIP.) It's even been done to youtube.com before! Clicking ads is inherently dangerous, as they are allowed to show URLs which do not reflect the URLs they will actually route you to. You should never click on an ad. This is a scenario that violates any reasonable convention of good web behavior, but Goo…

Isn't this true about any link?

No. If you hover over a link in your web browser, regardless of what it says on the link, the hover text (often appearing at the bottom left of your web browser) should show you the real, full destination URL. Try hovering over any link in HN, and you'll see the URL you're going to actually go to when you click on it.

However, when you hover over a Google Ads link, it does not do this. It shows you a friendly URL for the destination (such as https://www.ebay.com) but when you click on it, you get redirected with a bunch of tracking stuff added or even through a URL not on the ebay.com domain, as shown in this "exploit". In fact, even if an advertiser were to use a "clean" link as the destination, you first get redirected on that click through a google.com URL, even though the hover text is still lying about the destination.

I'm not even sure what it's doing here, there's some neat JavaScript in play. The hover text shows the "clean" URL, but if I inspect it, and then hover over it again, it shows the real redirect URL through google.com.

Re: Google AdWords Exploit Seen in the Wild

#92

Post by luckylion »

shkkmo wrote: post #87
luckylion wrote: post #81

Earlier quoted context omitted.

> Why? If you don't want to be tracked it is pretty easy to avoid. If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? And why would the link text look like a URL? I don't see why www.ebay.com/viewOrder makes more sense than view your order . > Even if it is a password reset email or a email verification email? Why would you want to share password reset info with a third party…

> If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? I don't see what relevance a subdomain has here. As the original issue was described, it was blocking any links where the url doesn't match the link text (if the link text is a url). This means that even tracking that is done on the same domain (e.g. example.com/emailTracking/{{unique_string}} redirects to example.com/viewO…

> Are we really promoting good security practices or just adding security theater cruft?

We're taking away easy attacks, just like blocking known spammers from delivering emails to your MTA. Yes, it doesn't solve spam completely, but it reduces the amount. Add other things like SPF, DKIM etc and you can identify even more malicious emails and warn the user. And certainly, the OP's description mentioned matching urls (though the text would have to match the href, so "ebay.com" would likely be fine for "https://ebay.com/something"), but again: what's the harm in linking to the actual URL? Why the need to hide it, IF you already make the link text look like a URL? I'm sure there are also reasons why a site operator wants to avoid SSL, but I do like the fact that many browsers do warn users when (potentially) sensitive data gets transmitted via plain text.

> Who said anything about a third party?

The super majority of click-tracking runs via third parties. And yes, every additional detail you share with them (PII has gotten a lot of attention lately, and I'm beginning to come around and love GDPR) will put your users more at risk - now it's not just your database that risks exposing your users when a leak/breach happens, it's also your email provider's.

> How would you implement link url / text mismatch blocking? Have you thought through the consequences for your users and their understanding of security or satisfaction with your product?

I'm sure that it's not trivial, but few things are, so rejecting it for that reason doesn't sound like a good idea to me. "Hey, let's not do SSL, it's not that simple to build and might inconvenience a user that has their clock set 100 years into the future"

Re: Google AdWords Exploit Seen in the Wild

#93

Post by [deleted] »

ariwilson wrote: post #85
ocdtrekkie wrote: post #49

I've reported this back in 2017: https://news.ycombinator.com/item?id=13413399 (Though the screenshot was on G+, so RIP.) It's even been done to youtube.com before! Clicking ads is inherently dangerous, as they are allowed to show URLs which do not reflect the URLs they will actually route you to. You should never click on an ad. This is a scenario that violates any reasonable convention of good web behavior, but Goo…

Isn't this true about any link?

[deleted]

Re: Google AdWords Exploit Seen in the Wild

#95

Post by Goronmon »

syn0byte wrote: post #65
herodotus wrote: post #39

When I worked at Apple I filed a Radar (bug-report) asking for the mail client to check that, if the text of an tag was a url, that the text matched the href field. What followed, on the Radar, was a lengthy debate about this. If I recall correctly, the people who opposed basically argued that, if this feature was implemented by the mail client, spammers would simply find another way to inject false links. We (those…

Sounds reasonable only if the text is a URI handler format; http:// file:// ftp:// steam:// etc. But then what about almost-uri text. www.yourbank.com without the https:// . Or lookalikes "https:\\" or... what about proxies? does https://l33th4x.com?proxy=www.bank.com count if the text is www.bank.com? Filtering crap like this sounds reasonable but very quickly becomes an exercise in what I call "Giving a mouse a coo…

Filtering crap like this sounds reasonable but very quickly becomes an exercise in what I call "Giving a mouse a cookie." Now you have a huge complex chunk of code to parse and filter URLs/URIs and every look-alike you can think of; Did you remember that automatic deserialization that kicked in when your values were sent to a callback?

This sounds an awful lot like how software development in general works...

Isn't all software just some version of "Giving a mouse a cookie."?

Re: Google AdWords Exploit Seen in the Wild

#96

Post by downandout »

This isn’t an exploit per se. it is a misuse of a feature. Google has long allowed the display URL to differ from the actual destination URL, and if this weren’t the case this would cause significant problems for advertisers because many link their ads to offsite tracking domains. It’s a feature, not a bug.

Re: Google AdWords Exploit Seen in the Wild

#97

Post by jlarocco »

mikeash wrote: post #72
jlarocco wrote: post #68

Earlier quoted context omitted.

I'm agreeing with the "no" votes here. It's extra work and testing complexity for a one off case that's trivially avoided by spammers. And where do you draw the line? Should it flag a link with text "htp://ebay.com" that goes somewhere else? "ebay" with a href somewhere else? There's no technical workaround to educating users.

Sandboxing to prevent malware installation and password managers to prevent phishing are excellent technical workarounds for this.

Except they're not, because a dumb enough user isn't going to think about their password manager, and they'll enter their password anyway.

Re: Google AdWords Exploit Seen in the Wild

#98

Post by amenod »

cesarb wrote: post #76
herodotus wrote: post #39

When I worked at Apple I filed a Radar (bug-report) asking for the mail client to check that, if the text of an tag was a url, that the text matched the href field. What followed, on the Radar, was a lengthy debate about this. If I recall correctly, the people who opposed basically argued that, if this feature was implemented by the mail client, spammers would simply find another way to inject false links. We (those…

At least Thunderbird seems to do that: when an email has an tag with text that looks like a URL but doesn't match the href, it throws the "this email is probably a scam" bar above the message.

...which then marks all these newsletters as scams, since the link usually first points to analytics site?

Re: Google AdWords Exploit Seen in the Wild

#99

Post by mikeash »

jlarocco wrote: post #97
mikeash wrote: post #72

Earlier quoted context omitted.

Sandboxing to prevent malware installation and password managers to prevent phishing are excellent technical workarounds for this.

Except they're not, because a dumb enough user isn't going to think about their password manager, and they'll enter their password anyway.

They won’t even know what it is.

Re: Google AdWords Exploit Seen in the Wild

#100

Post by griffoa »

herodotus wrote: post #39

When I worked at Apple I filed a Radar (bug-report) asking for the mail client to check that, if the text of an tag was a url, that the text matched the href field. What followed, on the Radar, was a lengthy debate about this. If I recall correctly, the people who opposed basically argued that, if this feature was implemented by the mail client, spammers would simply find another way to inject false links. We (those…

> When I worked at Apple I filed a Radar

There is your first problem right there. Never have I seen actual incompetence systematically implemented, but Apple managed to do exactly that.

And the talking and blabbering and bike shedding culture at Apple to prove you are the smartest person in the room is excruciating.

Post reply on HN