28

In my company we were writing a small web application which would be hosted and tested under HSTS protocol.

One of my tester complained that the username and password can be seen in cleartext so it is insecure. I replied that due to HSTS implementation it cant be decrypted. I pointed out wireshark logs and proved that it is encrypted.

My tester pointed out Firebug of his own browser and said that it is displaying cleartext username and password so it is insecure.

From the above, here are my analysis and questions:

  1. Since HSTS enables security when the data moves from browser to web sever, Firebug is just a browser plugin, it knows everything in the DOM tree so it can view forms fields, usernames and passwords.

  2. Is it possible to disable Firebug from identifying dom tree?

  3. Does revealing the content from Firebug is really a vulnerability? If yes how can I mitigate it?

  • 23
    firebug runs in his own browser. It has access to everything, which is normal. It is as much a vunerability as the keyboard or the user are. Both know the password at some point. – njzk2 Nov 2 '15 at 19:58
  • It is fair to say that firebug is unsafe in this sense: it exposes (on the screen) things that are normally obscured for security reasons. Your average firefox extension wouldn't do that. But firebug is a debugger, and debuggers expose hidden things, so this type of "unsafety" is expected. The principle to be learned is: don't let an adversary watch you using a debugger. – Wumpus Q. Wumbley Nov 3 '15 at 14:02
  • 2
    @WumpusQ.Wumbley I really hope nothing exposed by firebug is "obscured for security reasons." – djechlin Nov 4 '15 at 4:30
  • 2
    I've seen this question in the hot network questions list for a while - and I keep wondering one question, that no-one else has raised. Is this just an issue of seeing it in the form fields, or is the password also appearing in, say, a URL (e.g. a form submission via GET rather than POST). That would be a genuine concern. You wouldn't see anything in wireshark but the password would end up in e.g. server weblogs. – Damien_The_Unbeliever Nov 4 '15 at 7:15
  • 1
    @djechlin how would you describe the difference between <input type=text> and <input type=password> if not "obscured for security reasons"? – Wumpus Q. Wumbley Nov 4 '15 at 11:38
54

Sounds like there is some confusion over the protections that different parts of your system provide.

HSTS enforces HTTPS for users who have previously visited the site over HTTPS, for a given period. If a user has never visited the HTTPS version of a site, and the site is also available over HTTP (without a redirect to HTTPS), it will do nothing - the traffic will be unencrypted.

Firebug accesses data after decryption - it's a debugging tool. If the browser can see it in clear, Firebug can see it in clear. This is not a vulnerability, unless the website is sending data which shouldn't be sent (e.g. passwords from server), in which case the vulnerability lies with the website, not with Firebug.

If you are sending passwords from the server to the client, you have a problem - this should never be required. Passwords should be considered as a one way thing - users type them in, and they are checked on server side. This minimises the chance of any passwords being discovered without a larger server compromise.

  • 22
    " Firebug access data after decryption" is correct. But this isn't there that Firebug can see a username and password. It can see them on the client side before encryption. This seems to be the problem seen and described within the OQ. – daniel Azuelos Nov 2 '15 at 11:06
  • 17
    @danielAzuelos In that case, presumably the password has just been entered by the user - Firebug could access it from keypresses, or from the DOM. It's never been encrypted, so there is no expectation of it being secret from software on the machine. – Matthew Nov 2 '15 at 11:40
  • Additionally, presumably, a MitM could serve data over http even if the site is not "also available over HTTP (without a redirect to HTTPS)". ​ ​ – user49075 Nov 2 '15 at 12:42
22

No Firebug doesn't decrypt SSL traffic.

Firebug just remind of one key detail: a SSL connection provides a protection against eavesdropping on the connection path. SSL should be seen as a crypted tunnel (VPN is another one), but on both ends of the tunnel, everything is in full light: in clear.

Firebug isn't a vulnerability at all.

  • 3
    And if someone is reading the password directly from the memory of your browser, you probably have significantly bigger issues than an unencrypted password! – Jon Story Nov 3 '15 at 10:06
6
  1. Firebug can access all that the browser can access, so it can access username and password, just like the built in password manager, or password managers like Lastpass.
  2. No. It is not possible to disable Firebug from using the DOM tree, except when you disable Firebug. As OrangeDog says, blocking addons won't help as Firefox has a built-in debugger that can do the same.
  3. No. Revealing the content from Firebug is not a vulnerability.
  • 8
    The built-in debugger can see it too. Banning add-ons won't help. – OrangeDog Nov 2 '15 at 18:16
  • 2
    Firebug can see these the same way the browser built-in password manager does. – Mindwin Nov 3 '15 at 20:04
  • 2
    This answer is hard to link to and breaks if the OP (or anyone) changes the question. Could you make it more self-sufficient? – djechlin Nov 4 '15 at 4:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.