Scareware slingers stumped by Google secure search
Scam sites can't game search results
Last month Google made secure search the default option for logged in users – mostly to improve privacy protection. But there is a beneficial side-effect - it is harder for fraudsters to manipulate the search engine rankings of scam sites.
Users signed into Google are now offered the ability to send search queries over secure (https) connections last. Search queries sent while using insecure networks, such as Wi-Fi hotspots, are no longer visible (and easily captured) by other users on the same network.
When secure search is used Google omits from the HTTP referrer header the search terms used to reach websites. This makes it harder for websites to see the Google search terms that directed surfers to their pages. Also it is harder to tune content without using Google's analytics service.
The change in the referrer header makes life much more difficult for black hat SEO operators, who strive to make scareware portals figure prominently in 'newsworthy' search results. These fraudsters commonly use link farms to manipulate search results.
Fraudsters typically set up multiple routes through to scam sites. Surfers who stray onto scareware sites are warned of non-existent security problems to coax them into paying for fake anti-virus software of little or no utility.
Black hats thwarted
The changes introduced by Google when it launched secure search will leave them clueless about which approaches are bringing in prospective marks and which have failed.
David Sancho, a senior threat researcher at Trend Micro, explains that it is very useful for black hat SEO-promoted sites to know which search term they have successfully hijacked, - information that Google's changes denies them.
"When these sites receive visits from search engine visitors, they will have no idea what search sent them there," Sancho writes. "They won’t have a clear idea which search terms work and which don’t, so they are essentially in the dark. This can have a lot of impact on the effectiveness of their poisoning activities. This is, of course, good for Google as their search lists are cleaner but it’s also good for all users because they’ll be less likely to click on bad links from Google."
Regular no-padlock HTTP searches remain unaltered. Search terms are only concealed where secure search is applied, which means surfers are already logged in to Google’s services.
"Given how many people already use Google Mail and Google+, this may not be such a big obstacle – but it still poses one," Sancho explains. "If people keep using regular no-padlock HTTP searches, they will keep disclosing their search terms and keeping things unchanged."
"The more people use HTTPS, the less information we’re giving the bad guys ... one more reason to use secure connections to do your web searching," he concludes.
Google introduced encrypted search last year but changes that came in last month that make it a default option for logged-in users will inevitably mean that it becomes more widely used, rather than the preserve of security-aware users who are unlikely to fall victim to scareware scams in the first place. ®
Not on .co.uk
Google only defaults to https on google.com, If you're a logged in UK user on the .co.uk domain, you still default to unsecured http:
Logically, if you need to suppress the Refer(r)er header when you cross from https to http for privacy reasons, it only makes sense to do the same when you cross from one domain to another when using https for both (since you don't want sensitive information from example.com to get logged in the access log for nosey-buggers.net)
Therefore, regardless of what rfc2616 requires browsers actually do, suppressing all referral information would actually be in the spirit of the document, while passing potentially sensitive information along would not.
I have no idea which google actually do, but since they call it "secure", I'd imagine they do the sensible thing and suppress for all.
rfc2616 isn't for google to play by -- it's the browser that does not send the refer(r)er field if it's crossing from a secure request to an insecure request, not the server.