27

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?

Improve this question
6
  • 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
    Commented Nov 2, 2015 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.
    – user54862
    Commented Nov 3, 2015 at 14:02
  • 2
    @WumpusQ.Wumbley I really hope nothing exposed by firebug is "obscured for security reasons."
    – djechlin
    Commented Nov 4, 2015 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
    Commented Nov 4, 2015 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"?
    – user54862
    Commented Nov 4, 2015 at 11:38

3 Answers 3

Reset to default
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.

Improve this answer
3
  • 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.
    – dan
    Commented Nov 2, 2015 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
    Commented Nov 2, 2015 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
    Commented Nov 2, 2015 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.

Improve this answer
1
  • 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
    Commented Nov 3, 2015 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.
Improve this answer
3
  • 8
    The built-in debugger can see it too. Banning add-ons won't help.
    – OrangeDog
    Commented Nov 2, 2015 at 18:16
  • 2
    Firebug can see these the same way the browser built-in password manager does.
    – Mindwin Remember Monica
    Commented Nov 3, 2015 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
    Commented Nov 4, 2015 at 4:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .