Minimum required properties in ESAPI.properties

Question

My web application uses only the following ESAPI encode methods:

• ESAPI.encoder().encodeForLDAP()
• ESAPI.encoder().encodeForHTML()

In this case, what is the minimum required properties in ESAPI.properties?

Now I'm using ESAPI 2.1.0.1 and this properties.

Answer 1

If you are just using the encoder() function, the 3 lines in the encoder section is all you need. Lines 99-119 (between all the comments).

Edit Plus you must specify a default encoder. Example:

ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder

Encoder.AllowMultipleEncoding=false

Encoder.AllowMixedEncoding=false

Encoder.DefaultCodecList=HTMLEntityCodec,PercentCodec,JavaScriptCodec

Answer 2

I think I answered a previous question.

Again you're the victim of some bad design choices back at the beginning of the ESAPI project between 2009-2011. Namely, the Singleton-based monolith.

ESAPI's current design is monolithic, meaning it tries to be everything to everyone. As you're well aware, this isn't the best design strategy, but that's where we're at.

We have several proposals for breaking various functions out into separate libraries, but that's future work towards building ESAPI 3.0.

For your current dilemma, there's too much of the library that is dependent upon functionality that it sounds like you don't need and don't intend to use. Unfortunately, that is simply the current fact of life. No one has ever seemed to use our authentication interface--but its there for everybody, even if they don't need it. Most users use our encoding/decoding capability first, followed by the validation API and then crypto. The last couple are log injection and the WAF.

Most users of ESAPI take the non-prod test file, and leave it at that. (This is a really bad idea.)

The others take the one you reference and work through the exceptions, asking us questions on the mailing list.

This is not an ideal path to walk either, but it's the path we're in right now.

The danger from my perspective, is if you choose to implement happy-path configurations for the ones ESAPI is throwing exceptions towards, with the goal of JUST making it happy so you can get to your two narrow use-cases.

Then you get promoted and another developer on your app is faced with a problem that she thinks is solved because you handled all the integration with ESAPI.

PAY ATTENTION TO THE PARTS OF ESAPI THAT DON'T PERTAIN TO YOUR USE CASE. This isn't ideal, but its where we're at in 2017. Ask us questions on the user list.

Failure to do so--especially in the crypto portion, will leave your application vulnerable in the future.

Answer 3

RegEx used in ESAPI.validator().getValidInput(..) calls

Validator.COMPANY_ID_PTRN=[a-zA-Z0-9]+
Validator.USER_DN_PTRN=[a-zA-Z0-9=,]+
Validator.ROLE_DN_PTRN=[a-zA-Z0-9=,^\- ]+

Minimum default settings

ESAPI.Encoder=org.owasp.encoder.esapi.ESAPIEncoder
ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory
Logger.ApplicationName=TrianzApp
Logger.LogEncodingRequired=false
Logger.LogApplicationName=false
Logger.LogServerIP=false
Logger.UserInfo=false
Logger.ClientInfo=false
IntrusionDetector.Disable=true
ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator
Encoder.AllowMixedEncoding=false
Encoder.AllowMultipleEncoding=false
ESAPI.printProperties=false