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?

l0b0
  • 2,981
  • 20
  • 29
BlueBerry - Vignesh4303
  • 5,107
  • 13
  • 34
  • 63
  • 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 02 '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. –  Nov 03 '15 at 14:02
  • 2
    @WumpusQ.Wumbley I really hope nothing exposed by firebug is "obscured for security reasons." – djechlin Nov 04 '15 at 04: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 04 '15 at 07:15
  • 1
    @djechlin how would you describe the difference between `` and `` if not "obscured for security reasons"? –  Nov 04 '15 at 11:38
  • If you had used thinbus SRP they wouldn't have complained as the password wouldn't ever leave the browser. – simbo1905 Nov 11 '15 at 17:51

3 Answers3

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.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • 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 Nov 02 '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 02 '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)". ​ ​ –  Nov 02 '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.

dan
  • 3,033
  • 14
  • 34
  • 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 03 '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.
SPRBRN
  • 7,379
  • 6
  • 33
  • 37