My name is Matt Jones, and I work on the Facbook security team that looked into this tonight. We only send these URLs to the email address of the account owner for their ease of use and never make them publicly available. Even then we put protection in place to reduce the likelihood that anyone else could click through to the account.
For a search engine to come across these links, the content of the emails would need to have been posted online (e.g. via throwaway email sites, as someone pointed out - or people whose email addresses go to email lists with online archives).
As jpadvo surmised, the nonces expire after a period of time. They also only work for certain users, and even then we run additional security checks to make sure it looks like the account owner who's logging in. Regardless, due to some of these links being disclosed, we've turned the feature off until we can better ensure its security for users whose email contents are publicly visible. We are also securing the accounts of anyone who recently logged in through this flow.
In the future if you run into something that looks like a security problem with Facebook, feel free to disclose it responsibly through our whitehat program: https://www.facebook.com/whitehat. That way, in addition to making some money, you can avoid a bunch of script kiddies exploiting whatever the issue is that you've found.
It shouldn't take you more than one Google query to find the place to report Facebook security problems.
I don't think it's a good idea to link it from the general support section -- you don't want the security team that is hopefully carefully monitoring this stuff to have to wade through thousands of regular customer service complaints.
It shouldn't... but it could be easier. I've been in the situation before where I wanted to report malware on facebook and I couldn't figure out where to report it.
I agree that you don't want reporting a security issue to supersede the general case of problems, but as things stand it is hard to figure out how to report a real security issue if you don't know about that magic whitehat url.
this one has a Report Something link... but that doesn't give you options for reporting a security issue, just TOS violations or copyright infringement.
Just to recap, in order to find how to submit a security bug report, it took me 15 minutes and I still only found it because I knew the term to look for was "white hat" and not "security".
Perhaps you're right. But "Facebook report a vulnerability" works just fine and that's what I would have tried if I were trying to report a vulnerability.
And you'll find at the time of writing 250.000 more results where the "wants to be friends" email with the auto-login link is posted on blogs. Many of these blogs are also hacked, in that they redirect you to Russian dating sites if you visit the homepage.
I must have made a typo at "don%27t". I corrected the first query and it now returns 238.000 results for me again.
Perhaps some Blogspot sites got hacked/ their users phished (I noticed suspicious posting activity dating back to November 2011), which would explain how they got access to the emails. Or these accounts are all fake (selling likes) and they use Blogspot to create online persona's and manage their accounts.
- Information disclosure vulnerability: you'll see the email of the Twitter user [username]
- DoS vulnerability: you can click on the "I did not sign up for this account" button. After that, the Twitter user [username] email will be removed from the [username] account.
The URLs don't need to be posted online. Some browsers (Chrome, possibly Firefox with Safe Browsing mode, very likely any browser with a Google Toolbar installed) send visited URLs to Google and they will be indexed. I don't know if this is officially documented by Google, but several people have reported seeing this while testing new/beta websites that weren't published or linked anywhere.
I noticed a new twist in your post though: you're saying that because of Safe Browsing (which checks for e.g. malware as users surf the web), those urls are sent to Google. The way that Chrome and Firefox actually do Safe Browsing is that they download an encrypted blob which allows the browser to do a lookup for dangerous urls on the client side--not by sending any urls to Google. I believe that if there's a match in the client-side encrypted table, only then does the browser send the now-suspect url to Google for checking.
Here's more info: https://developers.google.com/safe-browsing/ I believe the correct mental model of the Safe Browsing API in browsers is "Download a hash table of believed-to-be-dangerous urls. As you surf, check against that local hash table. If you find a match/collision, then the user might be about to land on a bad url, so check for more info at that point."
Sorry but don't believe you about google toolbar. I had a private page with no links in or out and yet it appeared in google search. It was not guessable and there was no chance for a referrer link. The page was never shared with friends nor accessed outside my own computers.
I only found out when a friend searched for his name and the page appeared as it was my phone list
The most common way such "secret" pages get crawled is that someone visited that secret page with their referrers on and then goes to another page. For example, are you 100% positive that every person who ever visited that page had referrers turned off on every single browser (including mobile phones) they used to access that page?
Are you sure that it is the referrer headers? PP clearly stated there were no outgoing links on the secret page. I think there's a much more mundane explanation: javascript stuff downloaded from Googles CDN.
People nowadays are so used to just plopping jQuery etc. into their web pages that they forget that this stuff has to come from somewhere. If it's from Google, I'm quite certain that their CDN loader phones home right before it gives up any of the good stuff.
EDIT: Confirmed, though I was wrong in that there's no loader, requesting jQuery from ajax.googleapis.com gives them a nice fresh Referer header pointing at your secret site for their spiders to crawl. Be mindful!
an old meme, and my usual recommendation: just test it: create a page that i not linked from anywhere. visit it with the browsers mentioned above. watch the logfiles. wait for it. nope, no googlebot request. it is unbelievable easy to test, i have done so on various occasions in the past, so there is no need for you to spread a "several people have reported" rumor. just ... test ... it.
as for the old stories, that google does this kind of thing: people, especially SEOs or people who think they know SEO, always blame google. oh, my beta.site has been indexed, it must be because of ... google is evil.
most of the times i have seen cases where googlebot found a not published yet site it was because of (just some examples, not a complete list) i.e.:
* turned on error reporting (most of the PHP sites)
* the URLs were already used in some javascript
* server side analytics software, open to the public
* apaches shows file/order structure
* indexable logfiles
* people linked to the site
* somebody tweeted about it
* site was covered on techcrunch (yes, really)
* all visited URLs in the network were tracked by a firewall, the firewall published a log on an internal server, the internal server was reachable from the outside
* internal wiki is indexable
* intranet is indexable
* concept paper is indexable
testing your hypothesis "chrome/google toolbar/... push URLs into the googlebot discovery queue, which leads to googlebot visits" is easily testable. no need to spread rumors. setup for testing this: make an html-page (30 seconds max, basically ssh to your server, create a file, write some html), tail & grep logfiles (30 sec max), wait (forever)
When you add the +1 button to a page, Google assumes that
you want that page to be publicly available and visible in
Google Search results. As a result, we may fetch and show
that page even if it is disallowed in robots.txt.
I can understand adding a +1 button to a dev site, and then not understanding why it shows up in the index.
Don't forget people who may have * installed UserScripts / GreaseMonkey scripts * Browser plugins other than Google Toolbar which may send stuff to the big G * (Self-)modded browsers which send out stuff to wherever...the list goes on and on indeed.
Best thing to do to keep a site secret:
* Don't host it on the internet (d'uh)
* Hide behind a portal page and have that and your server weed out misconfigured / hijacked browsers before any can proceed to your real secret site (also see web cloaking).
I'm not sure either, but I doubt that Chrome or any of the badware-stopping features that are built in to it cause the URLs they're checking to be indexed. I'd be even more surprised if Firefox did this.
If you've got the toolbar installed though, I'd be less surprised if they tried crawling or indexing URLs you go to.
At least in terms of malware detection, Chrome utilises a bloom filter in the first instance to identify the probability of a URL being malicious before making remote calls. If it is found to be positive, only then does it submit it to Google for more precise verification.
> EDIT: It looks like they've explicitly said the toolbar does not cause things to appear in search results
I read this too after posting, but I'm skeptical. It wouldn't be the first time they claimed to not do things they later admitted doing ... The rationale being that search engines need a way to discover new URLs quickly and keep ahead of the competition (indexing speed and breadth).
I'd also like to know what exactly Google Desktop Search does with URLs it finds.
Robots.txt is about fetching content, it has noting do to with indexing URLs or anything which is part of the content at non-robots.txt restricted locations.
Whether google sends the urls to itself or not can be easily decided by using a http monitoring tool like fiddler and with hosts filter we can narrow down the traffic to google.com
Leave it running for few days you will see for yourself
A robots.txt file disallowing crawling on the sites that display the contents of user email would help fix this.
However, as some of the discussion below points out, I don't believe that disallowing crawling of these URLs in our robots.txt would keep them from the index if a search engine finds reference to them elsewhere; I think it simply keeps them from being crawled.
(Regardless of whether one has a Facebook account or not) If your theory is correct, this seems like a good reason to not use Chrome or any browser with a Google Toolbar :)
My name is Jared Null, and I first reported this as a vulnerability back in March to the bug bounty program. I've posted one conversation here: http://news.cnet.com/8301-1023_3-57544933-93/facebook-passwo.... I'm confused, you say that its not a vulnerability, yet Facebook had to take action. I guess seeing is believing and it only took a public disclosure to see the light. The sad thing is I reported both the recover password link and the checkpoint link "https://www.facebook.com/checkpoint/checkpointme?u= (which by the way is still vulnerable), the checkpoint links are reusable but the recover password links were one time use.
You mention that the nonces expire after a period of time.
If you don't plan on cutting the feature for ever, perhaps you could consider an alternative approach of limiting the validity of the URLs to the first visit and also removing the email-id (and other PII data) of the user from the URL.
The feature is absolutely too dangerous to ever have existed!
It turns out that Facebook implemented the plain links that are more powerful than the password reset procedures, considering the easiness in taking over the account of another user.
Having the actual user id in the link is just a small topping on that cake, not even worth to discuss as long as the "no login just click the link" possibility remains to exist.
When did the term "nonce" start being used in web application development to refer to a token that expires after a period of time instead of being a true one-time use number/token?
Hi, My account was hacked at the weekend and although it is locked the person still keeps changing my password and I am not able to get into it. it wont let me reset my password as keeps coming up with an error message. I need this sorted and have had no help from fb even after reporting it numerous times
Would Facebook ever consider having the option of two factor authentication (something similar, if not compatible with Google Authentication/TOTP/MOTP apps)?
I use it too, but I must admit to wishing they would make it compatible with Google Authenticator or some other OATH implementation. SMS'ed text codes take way too long to be a good second-step when you're having to login everyday like I do (not to mention logging in from work where my reception is almost nil).
For a search engine to come across these links, the content of the emails would need to have been posted online (e.g. via throwaway email sites, as someone pointed out - or people whose email addresses go to email lists with online archives).
As jpadvo surmised, the nonces expire after a period of time. They also only work for certain users, and even then we run additional security checks to make sure it looks like the account owner who's logging in. Regardless, due to some of these links being disclosed, we've turned the feature off until we can better ensure its security for users whose email contents are publicly visible. We are also securing the accounts of anyone who recently logged in through this flow.
In the future if you run into something that looks like a security problem with Facebook, feel free to disclose it responsibly through our whitehat program: https://www.facebook.com/whitehat. That way, in addition to making some money, you can avoid a bunch of script kiddies exploiting whatever the issue is that you've found.