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

141–150 of 163 posts

Re: Google AdWords Exploit Seen in the Wild

#141

Post by alasdair_ »

soared wrote: post #106
amluto wrote: post #89

Earlier quoted context omitted.

Google's approach here seems totally wrong. The destination URL should be, exactly, the link as shown. If someone wants to track clicks using a third-party tracker, Google should offer an API for that which does not give the third-party tracker any ability to control the destination -- they have plenty of market power to impose this and, heck, they could even charge a small premium. Most browsers support a lovely fea…

That’s not the point of the tool - the point of the tool is to turn example.com/cms/category/subcategory/product into the easier to read example.com/product

>That’s not the point of the tool - the point of the tool is to turn example.com/cms/category/subcategory/product into the easier to read example.com/product

Then set up an explicit 301 or 302 on example.com to make this happen, don't hide it in the ad-serving layer.

Re: Google AdWords Exploit Seen in the Wild

#142

Post by rasz »

ocdtrekkie wrote: post #91
ariwilson wrote: post #85

Earlier quoted context omitted.

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…

Google has been doing this on google.com search page for ages before "upgrading" to ping

I used to run

   if((event.target.tagName.toLowerCase() === 'a') && (event.target.childNodes[0]) && (/^(http?:\/\/(www\.|encrypted\.)?google\.[^\/]*)?\/?url/.test(event.target.href))) {
      var matches = /[\?&](url)=(.+?)&/.exec(event.target.href);
      if (matches != null) {
        event.target.href = unescape(matches[2]);
      }
  }
nowadays if (link.ping) link.ping = null; is enough

Re: Google AdWords Exploit Seen in the Wild

#143

Post by scarface74 »

username223 wrote: post #42
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…

I also think mail clients should do that, or at least offer it as an option. Most mail readers have an option to disable loading remote content, and this would be another little way to make HTML email less dangerous. I think (or at least hope) that most people are in the habit of hovering over links in email before clicking them. And I really hope that mail readers never start implementing Javascript. As for web apps…

You give way too much credit to users if you think they hover over links and users can’t hover over links on mobile devices.

Re: Google AdWords Exploit Seen in the Wild

#144

Post by megous »

rasz wrote: post #142
ocdtrekkie wrote: post #91

Earlier quoted context omitted.

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…

Google has been doing this on google.com search page for ages before "upgrading" to ping I used to run if((event.target.tagName.toLowerCase() === 'a') && (event.target.childNodes[0]) && (/^(http?:\/\/(www\.|encrypted\.)?google\.[^\/]*)?\/?url/.test(event.target.href))) { var matches = /[\?&](url)=(.+?)&/.exec(event.target.href); if (matches != null) { event.target.href = unescape(matches[2]); } } nowadays if (link.pi…

browser.send_pings = false

on Firefox

Re: Google AdWords Exploit Seen in the Wild

#145

Post by luckylion »

shkkmo wrote: post #103
luckylion wrote: post #92

Earlier quoted context omitted.

> 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…

> We're taking away easy attacks What attacks are blocked by this that are not also blocked by using SPF and warning users when SPF is not present or doesn't match? > 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? This is practically irrelevant. We are discussing the costs/benefits of the implementation of a client side feature, not the ideal…

> My biggest concern is that we shouldn't do anything to teach people that sometimes they CAN trust the link text rather than needing to check the actual URL they end up at.

I don't believe that "copy link text to avoid tracking" is a relevant part here, so I still don't understand why you'd want to give the impression of a text-link with a different URL. I see lots of malicious reasons, but I don't see valid ones where there is a strong case that this is a necessity. Why should we teach users that "don't trust your lying eyes, just click on whatever" is ever a good idea? Why shouldn't we teach them to not touch something that is trying to deceive them? If we teach them to ignore these things, we're making it easier for scammers.

Sure, blocking links to domains that don't match the sender's may be something as well, but I do see lots of cases where that's totally normal, i.e. me sending you an email saying "hey, I read your blog entry, and this site here does what you want". Mind you, that's just a link, it's not a link that is trying to confuse you about it's true target.

> You do expose additional information about the user's clicks and IP address. If this is something your company is concerned with

If any company isn't concerned with that, they either don't do business in Europe or they should talk to a lawyer. ;)

> If you are trying to promote the use of first-party click tracking (or just discourage third-party click tracking)

Neither is my intent, I just don't see valid reasons to pretend you're linking to one URL when you're linking to another when there's an easy alternative: put words into the linktext, not URLs.

It's like FB's idea to pressure users into giving them their passwords for their email account. Terrible idea, no valid business case ("it's easy and we can really check that they are the owner of that email account" isn't valid), but lots of reasons for malicious actors, so somebody telling you "give me your email password" is a warning sign for everybody. Trying to confuse users about what URL you're linking to is as well.

Re: Google AdWords Exploit Seen in the Wild

#146

Post by dangrossman »

amluto wrote: post #89
arbuge wrote: post #48

Earlier quoted context omitted.

It appears here that the redirection to the ebay.com destination url is not happening and that the user ends up on a different domain. That kind of situation is usually detected when ads are entered into the Google Ads* platform for review, with ads then rejected for "destination url mismatch". One thing checked is that the final destination url after all redirects matches what is specified in the ad's final url fiel…

Google's approach here seems totally wrong. The destination URL should be, exactly, the link as shown. If someone wants to track clicks using a third-party tracker, Google should offer an API for that which does not give the third-party tracker any ability to control the destination -- they have plenty of market power to impose this and, heck, they could even charge a small premium. Most browsers support a lovely fea…

Google already works like this in browsers that support it (most modern ones). The ad is linked to the destination URL with no redirects through any advertiser-controlled domain. A third-party tracking URL can be specified, and it will be pinged in the background using the browser's sendBeacon() function. Any redirects in response to the ping don't affect what webpage the browser displays, so they can't be used to hijack the click.

https://support.google.com/google-ads/answer/7544674?hl=en

Re: Google AdWords Exploit Seen in the Wild

#147

Post by Godel_unicode »

TeMPOraL wrote: post #130
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.

I'm partial to a simpler and complete solution: just always force display of href text on hyperlinks, ignoring the markup that's between and . Nothing good comes from displaying the text/image instead of the actual URL; at best it's used (usually overused) for extra aesthetic touch that's not otherwise useful, at worst it's used by advertisers and scammers to lie to people about the link's destination (tracking links…

I guarantee you that I can craft URLs users will click even if the whole URL is exposed. This "solution" makes developers feel better but provides essentially zero additional security.

Re: Google AdWords Exploit Seen in the Wild

#148

Post by jake_the_third »

TeMPOraL wrote: post #132
gknoy wrote: post #125

Earlier quoted context omitted.

Can you elaborate on what "brick wall UX" is like to use as a user, or how one implements it? Are there known examples you could point me at? (It's a term I haven't heard before, and haven't noticed anything when searching.)

I don't think it's a known term; it seems something GP created. As for how it works, the concept is simple: if the user wants to do the wrong or potentially insecure thing, just don't let them , period. That's the brick wall. I'm of two minds about this personally. On the one hand, I appreciate the argument that the only thing that can prevent businesses from doing something bad, stupid or abusive is if it's legally,…

Unless the developer has enough foresight to account for, and sufficiently handle, every single instance where that brick wall would stop a legitimate false positive, I stand vehemently against them.

There are enough examples in the past that clearly demonstrate that developers are not benevolent or competent enough to have complete and final control over the software their users run. Sometimes this control even results in the exact opposite of what the developers originally intended, as was the case with firefox addons just a couple of days ago.

Ultimate control over software should always reside in the hands of the user.

Re: Google AdWords Exploit Seen in the Wild

#149

Post by Godel_unicode »

TeMPOraL wrote: post #132
gknoy wrote: post #125

Earlier quoted context omitted.

Can you elaborate on what "brick wall UX" is like to use as a user, or how one implements it? Are there known examples you could point me at? (It's a term I haven't heard before, and haven't noticed anything when searching.)

I don't think it's a known term; it seems something GP created. As for how it works, the concept is simple: if the user wants to do the wrong or potentially insecure thing, just don't let them , period. That's the brick wall. I'm of two minds about this personally. On the one hand, I appreciate the argument that the only thing that can prevent businesses from doing something bad, stupid or abusive is if it's legally,…

> as a pro user, I do appreciate the ability to override software when it mistakenly tries to prevent me from doing something.

This is really the core problem in security; the world is designed for people like this by people like this, without any serious thought for the implications for the overwhelming majority of users. Do not include "I know what I'm doing" escape hatches, and security will magically get better for the many at the expense of convenience for the few.

Re: Google AdWords Exploit Seen in the Wild

#150

Post by Godel_unicode »

kevin_thibedeau wrote: post #102
amenod wrote: post #98

Earlier quoted context omitted.

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

They should just collect stats on their own servers.

This might come as a surprise to you, but every company doesn't have infinite developer time to reinvent things which already exist.
Post reply on HN