When loading Facebook, either through the browser or through any of our integration points like in the Address Book, the Facebook Login Page defaults to a WAP optimized site. Being WAP optimized also means that all assets like images, CSS and JavaScript are loaded over plain HTTP instead of HTTPS. This is a huge security risk as anyone who can MITM HTTP can now mess with the Facebook login page. Interestingly this does not happen on iOS with the same page. So it is likely that Facebook simply does not recognize our user agent and defaults to low security (but higher performance) settings for WAP.

Just to clarify, the login page is loaded over HTTPS but it seems the assets, including JS, are loaded over HTTP.

Sorry for changing the subject a bunch of times. I thought this was Contacts App specific but even when you load facebook.com in the Browser app, it defaults to the WAP optimized site and thus loads insecure content. It is not clear who should fix this. I *think* Facebook should simply recognize our User Agent and serve us modern content and all-HTTPS. I think the right people in Product are aware of this and things are being discussed with Facebook but I think we should still have this bug to keep track of it and make sure this gets fixed before we ship.

Lucas - who would need to make a call on whether or not a security change is needed here?

Not sure this is our bug to fix so much as it is a partner issue. This makes is hard to block on. Alex do you know who our partner contact is for FB?

No need to track for tef. This is a tech evangelism issue.

Why is this an evangelism issue? What does that mean wrt getting this security issue resolved?

(In reply to Lucas Adamski from comment #4) > Not sure this is our bug to fix so much as it is a partner issue. This > makes is hard to block on. Alex do you know who our partner contact is for > FB? Before talking to FB, who can answer whether or not a change is necessary?

(In reply to Alex Keybl [:akeybl] from comment #7) > Before talking to FB, who can answer whether or not a change is necessary? I believe this needs to be fixed. Allowing MITM for users' Facebook credentials is an unacceptable risk for a feature built into the product.

clee - who can we get in touch with from Facebook?

BD is managing our relationship with Facebook. Changing needinfo to Ron Piovesan from Mozilla BD.

I'm on the Bd team with Ron. Just want to clarify what needs to be done here. Is this all that needs to be done? "It is not clear who should fix this. I *think* Facebook should simply recognize our User Agent and serve us modern content and all-HTTPS."

(In reply to thomas elin from comment #11) > I'm on the Bd team with Ron. Just want to clarify what needs to be done here. > > Is this all that needs to be done? > > "It is not clear who should fix this. I *think* Facebook should simply > recognize our User Agent and serve us modern content and all-HTTPS." Likely. But we should also make sure that we are sending the right UA. I am not the best person to answer that. Adding Fabrice to the CC who probably has more insight or can point to the right people.

We have a UA override in place for Facebook, so we send them the Fennec Android UA String. They don't redirect us to https though, which is very sad.

As Fabrice eluded, Facebook does recognize the Firefox for Android UA. As Facebook relies on WURFL for UA detection, this recognition is done via a Firefox for Android specific hack by Facebook. The fix for the UA detection of Firefox OS is need in WURFL (I'm working on this). I would think that the fix to serve https content would be under Facebook's control.

Just a quick note that bug 843877 (Remove facebook.com UA override) did *not* fix this issue. The oauth dialog did improve (there is no mention about downloading Facebook for Android anymore) but it still redirects to a non-SSL version of the login page. I'm still investigating.

Quick note. In #1 i said that the login page is loaded over HTTPS and the assets over HTTP but this is not correct. I am not sure if this changed or if my initial observation was wrong. What I see now is this: 1) We request https://m.facebook.com/... 2) Facebook redirects is to http://m.facebook.com/... The login page is POSTed to HTTPS. That makes the risk a little less but the fact that page and script assets are loaded over HTTP makes this a huge MITM opportunity. I have been talking to people at Facebook but without any results yet. THey recognize the problem but don't have an answer. I *think* this is on their side as they redirect us to the insecure content.

Trace of the requests that we make. Made with an intercepting proxy. This shows how Facebook redirects us immediately to a non-SSL login page.

Needs a sec rating? Also, this definitely seems like a blocker for TEF, but I can't mark it as such since its not in the B2G project.

Set priority to sec-critical as it allows for injection of code into a system app.

The injection issue (845487) has been resolved now, but the MITM issue remains. There hasn't been any movement on this for a while. How can we get this moving again? Ron - are you the right person here, or do we need to pass this to someone else?

(In reply to Paul Theriault [:pauljt] from comment #21) > The injection issue (845487) has been resolved now, but the MITM issue > remains. There hasn't been any movement on this for a while. How can we get > this moving again? If some of the other 1.01 fires calm down, then we can probably get help to move this again. If the injection issue is resolved, does the sec rating here remain the same or drop lower? > > Ron - are you the right person here, or do we need to pass this to someone > else? Harald probably could help with this.

(In reply to Jason Smith [:jsmith] from comment #22) > (In reply to Paul Theriault [:pauljt] from comment #21) > > The injection issue (845487) has been resolved now, but the MITM issue > > remains. There hasn't been any movement on this for a while. How can we get > > this moving again? > > If some of the other 1.01 fires calm down, then we can probably get help to > move this again. > > If the injection issue is resolved, does the sec rating here remain the same > or drop lower? No. The Facebook content *must* be loaded over HTTPS. The rating is based on that, not on 845487.

Something doesn't add up here on this bug. We can't make any assumption that the content we interact with the on the web is always going to be secure over HTTPS. This is a bug on Facebook's side, which we can't control (we can talk to them to fix the issue however). Why aren't we preparing for such situations where 3rd party content we're interacting is over HTTP and enters into situations such as what Facebook is doing? We can't assume we're always going to get secure content.

I have not noticed WAP or mixed content issues on FB's login page. Resolving as worksforme.

(In reply to Hallvord R. M. Steen from comment #25) > I have not noticed WAP or mixed content issues on FB's login page. Resolving > as worksforme. Hallvord, how did you verify this?

(In reply to Jason Smith [:jsmith] from comment #24) > Something doesn't add up here on this bug. We can't make any assumption that > the content we interact with the on the web is always going to be secure > over HTTPS. This is a bug on Facebook's side, which we can't control (we can > talk to them to fix the issue however). Why aren't we preparing for such > situations where 3rd party content we're interacting is over HTTP and enters > into situations such as what Facebook is doing? We can't assume we're always > going to get secure content. I agree that we cannot make any assumptions about random stuff on the web. However, this is a third-party site with which we specifically integrate in Firefox OS. It is not just some random site, it is an integral part of Firefox OS (Contacts) that many people use. So in my opinion we should care a lot about these cases and make sure they are implemented correctly. It is easy to say that his is a Facebook problem (and it probably is) but ultimately it is us who made the decision to integrate with an insecure service that transmits personal information. Therefore we should not lower the priority of bugs like this but instead treat them very seriously.

Reopening as this bug is not about Facebook's app or site but rather the integration in Firefox OS. I'm not sure where this bug should live but, even if this bug requires outreach to Facebook, I don't think this is a tech evangelism issue. Perhaps Preinstalled B2G Apps.

sorry for the collision. Adding Harald as he is helping us to outreach FB on issues like this. thanks

This is not a preinstalled b2g apps bug - this is related to the core integration of the contacts app into facebook. We don't deal with those bugs as part of the preinstalled apps. Back over to Mobile.

This also isn't a Web compatibility issue. We can fight about the right component but I think at the end of the day we need to work with Facebook on this issue and Harald is the right guy to at least start that conversation. Over to Gaia to ensure this bug is on the radar.

I will try to make a WiFi setup today in which I can test if this bug is still valid.

I've been looking at this issue again but I am stuck with an error that Facebook gives me when I try to connect my Address Book to Facebook: "Unknown App ID: 123456" Obviously my build needs to change to point to the right Facebook app. Can anyone give me a hint on how to do that?

(In reply to Stefan Arentz [:st3fan] from comment #33) > I've been looking at this issue again but I am stuck with an error that > Facebook gives me when I try to connect my Address Book to Facebook: > > "Unknown App ID: 123456" > > Obviously my build needs to change to point to the right Facebook app. Can > anyone give me a hint on how to do that? You need to build with a MOZILLA_OFFICIAL build to get a valid facebook ID. Otherwise, facebook import won't work.

Hm - sorry, perhaps I misunderstood the context of this bug. It does say "either through the browser" so I assumed testing with regular Facebook browsing, keeping an eye on the padlock would be sufficient. If there is some special B2G integration points or apps this should presumably be re-tested by QA or devs working on that to see if it's still valid. If you can verify that it's still a problem, we can certainly follow up the outreach part - it's just not a good idea to do outreach on a problem you can't verify and a bug that hasn't been touched for a few months. ;)

I have looked at this bug again with a production build. The situation has improved a little bit but there is still an issue: When you flip the 'Facebook: Sync Friends' switch in the Address Book app, we correctly load https://m.facebook.com/... which shows a login dialog over HTTPS with no mixed content. This is a big improvement over the old situation when I filed this bug. However, when you submit the form with an *incorrect* login, the following plaintext request happen: GET /login.php?skip_api_login=1&signed_next=1&next=https%3A%2F%2Fm.facebook.com%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Fwww.facebook.com%252Fconnect%252Flogin_success.html%26state%3Dfriends%26scope%3Dfriends_about_me%252Cfriends_birthday%252Cfriends_hometown%252Cfriends_location%252Cfriends_work_history%252Cread_stream%26response_type%3Dtoken%26client_id%3D395559767228801%26ret%3Dlogin&refsrc=https%3A%2F%2Fm.facebook.com%2Flogin.php&app_id=395559767228801&refid=9&e=1348028&email=aa&signup_layout=layout%7Clower_subdued_button%7C%7Cs_btn%7Cspecial%7C%7Cl_btn%7Cconfirm%7C%7Csignupinstr%7C%7Clogininstr%7C%7Cst%7Ccreate%7C%7Claunched_Jan9&li=Hk1EUlUS8FmS53GLKTUQClcJ&_rdr HTTP/1.1 Host: m.facebook.com User-Agent: Mozilla/5.0 (Mobile; rv:27.0) Gecko/27.0 Firefox/27.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Cookie: datr=Hk1EUqVA06yZc1u9uSxDuNVt; m_ts=1380207902; reg_fb_gate=https%3A%2F%2Fm.facebook.com%2Flogin.php%3Fskip_api_login%3D1%26api_key%3D395559767228801%26signed_next%3D1%26next%3Dhttps%253A%252F%252Fm.facebook.com%252Fdialog%252Foauth%253Fredirect_uri%253Dhttps%25253A%25252F%25252Fwww.facebook.com%25252Fconnect%25252Flogin_success.html%2526state%253Dfriends%2526scope%253Dfriends_about_me%25252Cfriends_birthday%25252Cfriends_hometown%25252Cfriends_location%25252Cfriends_work_history%25252Cread_stre 11:05:36.998220 IP 192.168.2.4.47169 > edge-m-shv-04-lga1.facebook.com.http: Flags [P.], seq 1449:2439, ack 1, win 229, options [nop,nop,TS val 4294960679 ecr 1643803475], length 990 G2.A.P8.p.M.............. ...'a.sSe_type%253Dtoken%2526client_id%253D395559767228801%2526ret%253Dlogin%26cancel_uri%3Dhttps%253A%252F%252Fwww.facebook.com%252Fconnect%252Flogin_success.html%253Ferror%253Daccess_denied%2526error_code%253D200%2526error_description%253DPermissions%252Berror%2526error_reason%253Duser_denied%2526state%253Dfriends%2523_%253D_%26display%3Dtouch; reg_fb_ref=https%3A%2F%2Fm.facebook.com%2Flogin.php%3Fskip_api_login%3D1%26signed_next%3D1%26next%3Dhttps%253A%252F%252Fm.facebook.com%252Fdialog%252Foauth%253Fredirect_uri%253Dhttps%25253A%25252F%25252Fwww.facebook.com%25252Fconnect%25252Flogin_success.html%2526state%253Dfriends%2526scope%253Dfriends_about_me%25252Cfriends_birthday%25252Cfriends_hometown%25252Cfriends_location%25252Cfriends_work_history%25252Cread_stream%2526response_type%253Dtoken%2526client_id%253D395559767228801%2526ret%253Dlogin%26refsrc%3Dhttps%253A%252F%252Fm.facebook.com%252Flogin.php%26app_id%3D395559767228801%26refid%3D9; m_pixel_ratio=1 Connection: keep-alive HTTP/1.1 301 Moved Permanently Cache-Control: private, no-cache, no-store, must-revalidate Content-Type: text/html; charset=utf-8 Expires: Sat, 01 Jan 2000 00:00:00 GMT Location: https://m.facebook.com/login.php?skip_api_login=1&signed_next=1&next=https%3A%2F%2Fm.facebook.com%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Fwww.facebook.com%252Fconnect%252Flogin_success.html%26state%3Dfriends%26scope%3Dfriends_about_me%252Cfriends_birthday%252Cfriends_hometown%252Cfriends_location%252Cfriends_work_history%252Cread_stream%26response_type%3Dtoken%26client_id%3D395559767228801%26ret%3Dlogin&refsrc=https%3A%2F%2Fm.facebook.com%2Flogin.php&app_id=395559767228801&refid=9&e=1348028&email=aa&signup_layout=layout%7Clower_subdued_button%7C%7Cs_btn%7Cspecial%7C%7Cl_btn%7Cconfirm%7C%7Csignupinstr%7C%7Clogininstr%7C%7Cst%7Ccreate%7C%7Claunched_Jan9&li=Hk1EUlUS8FmS53GLKTUQClcJ&_rdr P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p" Pragma: no-cache X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 0 Set-Cookie: datr=Hk1EUqVA06yZc1u9uSxDuNVt; expires=Sat, 26-Sep-2015 15:05:37 GMT; path=/; domain=.facebook.com; httponly Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com Set-Cookie: reg_fb_ref=http%3A%2F%2Fm.facebook.com%2Flogin.php%3Fskip_api_login%3D1%26signed_next%3D1%26next%3Dhttps%253A%252F%252Fm.facebook.c 11:05:37.073608 IP edge-m-shv-04-lga1.facebook.com.http > 192.168.2.4.47169: Flags [P.], seq 1449:2329, ack 2439, win 40, options [nop,nop,TS val 1643803554 ecr 4294960679], length 880 G2.....P.AM..O8.t....(....... a.s....'252Foauth%253Fredirect_uri%253Dhttps%25253A%25252F%25252Fwww.facebook.com%25252Fconnect%25252Flogin_success.html%2526state%253Dfriends%2526scope%253Dfriends_about_me%25252Cfriends_birthday%25252Cfriends_hometown%25252Cfriends_location%25252Cfriends_work_history%25252Cread_stream%2526response_type%253Dtoken%2526client_id%253D395559767228801%2526ret%253Dlogin%26refsrc%3Dhttps%253A%252F%252Fm.facebook.com%252Flogin.php%26app_id%3D395559767228801%26refid%3D9%26e%3D1348028%26email%3Daa%26signup_layout%3Dlayout%257Clower_subdued_button%257C%257Cs_btn%257Cspecial%257C%257Cl_btn%257Cconfirm%257C%257Csignupinstr%257C%257Clogininstr%257C%257Cst%257Ccreate%257C%257Claunched_Jan9%26li%3DHk1EUlUS8FmS53GLKTUQClcJ; path=/; domain=.facebook.com X-FB-Debug: h9OxZLRnrKuZcOcOr1BvLeTbLXwTvGCf3r/BEUblCe4= Date: Thu, 26 Sep 2013 15:05:37 GMT Connection: keep-alive Content-Length: 0 From a security point of view this is still critical. You simply cannot have a plaintext redirect as part of a login flow. I am not sure what is causing this request as I cannot see the HTTPS requests yet. It could be either our code or something weird in the Facebook-owned login flow.

The above was tested on master and 1.1.1.0-prerelease and both had the same results.

Who can we assign this to in order to be addressed?

Based on comment 36, has the behavior in this bug changed enough as to affect its severity?

(In reply to Al Billings [:abillings] from comment #38) > Who can we assign this to in order to be addressed? I think we need to first have an architect look at this problem to see if there's anything we can do to mitigate the risk on our side, as that's going to be easier to get traction on. A resolution path relying on Facebook fixing issues is going to be harder overall due to lack of marketshare dominance and reliance on a 3rd party service fixing the problem for us, which is not directly in our control. Jonas - Can you drive figuring out what we can do here?

Sid might also know (or know who would know) if there's stuff we could do here related to either: * requiring https in a particular browsing context, or * auto-upgrading to https in a particular browsing context

(In reply to Matt Wobensmith from comment #39) > Based on comment 36, has the behavior in this bug changed enough as to > affect its severity? Yeah I would say this is not critical anymore. I think 'high' is more appropriate.

So I am downgrading this risk slightly to be inline with our risk rating policy for b2g. This risk is not as bad as it was previously, but still important to fix. Potentially sending PII in cleartext in a specific use case sounds more like sec-high to me, than sec-critical - we are certainly not chemspilling over this. As before, the solution will still likely involve reaching out to facebook - from reading above it sounds like hkirschner is the person who may be able to help here. Harald, if this isn't you, can you suggest anyone else? Re comment 41, while it *may* be possible to do something like force https, that sounds like a hack that may cause more problems than it solves (unless facebook already has support for doing everything over ssl)

(In reply to Jason Smith [:jsmith] from comment #40) > Jonas - Can you drive figuring out what we can do here? I don't think that there is much we can do as far as forcing facebook to go over http goes. What we *could* do, and what would likely be a good idea to do, is to make any attempts to make connections over http fail with an error. That obviously wouldn't help the situation right now. It would only help us detect when things regress more easily so that we can let google know. We could render our own login UI and not rely on facebook's HTML at all. I assume that facebook exposes APIs for that since that's what any non-web based application would do. But that might require application tokens that are more protected than what we have right now. Unfortunately I don't have the bandwidth right now to drive this. I'm happy to help with any details though.

Thanks, it's a 302 redirect - bug is somewhere in the login.php script. It's a generic issue with their mobile site. I've reported this as a security issue to Facebook.

(sorry about the spam, trying to figure out how to lock the bug down again.. :-o )

(In reply to Jonas Sicking (:sicking) from comment #44) > I don't think that there is much we can do as far as forcing facebook to go > over http goes. What we *could* do, and what would likely be a good idea to > do, is to make any attempts to make connections over http fail with an error. This seems worth pursuing in addition to any tech evangelism. Maybe it should go in a separate bug at this point?

Facebook claims to have fixed this. And they offer me $500 for having reported it :-) I'll ask them to donate the money instead - just doing my job and didn't even find the problem myself..

Tested - fix is deployed indeed

Cleaning up list of security bugs for b2g18. This bug doesn't need to be backported either due to it affecting a later version of Fx or another reason.