791681 - Insecure transition from HTTP to HTTPS in form post

Status: VERIFIED FIXED

(www.mozilla.org :: Pages & Content, defect, P2)

Description

[Tapan Krishna Kumar]

Vulnerability description

This form is served from an insecure page (http) page. This page could be hijacked using a Man-in-the-middle attack and an attacker can replace the form target.

Affected items

/en-US 
/en-US/about/partnerships 
/en-US/collusion 
/en-US/firefox/organizations 
/en-US/thunderbird/organizations 
/en-US/webmaker 
/projects/calendar/donate.html
 
The impact of this vulnerability
Possible information disclosure.

ATTACK: Man-in the middle attack

FIXING OF VULNERABILITY:
The form should be served from a secure (https) page.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Could you please give a more complete set of steps for reproducing this issue? What URL did you start at, what did you click on? I would like to reproduce this exactly to confirm the issue.

Comment 2

[Tapan Krishna Kumar]

(In reply to Curtis Koenig [:curtisk] from comment #1)
> Could you please give a more complete set of steps for reproducing this
> issue? What URL did you start at, what did you click on? I would like to
> reproduce this exactly to confirm the issue.

The Website Uses HTTP Protocol and There Is An Insecure Transition Of data 
The Attacker Uses Man-In-The-Middle Attack 
The Name Itself Conveys that between transition of data a man is in the middle and getting every data that is transit between a client and server

The man-in-the-middle attack in cryptography and computer security is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances 

EXample: An attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle.


To Patch This Vulnerability:

HTTPS Protocol Must Be Used To Prevent Data And Information Disclosure.


Thank You,

---
Tapan

Comment 3

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I understand what the vulnerability is, I am trying to find out exactly what mozilla urls you are seeing this on and the steps you took to find the issue so I can confirm it and get it to someone to fix. So if you could please give me full urls and the steps you took where you see a transition between HTTP and HTTPS that would be helpful.

Comment 4

[Tapan Krishna Kumar]

(In reply to Curtis Koenig [:curtisk] from comment #3)
> I understand what the vulnerability is, I am trying to find out exactly what
> mozilla urls you are seeing this on and the steps you took to find the issue
> so I can confirm it and get it to someone to fix. So if you could please
> give me full urls and the steps you took where you see a transition between
> HTTP and HTTPS that would be helpful.


http://www.mozilla.org/en-US 
http://www.mozilla.org/en-US/about/partnerships 
http://www.mozilla.org/en-US/collusion 
http://www.mozilla.org/en-US/firefox/organizations 
http://www.mozilla.org/en-US/thunderbird/organizations 
http://www.mozilla.org/en-US/webmaker 
http://www.mozilla.org/projects/calendar/donate.html 

All websites use HTTP Protocol .. to fix it Use HTTPS Protocol for all the websites will help you in solving This vulnerability.

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Thank you we will check these out. Please do not set the importance flags, the developer will set those once these are confirmed.

Comment 6

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Of all the pages these 2 might have an issue we should look further at

http://www.mozilla.org/en-US/about/partnerships 
* possible privacy issue

https://www.mozilla.org/projects/calendar/donate.html
* has a direct link to paypal

I also don't think this is not security-sensative so I am un-hiding this bug, we might want to consider some changes but as this goes from http->https and not the other way round.

Comment 7

[Tapan Krishna Kumar]

In reply to Curtis Koenig [:curtisk] from comment #6)

Okay Sir As Soon as the protocol is changed. the vulnerability will be eradicated and mozilla will become man in the middle attack bug free sir.

Thank you for considering my report.
---
Tapan

Comment 8

[Tapan Krishna Kumar]

(In reply to Curtis Koenig [:curtisk] from comment #6)

Till now did not receive any kind of mail about this respective bug sir.
The Status is new but this bug is not yet removed or resolved.

I Like To Know The Status Of This Bug Sir. 

Thank you.

---
Tapan

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

This is extremely low priority and not likely to get any attention in the near term. Primary as the data being that could be compromised is not private nor sensitive. So while this behavior is not preferred it does not pose a security issue at this time. When someone is available and inclined to work on it the bug will be assigned and dealt with.

Comment 10

[Tanvi Vyas[:tanvi]]

Bug 843977 and it's dependents have been filed to remove Mixed Content from mozilla Affiliated sites before the Mixed Content Blocker lands on stable in August.  Please replace the form target with an https link.

Marking this as P2.

Comment 11

[Kohei Yoshino]

I'll send a pull request for www.mozilla.org.
Bug 866994 is for blog.mozilla.org.

Comment 12

[Kohei Yoshino]

I just set up a local develop environment of Bedrock!
Pull request: https://github.com/mozilla/bedrock/pull/928

While investigating this issue, I have noticed that the SMS form on this page is showing a rock icon even though the submission is insecure.
http://www.mozilla.org/en-US/firefox/sms/

Comment 13

[Kohei Yoshino]

I'll make a PHP patch because some key pages are still on the PHP side like this:
http://www.mozilla.org/en-US/firefox/beta/

Comment 14

[Kohei Yoshino]

Attachment: Patch for the PHP side: /projects/mozilla.com/trunk/

Comment 15

[Kohei Yoshino]

Attachment: Patch for the PHP side: /projects/mozilla.org/trunk/

Comment 16

[Tanvi Vyas[:tanvi]]

(In reply to Kohei Yoshino from comment #12)
> While investigating this issue, I have noticed that the SMS form on this
> page is showing a rock icon even though the submission is insecure.
> http://www.mozilla.org/en-US/firefox/sms/

Thanks for catching this Kohei!

This is an HTTP page that posts a phone number over HTTP, which is not secure and should not show a lock icon.  This is a misuse of the lock icon and Mozilla should remove this.  We would like to train our users to look at the lock icon in the address bar, since that is the true indicator of the security level of the page.  Adding this lock next to the form only confuses users.  The confusion could lead them to be more susceptible to attacks/phishing in the future.

On a Separate Note - If a page is fully HTTPS (there no mixed content loaded on the page), it will show the lock icon.  BUT, it may still have a form that posts to http.  If a user edits the form and hits submit, they will get a warning before the post goes through.  The warning looks like this:  https://people.mozilla.com/~tvyas/MixedContentPost.png

Comment 17

[Adam Muntner [:adamm] (use NEEDINFO)]

I'm tracking the bugs that are blocking 843977, the mixed content bug. Is there an expected date that the changes will be made?

Comment 18

[Kohei Yoshino]

Once I get a write access to the SVN repo (Bug 880130) I'll commit the changes to trunk and make them ready for review.

Comment 19

[Adam Muntner [:adamm] (use NEEDINFO)]

Looks good! Thank you.

Comment 20

[Adam Muntner [:adamm] (use NEEDINFO)]

Thanks Kohei! Can you let me know when the ticket can be closed?

Comment 21

[Kohei Yoshino]

A(In reply to Kohei Yoshino [:kohei] from comment #14)
> Created attachment 755873 [details] [diff] [review]
> Patch for the PHP side: /projects/mozilla.com/trunk/

Tested locally and applied this patch to trunk at r116864.
The affected pages include

https://www-dev.allizom.org/en-US/firefox/beta/
https://www-dev.allizom.org/en-US/press/speakerrequest/
https://www-dev.allizom.org/en-US/newsletter/

I'll also update my pull request for Bedrock.
Can someone apply my patch in the comment 15 to trunk?

(In reply to Adam Muntner :adamm from comment #20)
> Can you let me know when the ticket can be closed?

Hopefully this week :)

Comment 22

[Adam Muntner [:adamm] (use NEEDINFO)]

I just looked at the bug and I while I'm not a github expert I think it's saying that the merge didn't happen yet. Do you know what it's waiting on?

Comment 23

[Kohei Yoshino]

* PHP/SVN: r116864 needs to be QAed, then merged to the stage/production branch
* PHP/SVN: a patch in comment 15 needs to be committed to the trunk branch, QAed, then merged to the stage/production branch
* Python/Git: https://github.com/mozilla/bedrock/pull/928 needs to be QAed, then merged to the master branch

Comment 24

[Tanvi Vyas[:tanvi]]

Any update here?  The Mixed Content Blocker is moving to beta today.  And the beta download page has mixed content on it: 

Release version - https://www.mozilla.org/en-US/firefox/beta/
Fixed dev version - https://www-dev.allizom.org/en-US/firefox/beta/

We are going to ask users/developers/contributors to install Firefox beta and test out the blocker, so the fact that our beta download page has mixed content on it doesn't look good.

Comment 25

[Chris More [:cmore]]

(In reply to Tanvi Vyas [:tanvi] from comment #24)
> Any update here?  The Mixed Content Blocker is moving to beta today.  And
> the beta download page has mixed content on it: 
> 
> Release version - https://www.mozilla.org/en-US/firefox/beta/
> Fixed dev version - https://www-dev.allizom.org/en-US/firefox/beta/
> 
> We are going to ask users/developers/contributors to install Firefox beta
> and test out the blocker, so the fact that our beta download page has mixed
> content on it doesn't look good.

Everything is fixed from comment 23. We are waiting for a review, QA and merge. Firefox OS is our P1 right now for a few more days and our team is on the hook for the entire Firefox OS consumer website that is still being developed.

Comment 26

[Kohei Yoshino]

(In reply to Kohei Yoshino [:kohei] from comment #23)
> * PHP/SVN: r116864 needs to be QAed, then merged to the stage/production
> branch
> * PHP/SVN: a patch in comment 15 needs to be committed to the trunk branch,
> QAed, then merged to the stage/production branch
> * Python/Git: https://github.com/mozilla/bedrock/pull/928 needs to be QAed,
> then merged to the master branch

Can someone review these changes? Firefox 23 is on the way.

Comment 27

[Adam Muntner [:adamm] (use NEEDINFO)]

Kohei, is there anything I can do to facilitate getting the review done?

Last I heard FF23 hits stable on Aug 6.

Comment 28

[Chris More [:cmore]]

Comment 23 provides links to the areas that need code reviewed and merged.

Comment 29

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/fbb8d94cc6365493114ba73afe86d8fff48b689b
Bug 791681 - Insecure transition from HTTP to HTTPS in form post

https://github.com/mozilla/bedrock/commit/8223d36658c25ce02d9756f296dd3962a505cbc7
Merge pull request #928 from kyoshino/bug-791681-form-https

Bug 791681 - Insecure transition from HTTP to HTTPS in form post

Comment 30

[Tanvi Vyas[:tanvi]]

(In reply to [github robot] from comment #29)
> Commits pushed to master at https://github.com/mozilla/bedrock
> 
> https://github.com/mozilla/bedrock/commit/
> fbb8d94cc6365493114ba73afe86d8fff48b689b
> Bug 791681 - Insecure transition from HTTP to HTTPS in form post
> 
> https://github.com/mozilla/bedrock/commit/
> 8223d36658c25ce02d9756f296dd3962a505cbc7
> Merge pull request #928 from kyoshino/bug-791681-form-https
> 
> Bug 791681 - Insecure transition from HTTP to HTTPS in form post

Was this a push to production?  Is this bug fixed?

Comment 31

[Mike Alexis [:malexis]]

(In reply to Tanvi Vyas [:tanvi] from comment #30)
> (In reply to [github robot] from comment #29)
> > Commits pushed to master at https://github.com/mozilla/bedrock
> > 
> > https://github.com/mozilla/bedrock/commit/
> > fbb8d94cc6365493114ba73afe86d8fff48b689b
> > Bug 791681 - Insecure transition from HTTP to HTTPS in form post
> > 
> > https://github.com/mozilla/bedrock/commit/
> > 8223d36658c25ce02d9756f296dd3962a505cbc7
> > Merge pull request #928 from kyoshino/bug-791681-form-https
> > 
> > Bug 791681 - Insecure transition from HTTP to HTTPS in form post
> 
> Was this a push to production?  Is this bug fixed?

Yes! marking this bug resolved. QA can verify on production

Comment 32

[Mike Alexis [:malexis]]

(In reply to Mike Alexis [:malexis] from comment #31)

> > Was this a push to production?  Is this bug fixed?
> 
> Yes! marking this bug resolved. QA can verify on production

Ack, never mind. the github PR was merged and pushed to prod but we still need to review the SVN commits:

* PHP/SVN: r116864 needs to be QAed, then merged to the stage/production branch
* PHP/SVN: a patch in comment 15 needs to be committed to the trunk branch, QAed, then merged to the stage/production branch

Comment 33

[Kohei Yoshino]

Checked my PHP patches... Both attachment 755873 [details] [diff] [review] (r116864) and attachment 755876 [details] [diff] [review] still look fine. I haven't patched to the firstrun and whatsnew pages in the PHP side that are no longer in use, so I think I don't have to revise them. Any other issues?

Comment 34

[Andrei Hajdukewycz [:sancus]]

Merged mozilla.com changes, r116864, to stage in r118705, production in r118708.

Committed mozilla.org changes in r118712.

Could still use QA verification. I don't think there are any other issues here.