Enterprise Security API – OWASP AppSec NYC 2008
This presentation was by Jeff Williams, OWASP Chair, on the Enterprise Security API.
Vulnerabilities and Security Controls
- Missing - 35%
- Broken - 30%
- Ignored - 20%
- Misused - 15%
Goal is to enable developers. Need to give them hands-on training, a secure coding guideline, and an Enterprise Security API.
The problem with Security Libraries: overpowerful, incomplete, not integrated, broken, can't update, custom.
Enterprise Security API (ESAPI) includes authentication, user, AccessController, AccessReferenceMap, Validator, ENcoder, HTTPUtilities, Encryptor, EncryptedProperties, Randomizer, Exception Handling, Logger, IntrusionDetection, and SecurityConfiguration. Built on top of your existing enterprise services or libraries.
Some Examples
- Input Validation - validation engine and decoding engine that will take input and provide safe output for web pages
- Output Encoding - need to use the right encoding for the right place you are putting the encoding
- Authentication - creates a user object and functions to login() or logout(). Provides additional functionality for encrypted cookies, changing SESSIONID, remember me cookies, etc.
- Access Control - provides functionality to check if a user is authorized for URLs, functions, data, services, or files.
- Direct Object Reference Protection - use an access reference map that does an indirect translation between an object and it's reference. Use getDirectReference() and getIndirectReference() functions.
- Error, Logging, and Detection - Configurable thresholds. Responses are log intrusion, logout user, and disable account. User object is available anywhere in the application so the logger links the messages logged to a user. Exceptions sent to an intrusion detector which has thresholds set.
OWASP ESAPI Covers Majority of OWASP Top Ten
- A1. XSS - Validator, Encoder
- A2. Injection Flaws - Encoder
- A3. Malicious File Execution - HTTPUtilities (Safe Upload)
- A4. Insecure Direct Object Reference - AccessReferenceMap, AccessController
- A5. CSRF - User (CSRF TOken)
- A6. Leakage and Improper Error Handling - EnterpriseSecurityException, HTTPUtils
- A7. Broken Authenticationa nd Sessions - Authenticator, User, HTTPUtils
- A8. Insecure Cryptographic Storage - Encryptor
- A9. Insecure Communications - HTTPUtilities (Secure Cookie, Channel)
- A10. Failure to Restrict URL Access - AccessController
MITRE found that all application security tool vendors' claims put together cover only 45% of the known vulnerability types (695). They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true). This means that at least 55% is not covered by tools.
Latest version released in September 2008 (1.3.1) and are holding a summit later this year to determine if they got everything right. In active development. Java, .NET, PHP, classic ASP. Rich client extensions. Web service extensions. Framework (Struts) integration.
Written under the BSD license so it should be very easy for you to use it in your applciations.
Project Home Page: http://www.owasp.org/index.php/ESAPI
Expert advisory/design/implementation team that has collectively reviewed over 100 million lines of code. ~600 JUnit test cases. FindBugs, PMD, Ounce, and Fortify clean. Code review by several Java security experts. Penetration test of sample applications. Full Javadoc for all functions.
Presentation will be posted on homepage. Includes a list of banned API's that ESAPI replaces. Has example of enterprise cost savings. All of ESAPI is only 5000 lines of code. Building a ESAPI swingset which has a demo of insecure (what can go wrong) and secure (using ESAPI) programming and good tutorial on how to use. Login module shows last successful login, last failed login, number of failed logins, enforces a strong password policy.
Oracle + BEA = ?
We use Oracle Application Server as our Java app server at NI. Yeah, yeah, I'll wait till you stop laughing.
Why not JBoss or WebLogic or WebSphere? Well, a couple reasons. We made the decision five years ago, and JBoss wasn't solid then, and we needed J2EE support so plain Tomcat wasn't enough. And we're a huge Oracle shop and figured that if we were using the same app server on the Web and our ERP tiers there'd be leverage in terms of developer knowledge etc. Would we make that same decision today? I'm not sure about that (I can hear my team members shouting "hell no" over the cube walls). Although since we've also gone with Oracle's SOA suite for ESB and BPEL it would be harder to switch. But still tempting - Oracle has done a horrible job in getting their app server supported by other vendors. Every time we buy something and look at the supported app server section of their support matrix, and we ask "What about Oracle's OAS?" we get expressions of mixed horror and pity from the supplier. (I liked it when the Chinese technical guy from one eComm vendor we had in responded to this question with, "You know, the Tomcat is good, and free! Maybe you use that!")
Anyway, Oracle bought BEA a while back, which got keen interest from us. Stay with Oracle *and* use a good app server that other people support? Tempting! But Oracle's been farting around for six months without coming out with a statement on what this will mean for the products. Oracle's finally done a Webcast describing their strategy. Well, it's half marketing and a celebration of how many million dollars they have. But there's also a lot of product strategy in there. I'll sum it up for you because the damn webcast is nearly two hours long, and I don't want other people to have to waste that much time on it. Unless you like to hear someone go on about "strategic clarity" and "customer profiles," in which case this is two hours of bliss for you and you should watch it. Although I also had the stream break a bunch of times while watching. Who the heck uses RealPlayer any more? Anyway, here's a list of the interesting product facts from the Webcast. Some are marked with their timestamp if you want to fast forward to them and see more.