When DefaultSecurityConfiguration is instantiated with Properties a NPE is thrown on calling methods getStringProp(), getBooleanProp(), getByteArrayProp(), getIntProp()

[hbroeder]

In ESAPI version 2.2.0.0 the methods getStringProp(), getBooleanProp(), getByteArrayProp(), getIntProp() in class DefaultSecurityConfiguration will throw a NullPointerException when DefaultSecurityConfiguration is instantiated using constructor DefaultSecurityConfiguration(Properties properties)

... Properties p = new Properties(); p.put("key1","value1"); SecurityConfiguration sc = new DefaultSecurityConfiguration(p); String kv1 = sc.getStringProProp("key1"); NPE...

[kwwall]

This seems to be related to GitHub issue #271 which had been closed, but apparently was already implemented at some point. (I'm too lazy at the moment to track it down via 'git blame'.) But this class was supposed to be a singleton and therefore should not have a public CTOR. (A protected or package level one, maybe; but IMO, not a public one.)

We can fix the NPE (if that is desirable; but that would we throw in that case? ConfigurationException), but because DefaultSecurityConfiguration is implemented as a singleton, I think this would involve significant re-design and refactoring to get it to work as intuitively expected.

Anyway, this clearly needs additional discussion.

[hbroeder]

Just to provide you with some context on how we got to this. We are building a solution that is going to run on k8s. Currently, we are exploring several scenarios for configuration management for our solution and the open source components it is relying on. One of those scenarios we are working on is can we somehow make our lives easier when dealing with configuration management and replace the different configuration implementations for those components with an abstraction that retrieves the configuration values from e.g. a database.

So, with regard to ESAPI can we somehow replace ESAPI.properties and validation.properties with some abstraction? Apparently, the ESAPI framework allows extension by suggesting a custom implementation class for interface SecurityConfiguration, which can be provided by means of System property 'org.owasp.esapi.SecurityConfiguration' (line 29 in ESAPI.java). Currently, we are playing with an implementation of SecurityConfiguration that retrieves data from a database and delegates to DefaultSecurityConfiguration.

[kwwall]

I'm not sure that the original intent of ESAPI's SecurityConfiguration was ever to provide a generalized security configuration mechanism where it could manage properties outside of the trusted ESAPI.properties file. I may be wrong about that, but if we you just want to manage properties in general, you probably should be using Apache Commons Configuration instead of ESAPI's SecurityConfigurator. The main idea behind the getStringProp(), getBooleanProp(), getByteArrayProp(), getIntProp() which I suggested was just to allow us to do a massive simplification of managing ESAPI specific properties (a work which is still underway, some of which I've done on my private BitBucket repo where I am making security fixes for CVE-2013-5960). The "problem" is without those new methods, we had to add at least one new method for every new ESAPI property that we added and that was resulting in an explosion of the SecurityConfiguration interface.

[hbroeder]

@kwwall I apologize. English is not my first language and I realize that this may have given rise to confusion. I understand the reasons of wanting to get rid of the "named" getters and refactor the interface. Also, I'd like to clarify that we do not wish to use ESAPI's SecurityConfiguration as a general means of security configuration management for our entire solution. On the contrary, our intent of research was more along the lines of: is it possible use/inject something like - let's say - Apache Commons Configuration to provide ESAPI's security configuration. I agree that ESAPI must rely on a trusted source for its security configuration. Whether the ESAPI.properties file (being read from the file system, classpath or whatever) can be considered as the trusted source by itself is somewhat doubtful because it is lacking means, for example, to establish its integrity or ensure confidentiality.

[kwwall]

@hbroeder - Regarding the integrity of ESAPI.properties, if that were important to people, the get thing is to put ESAPI.properties on your classpath inside of a signed jar or war file. Alternately, we could allow it signed it with something like GPG, but that would require not only code changes, but operational changes to those using ESAPI who wished to sign the properties file so I'm not convinced that would be used often enough to be worth the ESAPI dev team's investment. OTOH, if you can make a case for it, please do so and we will listen.

[pallavi-t]

Hi, Our System is under update from ESAPI 2.1.0.1 to 2.2.1.1 and we are facing challenge. Could you please guide us. CDSEsapiSecurityConfiguration is instantiated with Properties and JUL is used as of now. esapi-java-logging.properties file is used. At the time of application startup, NPE is seen.

at org.owasp.esapi.reference.DefaultSecurityConfiguration.getBooleanProp(DefaultSecurityConfiguration.java:1359) at org.owasp.esapi.logging.java.JavaLogFactory.(JavaLogFactory.java:58)

Could you please guide? Console.log .

[kwwall]

@pallavi-t -- You're problem seems very different than the description provided by @hbroeder who created this GitHub issue. If you believe this is a bug, then open a new GitHub issue and clearly describe how to reproduce it. Or at least provide a complete and full exception stack trace. (The attached console.log file was not complete.)

If all you are looking for is guidance rather than reporting a bug, then it is better to post to one of the 2 ESAPI related Google groups (see the README.md file) or post a question on Stack Overflow, which both @xeno6696 and I monitor for ESAPI related questions.

That said, I have a question for you. Have you read the 2.2.1.1 release notes? In particular, the section "Changes Requiring Special Attention" starting at line 41. I'd bet almost anything that is what your problem is related to. Read through that and see if it solves your problem. If not, then follow up in one of the other manners that I mentioned above, because I don't want to conflate 2 different problems into the thread of a single GitHub issue.