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

61–70 of 163 posts

Re: Google AdWords Exploit Seen in the Wild

#61

Post by dymk »

nullwasamistake wrote: post #53
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…

Wow it seems trivial to trick Google's bots with these links. Have the page redirect until ad is approved, profit? I'm sure it's easy to find their bot IP's too. Just make a bunch of terrible ads that nobody will click and see who visits the url. Google needs to abolish this link policy, I don't see how it's enforceable

This is called "cloaking", and it's a cat and mouse game between ad networks and bad actors. You're describing the simplest thing that can be done to cloak a website from an automated checker, but there's far more advanced techniques as well.

Re: Google AdWords Exploit Seen in the Wild

#62

Post by shkkmo »

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…

> the mail client to check that, if the text of an tag was a url, that the text matched the href field.

The use case that this breaks is doing click tracking on links using redirects from a unique url to the actual url (which would be the url displayed in the link text).

To avoid breaking this use case, the best remedy would be to prompt the user with a security warning upon clicking a mismatched link prompting them the verify the url in the url bar. The issue, is that doing this selectively teaches the wrong security practice to users: that they can improve their safety by looking at the link text rather than at the url bar after clicking the link.

Re: Google AdWords Exploit Seen in the Wild

#63

Post by tmefq »

jdironman wrote: post #50
username223 wrote: post #42

Earlier quoted context omitted.

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…

Maybe, quite simple have the option to parse tags down to the format "Text - URL". If I remember correctly, some sites from way back had this sort of format occasionally.

WordPress does it in the admin interface. A very clever hack. Something like:

    a:after {
        content: attr(href);
        display: inline-block;
        padding: 0 1ex;
    }

Re: Google AdWords Exploit Seen in the Wild

#64

Post by yellow_postit »

blakesterz wrote: post #9

Every once in a while I'll do a search on Google from a browser with no blocker for something like 'ebay' or some other big brand name and I'm always surprised to see that big brand name has bought ads for themselves, it never made sense since they're always the first search result anyways. Now I can only assume two things... 1. Some number of those ads were scams 2. Some large number of people just blindly click on…

By controlling more screen real estate you will get even more clicks to your website. Given the incremental cost for a nav query is so low for the first algo it is a good decision.

Re: Google AdWords Exploit Seen in the Wild

#65

Post by syn0byte »

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

2 days of work later, your new build has fancy-pants a tag filtering that contains and unknown number of bugs and phishers just register and use new domains that look kinda legit and follow your new text/link rules. www.security-wellsfargo-audit.com/login looks legit to the mark, your mail client allowed it so it must be OK.

Re: Google AdWords Exploit Seen in the Wild

#67

Post by appleflaxen »

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…

uh... ok... I'll bite... why do you call it "giving a mouse a cookie"

Re: Google AdWords Exploit Seen in the Wild

#68

Post by jlarocco »

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'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.

Re: Google AdWords Exploit Seen in the Wild

#69

Post by smallbigfish »

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…

That filtering code should already be there in web app.

Re: Google AdWords Exploit Seen in the Wild

#70

Post by the_jeremy »

appleflaxen wrote: post #67
syn0byte wrote: post #65

Earlier quoted context omitted.

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…

uh... ok... I'll bite... why do you call it "giving a mouse a cookie"

Let me google that for you: https://en.wikipedia.org/wiki/If_You_Give_a_Mouse_a_Cookie
Post reply on HN