[Esapi-user] [Esapi-dev] Esapi logging question

Chris Schmidt chrisisbeef at gmail.com
Sat Jan 23 20:22:56 EST 2010


Sounds like this could be solved with some property annotations in 2.0 -
1.4.3 maybe a doclet tag on specific properties?

On Sat, Jan 23, 2010 at 4:25 PM, Kevin W. Wall <kevin.w.wall at gmail.com>wrote:

> Craig Younkins wrote:
> > Jim,
> >
> >>> When Esapi boots, it prints the properties file, and some other
> > events, to System.out.
> >
> >> This is a significant security concern (ie: logging the master salt and
> > other security critical information). This section of the code has been
> > commented out in both branches
> >
> > Just wanted to point out that that code was designed to not disclose all
> > configuration variables. It would filter out any parameter with "Master"
> in
> > the name, so the MasterSalt has never (?) been printed during the parsing
> of
> > the configuration.
> >
> > That being said, I don't think that was a great solution either. I would
> > love to see a boolean configuration variable indicating whether or not to
> > dump the configuration to the console AND a globbing configuration
> variable
> > indicating what to never print. Something like....
> >
> > General.PrintConfiguration = true
> > General.NeverPrint = "Master*, General*"
> >
> > Comments?
>
> There is already a boolean property called      ESAPI.printProperties
> that does what your first option would do. You may have never noticed
> it because I had it default to 'true' for backward compatibility.
> However it is set to 'false' in src/test/resources/.esapi/ESAPI.properties
> so these don't print out while running the JUnit tests. (I just found
> it too annoying to parse through that over and over again just to find
> some specific console output and I figured backward compatibility would
> not be an issue with the JUnit tests.)
>
> However there is nothing to account for just making it shut-up for specific
> properties. And if we really just don't want it to print potentially
> sensitive
> values out, perhaps we should just name them with 'sensitive' as part of
> the
> property name (e.g., 'Encryptor.sensitive.MasterKey' rather than
> 'Encryptor.MasterKey', etc.) and just automatically skip those "sensitive"
> properties. I'd hate to leave it up to ESAPI users to determine what is
> sensitive and what is not. (So in that sense, it's a good thing that
> Encryptor.MasterKey and Encryptor.MasterSalt are always skipped.)
>
> Just my $.02,
> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>



-- 
-- Chris

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Coming soon OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100123/a5658eaa/attachment.html 


More information about the Esapi-user mailing list