1

I have a was 9 server with two different web applications, each one with the esapi 2.1 library with its ESAPI.properties and validation.properties files:

A\webcontent\web-inf\esapi\ESAPI.properties
A\webcontent\web-inf\esapi\validation.properties
B\webcontent\web-inf\esapi\ESAPI.properties
B\webcontent\web-inf\esapi\validation.properties

In application B the validation.properties file has validations that are not in application A, when application B is alone works correctly but when the two applications are together the B application get properites files of A and does not load its validations so it gives an error.

I test changing B move the properties files in "src\esapi" and in "src\org\owasp\esapi\resources" and the same error always appears

The selected type was not set via the ESAPI validation configuration

java.lang.IllegalArgumentException: The selected type was not set via the ESAPI validation configuration
at org.owasp.esapi.reference.DefaultValidator.getValidInput(DefaultValidator.java:208)
at org.owasp.esapi.reference.DefaultValidator.getValidInput(DefaultValidator.java:185)

my web.xml:

<context-param>
    <param-name>esapiProperties</param-name>
     <param-value>/esapi/ESAPI.properties</param-value>
</context-param>   
<context-param>
     <param-name>validationEsapiProperties</param-name>
     <param-value>/esapi/validation.properties</param-value>
</context-param>

or:

<context-param>
  <param-name>esapiProperties</param-name>
  <param-value>/org/owasp/esapi/resources/ESAPI.properties</param-value>
</context-param>   

<context-param>
    <param-name>validationEsapiProperties</param-name>
    <param-value>/org/owasp/esapi/resources/validation.properties</param-value>
</context-param>
enK
  • 11
  • 1

2 Answers2

0

The use case you're attempting is against the design choices made by the original project maintainers. Because they implemented all the ESAPI classes as singletons, you can't instantiate two different instances of ESAPI within the same runtime instance, in this case, your instance of websphere. It's a classic race condition where the first application to load a resource is the one that wins. The decision I think partly is in response to the fact that the library was written with the idea of remediating broken websites, in which case Singletons help ensure yours is the one that loads.

The only solution at this time--are non-ideal. One is to merge all your validations into one instance, the other to deploy different applications to different instantiations of Websphere.

ESAPI 3.X is when I would expect to see a default that makes more sense.

avgvstvs
  • 6,196
  • 6
  • 43
  • 74
  • Merging all your validations into a single instance is probably your best option, although another option might be to write your own replacement for the DefaultSecurityConfiguration class and then set the System property "org.owasp.esapi.SecurityConfiguration" to your fully qualified class name from the 'java' command line. That would be a LOT of work though. – Kevin W. Wall Nov 18 '21 at 04:21
0

Assuming ESAPI 2.1.0 and a typical Eclipse dynamic web app with src folder:

  • Move ESAPI property files (ESAPI and Validation) into src/esapi and set custom filenames.
  • Delete any reference in web.xml about ESAPI properties (it doesn't have any effect)
  • Create a class extending DefaultSecurityConfiguration class, overriding getResourceStream method (signature InputStream getResourceName(String filename)) and return resource stream from app classloader. It is neccesary to evaluate filename parameter because of "configuration/validation file load" uses the same method (maybe filename.indexOf("validation"))
  • Create a class (with implements javax.servlet.Filter) that invokes (in doFilter) ESAPI.override() at each request. You must declare your new filter in web.xml (mapping requests as you desire).

Review javadoc annotation in override method if you need more information.

antoniosanct
  • 38
  • 8