ESAPI
- Create a standardized mechanism for Java EE applications to address security concerns
- ESAPI is NOT a framework. It’s a set of well defined interfaces and a reference
- implementation of the “right” way to do security controls
Input Validation & Encoding
- Canonicalizing - reducing a possibly encoded string down to its simplest form.
- Double encoding is not something a user does so generally regarded as an attack
- Encoding - various methods for different destinations. Whitelist acceptable characters and encode those that don’t pass muster
- Validating - after canonicalizing, ensures data is of the correct type, in acceptable ranges, etc
- Supports either boolean returns or throwing exceptions “to allow maximum flexibility because
- not all validation errors are security problems”
- safeReadLine() to prevent DoS attack
- File name and directory path validation
- Basic credit card validation
- AntiSamy protection
Encryption
- Reference implementation utilizes Java Cryptography Extension (JCE)
- Ensure strong salt and password values are used - takes away the chance for developers to make poor choices for these crucial values
- Algorithms configurable via properties
- Seal - encrypts data and includes an expiration timestamp
Indirect Object References
- Reference implementation includes 2 concrete classes: integer based and random strings
- Defeats parameter tampering attacks
- Can help combat CSRF if per-user access reference maps are used
HTTP Utilities
- Provides useful methods relating to request, response, cookies, sessions, etc.
- addCSRFToken()
- changeSessionIdentifier()
- encrypt/decrypt fields
- safeXXX() methods for adding headers, sending forwards & redirects to ensure character encoding
- Reference implementation utilizes Apache Commons FileUploader
- Reference implementation relies on current request & response being stored in ThreadLocal variables - means you have to utilize the ESAPI authenticator or explicitly call ESAPI.authenticator().setCurrentHTTP()
Authentication & Access Control
- Reference implementation includes a file based authenticator.
- Provides login/logout capabilities, user authentication using hashed passwords
- Utility methods for password generation and to ensure account name and password strength
- Carries out some of the required setup for other components such as HTTPUtilities
Intrusion Detection
- Reference implementation has a default detector that does rudimentary calculations of number of errors per time period
OWASP Top 10 and ESAPI mapping
- Malicious File Execution
- HTTPUtilities(FileUpload)
- Insecure Direct Object Reference
- Leakage and Improper Error handling
- EnterpriseSecurityException, HttpUtils
- Broken Authentication and Sessions
- Authenticator, User, HttpUtils
- Insecure Cryptographic Storage
- Failure to Restrict URL access
Intrusion Detection
To enable intrusion detection in your application, the only requirement is to configure it to be enabled in your ESAPI.properties file. Simply set the IntrusionDetector.Disable property to be false and you are in business. Once intrusion detection is enabled in your application, any exception that extends the EnterpriseSecurityException will raise an event that the intrusion detector can be configured to respond to.
In the ESAPI.properties file you will find a section for IntrusionDetection with a sample configuration for events. You can add custom events here and configure what actions should be taken as well as thresholds for those events.
Introducing AppSensor
Some friends at OWASP took the ESAPI Intrusion Detector and some ideas that they had and built one of the most powerful application layer intrusion detection and prevention components available today. This project, called AppSensor - is built on top of ESAPI so it integrates seamlessly with ESAPI and provides fantastic protection to your application. I highly recommend using AppSensor for anything other than the most basic of intrusion detection and prevention needs.
Encryption
performing the encryption and decryption of sensitive information is incredibly simple.
view plainprint?
// Populate User Object from Request
// ...
// Encrypt Sensitive Information
CipherText encryptedSSN = ESAPI.encryptor().encrypt(new PlainText(userInfo.getSSN()));
userInfo.setSSN(new String(encryptedSSN.asPortableSerializedByteArray());
// Persist User Object
// ...
To decrypt the data is just as simple.
view plainprint?
// Retrieve persisted User Object
// ...
// Decrypt Sensitive Information
CipherText encryptedSSN = CipherText.fromPortableSerializedBytes(user.getSSN());
PlainText decryptedSSN = ESAPI.encryptor().decrypt(encryptedSSN);
userInfo.setSSN(decryptedSSN.toString());
// Prepare User Object for use in application
// ...
Of course this can be abstracted into a service, added as an annotation processor in your persistence layer, and altered to be used in a more generic form that meets your specific platform needs. Additionally, depending on the type of information you are dealing with and the perceived risk of that information being leaked - it may make sense for the data to be encrypted all the time until it needs to be viewed or altered on the front end. This approach can also increase performance of the encryption and decryption because you are only ever performing this step when it is needed.
The ESAPI Web Application Firewall
This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project. My notes are below:
WAF Fallacies (at least in regards to OWASP ESAPI WAF)
- WAFs add attack surface
- WAFs can create culture problems
- WAFs can't fix business logic vulnerabilities
- WAFs are way too expensive
- WAFs complicate networks
Why fix in ESAPI WAF vs Fix in code?
- Changing in ESAPI WAF is just a text file
- Shorter gap between time discovered and WAF fix vs code fix
Advantages of WAF
- Performance - Only your rules are checked, plus state is already managed by the app server
- Capability - being closer to the app lets us do more
- Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time
Principle: Make common tasks easy, uncommon tasks possible.
Notes:
- General virtual patching functionality is easy to understand.
- Ability to write custom script rules as well "bean-shell-rules"
- Fixing Injection Flaws is easy.
- Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control).
- Can add "outbound" security as well.
- Add anti-clickjacking header
- Set uniform content-type
- Add HttpOnly flag
- Add secure flag
- Detect outbound information
- Replace outbound information
- Takes advantage of early failing to make rules as optimized as possible
Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):
- Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
- Unchecked Redirect
- Add HttpOnly
- Add anti-clickjacking header
- Privilege escalation
3 Different WAF Modes
Latency with all of the rules turned on is about 5%. With selected rules is closer to 0%. Basically an order of n magnitude where n is the number of rules enabled. Comes out to milliseconds.
Using ESAPI with Struts
- extend the struts tag library and embed the ESAPI libraries within it.
- The biggest advantage of this approach is that there are no or minimal changes required to JSP pages. You can retro fit this solution into existing struts 2 application. The only JSP’s you may need to change are ones that use the s:property tag directly which are outputting into a HTML attribute, JavaScript or CSS.
Customizing the s:property Tag
At the core of the struts tags there is the property tag (<s:property ../>). You’ll find that all the struts freemarker templates use the property tag within them for actually outputting the values, hence also becoming the core of the problem.
The main problem with the property tag is that it has few options for escaping the outputs by default (escape and escapeJavaScript), and then what escaping it does do is fairly limited. So to get around this we’ll create a more robust version of the property tag that has options to escape for HTML attribute, HTML value, CSS etc.
General Use
The features of the new property tag can be used directly within a JSP page.
<s:property value="name" escapeHtmlAttribute="true"/>
An additional feature added to the property tag is the encrypt attribute. Setting this attribute to true will encrypt the value. According to OWASP object ID’s should not be used on their own, but they should be encrypted. Having the encrypt attribute makes it very easy to folow this rule. The value has to be decrypted in the action code.
Securing Inputs
- Inputs in this instance includes securing HTML forms as well as general HTTP requests that are sent to your application.
Servlet Filter
- Checks for double encoded values
- Valid characters, it needs to be fairly broad though (printable characters)
- Canonicalization
- ESAPI supplies the SecurityWrapper filter that will perform the above validation and sanitation. It can found under the following package: org.owasp.esapi.filters.SecurityWrapper
- The SecurityWrapper wraps up the HttpServletRequest and HttpServletResponse in it’s own copies. These wrappers validates and canoncalizes inputs included within the request as well as HTTP header values.
- The validation within the request and response wrappers is done using the ESAPI.validator().getValidInput(…) methods. The validation rules that this method uses is driven from the regular expressions set within the esapi.properties and validation.properties. The default expressions found within these properties files are very restrictive
The same theory applies for values within HTML forms. Any hidden values should also be encrypted to stop tampering. The same technique described above can be used.
Validation
Server side validation in struts can be done in a number of ways, within annotations or by using validation XML files. One can create custom validators and add them to Validator.xml file.
References
http://www.nutshellsoftware.org/software/securing-struts-2-using-esapi-part-1-securing-outputs/
http://www.nutshellsoftware.org/software/securing-struts-2-using-esapi-%E2%80%93-part-2-securing-inputs/
Appendix: Encodings
HTML character references
- Numeric character references can be in decimal format, &#DD;, where DD is a variable number of decimal digits.
- Similarly there is a hexadecimal format, &#xHHHH;, where HHHH is a variable number of hexadecimal digits. Hexadecimal character references are case-insensitive in HTML.
- Characters in the hexadecimal ranges 00–08, 0B–0C, 0E–1F, 7F, and 80–9F cannot be used in an HTML document, not even by reference, so "™", for example, is not allowed. However, for backward compatibility with early HTML authors and browsers that ignored this restriction.
- Character entity references have the format &name; where "name" is a case-sensitive alphanumeric string. For example, '?' can also be encoded as λ in an HTML document.
- If HTML attributes are not fully quoted, then you must entity encode whitespace like space, tab, and others
Attribute Encoding
Attribute encoding replaces three characters that are not valid to use inside attribute values in HTML. Those characters are ampersand ‘&’, less-than ‘<’, and quotation marks ‘”’. The first two for the same reason you HTML encode to prevent HTML injection attacks and the last one because quotation marks are used to define the value of the attribute.
Appendix: ESAPI API
Note: ESAPI canonicalizes input before validation to prevent bypassing filters with encoded attacks. Failure to canonicalize input is a very common mistake when implementing validation schemes. Canonicalization is automatic when using the ESAPI Validator.
Important Methods
Default canonicalize() method only decodes HTMLEntity, percent (URL) encoding, and JavaScript encoding. Although ESAPI is able to canonicalize multiple, mixed, or nested encoding, it's safer to not accept this stuff in the first place. In ESAPI, the default is "strict" mode that throws an IntrusionException if it receives anything not single-encoded with a single scheme. This is configurable in ESAPI.properties using the properties:
- Encoder.AllowMultipleEncoding=false
- Encoder.AllowMixedEncoding=false
& --> &
< --> <
> --> >
" --> "
' --> ' ' is not recommended
/ --> / forward slash is included as it helps end an HTML entity
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote.
Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. DO NOT use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.
Encode data for insertion inside a data value or function argument in JavaScript. Including user data directly inside a script is quite dangerous. Great care must be taken to prevent including user data directly into script code itself, as no amount of encoding will prevent attacks there. Please note there are some JavaScript functions that can never safely receive untrusted data as input – even if the user input is encoded.
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format. DO NOT use any escaping shortcuts like \"
Encode data for use in an XPath query. NB: The reference implementation encodes almost everything and may over-encode. The difficulty with XPath encoding is that XPath has no built in mechanism for escaping characters. It is possible to use XQuery in a parameterized way to prevent injection. For more information, refer to this article which specifies the following list of characters as the most dangerous: ^&"*';<>(). This paper suggests disallowing ' and " in queries.
Encode for use in a URL. This method performs URL encoding on the entire string.
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format.
References:
http://yet-another-dev.blogspot.com.au/
http://www.webadminblog.com/index.php/2009/11/12/the-esapi-web-application-firewall/
