[mkjones]

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.

[blauwbilgorgel]

Since this is already out there as a known issue, and concerns Google too, check out:

https://www.google.com/search?q=%22wants+to+be+friends+on+Fa...

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.

An example of such a blog with password reset email is: http://papajimummyji.blogspot.com/

An example of a spam-redirecting blog is: http://demiansyahhh.blogspot.com/ (possibly unsafe)

For some more Facebook reset emails see:

https://www.google.com/search?q=%22You+recently+asked+to+res...

EDIT: Twitter emails are also exposed: https://www.google.com/search?q=%22Forgot+your+Twitter+passw...

Youtube emails: https://www.google.com/search?q=%22YouTube+sends+email+summa...

Twoo emails: https://www.google.nl/search?q=%22Massive+Media+NV%2C+Emile+...

And likely more web services.

[windsurfer]

It's 47 minutes later and for your searches, I'm seeing 5 results and 309 results. Spooky.

[shiftpgdn]

Somebody at the Google is certainly watching this thread and cleaning house.

[blauwbilgorgel]

Yeah that was weird. I found another that still returns 233.000 results for me:

https://www.google.com/search?q=%22wants+to+be+friends%22+%2...

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.

[acarlucci]

It's something like this (I don't know if you already knew):

1. Try to search this http://goo.gl/dHHsU on Google. You'll find (at the time of writing) 90.300 results.

2. Find an URL like this https://twitter.com/account/confirm_email/[username]/[XXXXX-...

3. Change the URL like this https://twitter.com/account/not_my_account/[username]/[XXXXX...

Twitter "not_my_account" vulnerability:

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

[nico-roddz]

Thanks Matt,

My only concern is my account security (not money).

I found this issue with almost no technical knowledge, so the crazy thing is:

How many back doors should be over there ready to be exploited by spammers?

BTW, a big "report security issue" button on https://www.facebook.com/help/ would certainly help next time.

Thanks again,

Nico

[eli]

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.

[engtech]

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.

Googling "facebook security" brings

#1 result: https://www.facebook.com/security

no information on reporting problems there

#2 result: https://www.facebook.com/help/security

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.

#3 result: https://www.facebook.com/security/app_10442206389

This looks better than the other two, but there is still nothing here about how to report a security issue.

Knowing what to look for, there's a hidden "Take Action >> White Hats" link that will eventually take you to the correct page: https://www.facebook.com/security/app_6009294086

So click that link... and presented with a huge page of names and still no obvious call to action: https://www.facebook.com/whitehat

Oh, it's the Report Vulnerability link in that sidebar that we're been conditioned to ignore in the normal Facebook UI.

https://www.facebook.com/whitehat/report/

---

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

[eli]

shrug

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.

[engtech]

That's still a few down in the search results.

It looks like the magic search term that brings you right to the report page is: "Facebook vulnerability"

http://google.com/?q=Facebook+vulnerability

[lazyjones]

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.

[Matt_Cutts]

Hi there, allow me to correct this misconception. I've debunked that idea often enough that I wrote a blog post about this four years ago: http://www.mattcutts.com/blog/toolbar-indexing-debunk-post/ I wrote an earlier debunk post in 2006 too: http://www.mattcutts.com/blog/debunking-toolbar-doesnt-lead-...

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

Hope that helps. Further down in the discussion, someone posted this helpful link with more explanation: http://blog.alexyakunin.com/2010/03/nice-bloom-filter-applic...

[greggman]

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

[Matt_Cutts]

Multiple people have run controlled experiments like I described in http://www.mattcutts.com/blog/debunking-toolbar-doesnt-lead-...

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?

[ack0x06]

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!

[greggman]

I'm 100% sure. That page was for me and me alone. It was never accessed by anyone but me. I never shared the URL with anyone.

Referrers only get shared through links. There were no links to or from that page. Going to a page and typing in new URL does not provide a referrer.

[franze]

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)

[blauwbilgorgel]

It is a myth that is hard to get rid of. No one wants to admit they tweeted out a link to the dev website.

Though I recently found this on the Google+ FAQ: http://support.google.com/webmasters/bin/answer.py?hl=en&...

  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.

[ack0x06]

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

[mkjones]

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.

EDIT: It looks like they've explicitly said the toolbar does not cause things to appear in search results: http://www.seroundtable.com/google-toolbar-indexing-12894.ht....

[elliotanderson]

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.

1. http://blog.alexyakunin.com/2010/03/nice-bloom-filter-applic...

[lazyjones]

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

[Evbn]

You could make a good bit of easy money if you can prove your suspicions. But since you haven't...

[cbjoe]

Google indexes URLs despite measures such as robots.txt when these URLs are discovered by Google software including Chrome and their Toolbar.

[Evbn]

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.

[maxerickson]

Safe browsing in Firefox is implemented client side, it doesn't share urls with Google.

[nico-roddz]

When you like or share a post in your newsfeed, you're sending a linkback to the original post.

So, if your newsfeed is public "to everyone" Google is able to crawl and index the content on it (discard the original post privacy settings)

[mandeepj]

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

[wesley]

Wouldn't a proper robots.txt rule fix this?

[mkjones]

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.

[credo]

(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 :)

[brudgers]

Another good reason.

[pgl]

Sorry, but, where does it mention anything about making money for reporting security vulnerabilities on https://www.facebook.com/whitehat?

[chucknthem]

https://www.facebook.com/whitehat/bounty/

[mkjones]

Yep as chucknthem points out, try clicking the "bounty" on the left side: https://www.facebook.com/whitehat/bounty/. Sorry I didn't make that clearer!

[Null00]

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.

Jared Null WhiteHat Security

[credo]

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.

[acqq]

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.

[gcorne]

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?

http://en.wikipedia.org/wiki/Cryptographic_nonce

[durin42]

They could both be one-time-use nonces and additionally have an expiration date. That was how I read the statement, but maybe that was generous.

[Evbn]

Nonces are one time use in webapps, unless bad bug.

[gcorne]

WordPress uses them in a similar way to how it sounds like Facebook is using them. I wonder how many others are misusing the term.

[lightj]

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

[gonzac]

I discovered this a long time ago, and I denounced this In this post you can see http://gonzac-studios.blogspot.com.ar/2012/02/hack-la-vulner...

[elliotanderson]

Would Facebook ever consider having the option of two factor authentication (something similar, if not compatible with Google Authentication/TOTP/MOTP apps)?

[leonkenneth]

Actually it already has, see http://www.facebook.com/note.php?note_id=10150172618258920.

[mpyne]

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

[mkjones]

We're working on improving this flow.

However, if you tell us to trust a given computer when you log in, you shouldn't have to enter the code more than once.

[abraham]

I can't speak for the iOS app but the Android app will generate tokens.

[julien_c]

It does, and I'm using it.

[Omegador]

That page doesn't say anything about money. It says Facebook might decide not to sue you submit it.

[mkjones]

https://www.facebook.com/whitehat/bounty/ describes our bug bounty program, linked to from the "bounty" tab on the left of https://www.facebook.com/whitehat/.