Issue Crash-stats is currently using HTTP Basic Authentication and verifying credentials against an internal LDAP server. This method of authentication attaches the username and password within every HTTP request in a reversible format. If an attacker is able to view any of the HTTP requests then the attacker can easily acquire the user's password. Currently crash-stats.mozilla.com supports both HTTP and HTTPS connections. If the user accesses the page over HTTP then their credentials will be sent in the clear and exposed to anyone monitoring network traffic. This is of particular concern for the admin portion of the site which allows a user to send custom emails to numerous Firefox users. Recommended Remediation 1. Configure the server to redirect all HTTP requests to the equivalent HTTPS. 2. Consider implementing Strict Transport Security as a secondary control to further protect users accessing the page with an updated browser.
Why does all of crash-stats need to be over HTTPS? That seems like it will cause a ton of extra load for no real gain... From my quick testing, http://crash-stats.mozilla.com/admin/ redirects to https://. It does seem to be possible to change over to http:// after logging-in and still be authenticated. The cookies are missing the Secure flag, so that could be one fix (as well as adding HTTPOnly flag, too). Just need to make sure that nothing on https:// redirects back to http://.
Let me close this one out and do a bit more investigating. I was surprised to see that although the site uses basic auth for login (over https), the site then gives a cookie instead of keeping the basic auth creds in the requests. This is good from a security perspective. But, I do need to look at the cookie handling since its possible to jump between http and https version of the site. No action for now on this. I'll open new bugs if needed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Just to finish this one off - the stage environment and prod environment are setup differently. It looks like prod is ok since it requires explicit reauthentication and a new sessionid to access /admin.
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.