jmpcn / openid4java

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

ParameterList TRACE logging can leak sensitive information #157

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a org.openid4java.message.ParameterList with log level set TRACE.

What is the expected output? What do you see instead?

The ParameterList object will echo out all parameters, regardless of an 
"openid." prefix. The documentation does not explicitly call out this behavior, 
and the parameters could have sensitive information, such as the password, that 
could un-intentionally land in the log files. It is my opinion, that the 
documentation should call out this behavior, and limit the parameters logged to 
those only relevant to the openid protocol. 

What version of the product are you using? On what operating system?
openid4java-nodeps-.0.9.6

Please provide any additional information below.
This issue was noticed while creating a OP using Spring Security to intercept 
the login request, which via Spring's conventions will 'marry' the original 
request (the un/pass form post) with the auth success via request caching and 
forwarding. 
Spring Security will intercept the original request, then upon successful 
authentication, Spring will rebuild the original request and forward the 
request which can result (while at TRACE level) a leak of the un/password to 
the log files. 
*Note - I am not claiming that all Spring or Spring Security implementation 
would behave in this manner.....rather without close inspection of the 
parameters while building a org.openid4java.message.ParameterList, the un/pass 
could be leaked to a log file.  

Original issue reported on code.google.com by jl009...@gmail.com on 27 Jun 2011 at 10:35

GoogleCodeExporter commented 8 years ago
Don't think it's a specific library/implementation issue. DEBUG/TRACE log 
levels promise verbose logging information, of which server implementers should 
be aware by default (as well as of what their protocol messages may carry).

Original comment by Johnny.B...@gmail.com on 31 Oct 2012 at 9:27