Mask Passwords in Fiddler Traces

[Patrik Spiess]

Hi all

Sometimes I have to capture and save a fiddler trace of an authentication process on our web applications. Then, when submitting a password in a http form, fiddler shows the plaintext password in the trace. If I have to send around this trace to our partners, I have to mask all those passwords manually in the SAZ file.

Is there a way to tell fiddler to mask all passwords in it's trace so that my passwords do not show up in the SAZ file?

Thanks

Patrik

[EricLaw]

How do you imagine that Fiddler would know that a given string is a password?

[Patrik Spiess]

Hi Eric

There are several ways to recognize strings to mask. I could imagine those 2:

- mask by hash:

Fiddler should maintain a list of strings, which in fact may be real passwords to mask. Of course this list has to be stored in a save way, as it may contain real passwords. In every request Fiddler searches for the given strings and masks them if found.

I assume it not a very good way, because Fiddler has to know the real passwords to mask. Maybe it would be possible to just save hashes of the passwords.

- maks by parameter names

Fiddler should maintan a list of parameters. Whenever such a parameter occurs in a request, Fiddler shoud mask it's value. e.g.:

username=peter....@domain.com&password=mYduMmypaSswOrd&Submit=logon&cmd=somecommand&Location=somelocation

In this example I would define the field 'password' as to be masked. Whenever Fiddler recognizes such a parameter the value gets masked.

This would be more secure, as Fiddler does not have to know the passwords.

To mask with what?

I would suggest that the reconized passwords are masked with a custom string. i.e. with '********' or 'MASKEDBYFIDDLER' or whatever I configure.

regards

Patrik

[EricLaw]

You could write a script rule to attempt to mask data like this, but it's generally going to be much harder than one might expect.

Sharing network traces with untrusted third parties is nearly impossble to do safely.

For one thing, you'd also probably want/need to mask out any session cookies or other tokens to prevent any kind of replay, and typically you'd also want to perform some amount of sanitization on the responses themselves, since pages protected by passwords typically themselves contain sensitive data, account numbers, PII etc.