search

codenamejason / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
2 stars 0 forks source link

Add a configuration option to allow omitting AUTH_PASSWORD from error logs #140

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I would love a configuration option for web.config to specify whether or
not to store the value of the AUTH_PASSWORD server variable in error logs,
e-mails, etc. Perhaps this could be done through an attribute on the
security element (or a new element) such as: logPassword="0" or
omitServerVariables="AUTH_PASSWORD" .

This would allow an admin to prevent the logging of user passwords in the
interest of security. Perhaps this could be extended to also allow
specifying variables to omit or mask from the query string, form and
cookies collections (to prevent logging of credit card numbers, for example).

Note: I am aware of the customization mentioned at
http://groups.google.com/group/elmah/browse_thread/thread/48fc5183d1ed931d
but it would be nice to have this be configurable.

Original issue reported on code.google.com by mhenr...@gmail.com on 28 Oct 2009 at 2:32

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 28 Oct 2009 at 7:26

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 28 Oct 2009 at 7:27

GoogleCodeExporter commented 9 years ago 
What is the status of this issue?  We are very interested in this, and were 
going to
submit it too, but found this issue.  Is this going to be included in a release 
soon?
Russ Clark,
Sandia National Laboratories,
Albuquerque, NM

Original comment by rdcl...@sandia.gov on 4 Dec 2009 at 5:35

GoogleCodeExporter commented 9 years ago 
It should be configurable i.m.o., but I've managed to exclude it without 
modifying the source: 
http://tech.kipusoep.nl/2012/01/06/umbraco-elmah-with-sql-ce-4-0-and-authenticat
ion-part-2/

Original comment by ralph.eg...@gmail.com on 6 Jan 2012 at 10:29

GoogleCodeExporter commented 9 years ago 
Please elevate this much needed feature to high priority and implement it in 
the next Service Pack.

We are all eagerly waiting for it since 2009 when it was first logged.

Original comment by ykhab...@gmail.com on 5 Feb 2012 at 8:02

GoogleCodeExporter commented 9 years ago 
Highly needed feature. Having the user password as part of the error log 
prevents us from using ELMAH in production environment.  Please implement.

Original comment by epignos...@gmail.com on 6 Feb 2012 at 2:00

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I think it is a good idea, add this feature

Original comment by jema...@miamigov.com on 6 Feb 2012 at 3:08

GoogleCodeExporter commented 9 years ago 
We would be a great feature. Please add it as soon as possible.

Original comment by ijgarci...@gmail.com on 6 Feb 2012 at 3:12

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
As a QA tester for web-application development, we are continually forwarding 
ELMAHs(emails) encoutered to development and QA team. Having my password 
concealed is a basic requirement for security(on a daily basis). Please 
implement this feature a.s.a.p in upcoming Service-Pack 2.

Original comment by webnetst...@gmail.com on 6 Feb 2012 at 3:16

GoogleCodeExporter commented 9 years ago 
Please add this feature, it is much needed. Passing the user information in an 
error message is a security issue.

Original comment by mannyot...@gmail.com on 6 Feb 2012 at 3:16

GoogleCodeExporter commented 9 years ago 
This missing feature is preventing us from using ELMAH for our Web based 
applications. It should be part of the ELMAH’s core configuration 
functionality. Having ELMAH’s 1.2 SP2 just for this single feature is a must.

Original comment by miria...@gmail.com on 6 Feb 2012 at 3:45

GoogleCodeExporter commented 9 years ago 
I am concerned about the password is included in the body of the Elmah message 
from the first day I started receiving them as result of my QA activities 
(2010). The priority of this request should be updated to HIGH.

Original comment by cvc...@yahoo.com on 6 Feb 2012 at 3:47

GoogleCodeExporter commented 9 years ago 
In my opinion, it doesn't take too much effort to add this feature and the 
benefit would be great. Please consider it as soon as possible.

Original comment by pcary2...@yahoo.com on 6 Feb 2012 at 4:22

GoogleCodeExporter commented 9 years ago 
We would like to implement this feature in our production environment but 
creating our own fork of the source is an undesirable option. Sending/logging 
the user password anywhere is a major security concern in most organizations.

Original comment by AnthonyV...@gmail.com on 6 Feb 2012 at 4:32

GoogleCodeExporter commented 9 years ago 
Hi there!

It's good to see so many people interested in this issue!
A few questions:

1) Are there any use cases for including AUTH_PASSWORD at all?

2) Should AUTH_PASSWORD be excluded by default?
i.e. <security /> <!-- no omitServerVariables -->
will automatically exclude AUTH_PASSWORD

3) If it is excluded by default how do you add it back in again?
Perhaps <security omitServerVariables="" /> gets it back.

4) Should the NuGet package be the one that does the exclusion?

Cheers,

James

Original comment by jamesdriscoll71 on 6 Feb 2012 at 4:58

GoogleCodeExporter commented 9 years ago 
In my opinion I believe AUTH_PASSWORD should be omitted by default. It seems to 
me that this is a feature that would be sought out for a particular purpose and 
not needed 99% of the time. The consequences of leaving this setting on without 
realizing can be disastrous.

Original comment by AnthonyV...@gmail.com on 6 Feb 2012 at 6:19

GoogleCodeExporter commented 9 years ago 
Hi James,

Thanks for the ideas on how to implement handling of the AUTH_PASSWORD server 
variable (and any other server variable)

1) Are there any use cases for including AUTH_PASSWORD at all?
Yes.

2) Should AUTH_PASSWORD be excluded by default?
i.e. <security /> <!-- no omitServerVariables -->
will automatically exclude AUTH_PASSWORD
It could be included by default.

3) If it is excluded by default how do you add it back in again?
Perhaps <security omitServerVariables="" /> gets it back.
If included by default, so by using comma separated list of values 
omitServerVariables="AUTH_PASSWORD,..." will disable  it.

4) Should the NuGet package be the one that does the exclusion?
Nice to have, but not mandatory.

Original comment by ykhab...@gmail.com on 6 Feb 2012 at 6:23

GoogleCodeExporter commented 9 years ago 
Hi James,

Thanks for the quick answer. This is my opinion about your questions:

1- Are there any use cases for including AUTH_PASSWORD at all? 
I can't think of a use case where it would be needed. But since it has always 
been part of ELMAH, some developers might rely on it for something. I would 
keep it for backward compatibility and for full coverage.

2- Should AUTH_PASSWORD be excluded by default?
i.e. <security /> <!-- no omitServerVariables -->
will automatically exclude AUTH_PASSWORD?
I think that excluding by default will be confusing. I would prefer to 
explicitly specify it using the idea of omitServerVariables.

3- If it is excluded by default how do you add it back in again?
Again, I don't think excluding by default is a good idea. It's not consistent 
with the way other server variables will be handled.

4- Should the NuGet package be the one that does the exclusion? 
Yes. I think we should make it a best practice not to include user passwords. 
Also, developers using the nuget package get the idea of how they can omit 
other server variables.

Original comment by epignos...@gmail.com on 6 Feb 2012 at 6:38

GoogleCodeExporter commented 9 years ago 
As stated above, I.M.H.O, AUTH_PASSWORD should be manually omitted. Please 
include in next SP2.

Original comment by webnetst...@gmail.com on 6 Feb 2012 at 7:01

GoogleCodeExporter commented 9 years ago 
I feel the configuration option for web.config to specify whether or not to 
store the value of the AUTH_PASSWORD server variable in error logs is a good 
idea.  I feel the better choice is to not have it at all or by default.

Original comment by bjwriv...@gmail.com on 6 Feb 2012 at 8:04

GoogleCodeExporter commented 9 years ago

Original comment by jamesdriscoll71 on 6 Feb 2012 at 8:25

GoogleCodeExporter commented 9 years ago 
Thanks everyone for your input. It really helps to understand the urgency of an 
issue and we're strongly re-evaluating whether or not this warrants 1.2 SP 2. 
Here is some background meanwhile.

This issue has really been seen as an enhancement so far (i.e. not burning) for 
two reasons: one, the original description had hints of extending the idea to 
all collections, and two, workarounds are available that do not require 
maintaining private builds of ELMAH. Being an enhancement rather than a bug, it 
could be deferred to a future release in order to implement the feature more 
broadly and correctly. It was not forgotten or neglected even though it may 
have appeared so. In fact, there's been considerable work on it in 2.0.

To be fair on other enhancements, this issue would have to be turned into a 
sufficiently inherent flaw and perhaps scoped down prior to warranting a 
service pack. It seems that most folks are concerned with AUTH_PASSWORD as the 
most problematic item. If we can agree that AUTH_PASSWORD should simply be 
masked without any need for re-instating it via configuration then it could be 
a really simple, practical and quick fix.

Original comment by azizatif on 6 Feb 2012 at 10:54

GoogleCodeExporter commented 9 years ago 
Hi azizatif,

I hope you hit the nail and everybody will agree with you.

The urgency and importance of the suppressing exposure of the AUTH_PASSWORD 
deserves “..simple, practical and quick fix…” on its own in ELMAH v.1.2 
quick fix.
No configuration is needed for that. 

We will all patiently wait for the more comprehensive solution covering 
flexible configuration of all collections in the future v. 2.0

Original comment by ykhab...@gmail.com on 7 Feb 2012 at 1:21

GoogleCodeExporter commented 9 years ago 
I do agree "... AUTH_PASSWORD as the most problematic item."!  If there is a 
"... practical and quick fix..." by simply masking it, it should be down.  It 
is too important to wait.

Original comment by bjwriv...@gmail.com on 7 Feb 2012 at 3:40

GoogleCodeExporter commented 9 years ago 
I agree as well, AUTH_PASSWORD may be masked.

Original comment by webnetst...@gmail.com on 7 Feb 2012 at 4:12

GoogleCodeExporter commented 9 years ago 
Azizatif, I agree that masking the password as a quick fix, while a 
configurable solution can come in a later release, is a great idea. It would 
make a world of difference. Thanks.

Original comment by ozzie.pe...@gmail.com on 7 Feb 2012 at 5:29

GoogleCodeExporter commented 9 years ago 
I can live with masking AUTH_PASSWORD solution only until a full feature to 
disallow any server variables is available.

Original comment by epignos...@gmail.com on 7 Feb 2012 at 12:23

GoogleCodeExporter commented 9 years ago 
I agree with everyone else, a quick fix will be appreciated. 

Its great to see so much response to this issue. I was afraid I was going to 
have to disable ELMAH in my production environment.

Original comment by AnthonyV...@gmail.com on 7 Feb 2012 at 1:45

GoogleCodeExporter commented 9 years ago 
I agree that AUTH_PASSWORD should be removed without any configuration until a 
new version is released.

Original comment by mannyot...@gmail.com on 7 Feb 2012 at 2:35

GoogleCodeExporter commented 9 years ago 
A few months ago I gave up on waiting for this security hole to be fixed.  I 
ended up deciding that while we (as a service department) did not want to give 
up this tool we could not use it as is so I modified the Error.cs file to mask 
AUTH_PASSWORD if it is not null.

Original comment by tnwhee...@gmail.com on 7 Feb 2012 at 4:56

GoogleCodeExporter commented 9 years ago 
I agree to remove the AUTH_PASSWORD as soon as possible, this is the most 
problematic issue and then implement a the full configurable solution.

Original comment by jema...@miamigov.com on 7 Feb 2012 at 6:52

GoogleCodeExporter commented 9 years ago 
I agree that AUTH_PASSWORD should be removed without any configuration until a 
new version is released.

Original comment by sorcer...@gmail.com on 8 Feb 2012 at 3:58

GoogleCodeExporter commented 9 years ago 
Thanks for the feedback, based on which the current plan is to release SP 2 
with AUTH_PASSWORD masked to 5 stars irrespective of the actual length of its 
value. This will not be configurable option.

Original comment by azizatif on 10 Feb 2012 at 5:56

GoogleCodeExporter commented 9 years ago 
Do you have a estimated timeline for SP2?

Original comment by iamw...@gmail.com on 14 Feb 2012 at 7:02

GoogleCodeExporter commented 9 years ago 
Since this issue has been scoped down to a simple fix, it should not take long 
at all. I was hoping that we'd be able to aim for end of February, rolling in 
one or two other fix as well. Unfortunately, we have run into a small problem 
with our SVN repo and working with Google Code to resolve it.

Original comment by azizatif on 18 Feb 2012 at 1:40

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 5 Mar 2012 at 8:25

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision 424039685a2c.

Original comment by azizatif on 5 Mar 2012 at 8:27

GoogleCodeExporter commented 9 years ago 
It looks like that all the issues: 140, 270, 273, and 278 destined to make SP2 
have been fixed.

We are all waiting when the SP2 will be published and available for download.

Original comment by ykhab...@gmail.com on 12 Mar 2012 at 5:01

GoogleCodeExporter commented 9 years ago 
@ykhabins: ELMAH is free and open source software where people volunteer to 
contribute in their spare time. As a general rule, we do not commit to 
deadlines. If you need the fixes urgently (or want to help with testing) then 
you always have the option to download the sources and build from them.

I would like to see 1.2 SP1 out soon like everyone else. Right now, some final 
touches are in flight and reviews being conducted in preparation for the 
release. I hope we can have those wrapped up to make a release this month, but 
again, that is not a deadline.

Original comment by azizatif on 15 Mar 2012 at 9:10

GoogleCodeExporter commented 9 years ago 
Since this issue was the prime driver for an 1.2 SP2 release, I wanted to drop 
in a special note here to thank everyone for the input and patience and to say 
that it's here! See the announcement[1] for details.

[1] https://groups.google.com/forum/?fromgroups#!topic/elmah/yDmDsiLH0uM

Original comment by azizatif on 10 Apr 2012 at 11:47