835983 - Facebook defaults to WAP and loads insecure content

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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.

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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.

Comment 3

[Alex Keybl [:akeybl]]

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

Comment 4

[Lucas Adamski [:ladamski]]

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?

Comment 5

[Jason Smith [:jsmith]]

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

Comment 6

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 7

[Alex Keybl [:akeybl]]

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

Comment 8

[Lucas Adamski [:ladamski]]

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

Comment 9

[Alex Keybl [:akeybl]]

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

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

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

Comment 11

[Thomas Elin [:relaas]]

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

Comment 12

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 13

[[:fabrice] Fabrice Desré]

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.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 15

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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.

Comment 17

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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.

Comment 18

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: request trace

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.

Comment 19

[Lucas Adamski [:ladamski]]

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.

Comment 20

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 21

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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?

Comment 22

[Jason Smith [:jsmith]]

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

Comment 23

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 24

[Jason Smith [:jsmith]]

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.

Comment 25

[Hallvord R. M. Steen [:hallvors]]

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

Comment 26

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 27

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 28

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 29

[Jose Manuel Cantera]

sorry for the collision.

Adding Harald as he is helping us to outreach FB on issues like this.

thanks

Comment 30

[Jason Smith [:jsmith]]

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.

Comment 31

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 32

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 33

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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?

Comment 34

[Jason Smith [:jsmith]]

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

Comment 35

[Hallvord R. M. Steen [:hallvors]]

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

Comment 36

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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.

Comment 37

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 38

[Al Billings [:abillings - ex-MoCo]]

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

Comment 39

[Matt Wobensmith [:mwobensmith][:matt:]]

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

Comment 40

[Jason Smith [:jsmith]]

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

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 42

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

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

Comment 43

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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)

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 45

[Hallvord R. M. Steen [:hallvors]]

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.

Comment 46

[Hallvord R. M. Steen [:hallvors]]

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

Comment 47

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 48

[Hallvord R. M. Steen [:hallvors]]

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

Comment 49

[Hallvord R. M. Steen [:hallvors]]

Tested - fix is deployed indeed

Comment 50

[David Chan [:dchan]]

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.