Transcript Enterprise Security API (ESAPI) Kevin W. Wall ESAPI Project co-owner [email protected] Central Ohio OWASP August 18, 2011 Copyright © The OWASP Foundation Permission is granted to copy, distribute.

Enterprise Security API
(ESAPI)
Kevin W. Wall
ESAPI Project co-owner
[email protected]
Central Ohio OWASP
August 18, 2011
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP
License.
The OWASP Foundation
http://www.owasp.org/
You've been pwnd...
Obligatory CV




20+ years developer experience, 12 yrs security
experience

17 yrs at (now Alcatel-Lucent) Bell Labs; left as DMTS

3.5 yrs as independent contractor (C++ & Java)

12 years application & information security experience
Currently: Staff Security Engineer at CenturyLink (formerly
Qwest)
OWASP ESAPI for Java

Project co-owner

Cryptography developer (since Aug 2009)
OWASP ESAPI for C++


Meddlesome troublemaker
Blog: http://off-the-wall-security.blogspot.com/
Obligatory Disclaimer

The views represented here are solely my own (except where
I've reused someone else's slides) and do not necessarily
reflect the views of:

CenturyLink

OWASP

ESAPI development team

ESAPI user community

Any of my six cats
Overview


What is ESAPI?

Motivation

Vision

Goals
ESAPI history

Past

Present
ESAPI - Motivation

Security controls are difficult to get correct.



Requires attention to detail. Getting them wrong means
vulnerabilities.
Often requires development knowledge as well as extensive security
knowledge.
No single unified approach for frameworks

Within a given programming language

Across programming languages
ESAPI Vision
NOT THIS:
ESAPI - Vision
BUT THIS:

Build a common set of security controls for today's most
popular programming languages.




Have interfaces in common across programming languages as
much as possible and natural.
Provide at least a simple reference implementation for each security
control to serve as example if not useful in itself.
Easily extensible
Provide functionality that is most often needed, but lacking (or
inconsistent) in various frameworks / languages.
ESAPI - Goals


Develop open source security API that:

Is scalable to enterprise levels

Broad in its coverage of security controls

Liberal in its licensing (BSD, Creative Commons)
Encourage framework development teams and security
vendors to adopt ESAPI.

No intentional vendor bias

Covers areas where there are little broadly adopted standards
ESAPI History

Past

API conceived in June 2006 by Jeff Williams

Major ESAPI for Java releases:






1.0 in December 2007
1.1, March 2008
1.2.1, September 2008
1.3, September 2008
1.4, November 2008
2.0, May 2011

Present: 13 total programming languages represented!

Future

To be discussed at AppSec USA 2011 (more on this later)
Using ESAPI (1 of 3)

Getting started




https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security
_API
Download: http://code.google.com/p/owasp-esapi-java/
ESAPI Cheat Sheet:
https://www.owasp.org/index.php/ESAPI_Cheat_Sheet
ESAPI Swingset: http://code.google.com/p/owasp-esapi-javaswingset/
Using ESAPI (2 of 3)

Getting help

ESAPI User mailing list (focuses on Java version):
https://lists.owasp.org/mailman/listinfo/esapi-user


ESAPI Developer mailing list:
https://lists.owasp.org/mailman/listinfo/esapi-dev
ESAPI Project page: http://www.esapi.org/ (coming soon)
Using ESAPI (3 of 3)

Getting involved

Many other language implementations, all playing catch up

ESAPI for Java version needs help with user documentation

ESAPI 2.1 (Java) starting soon

ESAPI Swingset and Swingset Interactive → Port to use ESAPI 2.0
ESAPI Structure
–
ESAPI Homepage: http://www.owasp.org/index.php/ESAPI
Mapping OWASP Top Ten (2010) to ESAPI 2.0
•
•
A1: Injection
•
Encoder
•
A2: Cross-Site Scripting (XSS)
•
Encoder, Validator
A3: Broken Authentication and Session Management
•
•
A4: Insecure Direct Object References
•
AccessReferenceMap, AccessController
•
A5: Cross-Site Request Forgery (CSRF)
•
User (CSRF Token)
•
A6: Security Misconfiguration
•
Security Configuration
•
A7: Insecure Cryptographic Storage
•
Encryptor
•
A8: Failure to Restrict URL Access
•
AccessController
•
A9: Insufficient Transport Layer Protection
•
HTTPUtilities
•
A10: Unvalidated Redirects and Forwards
•
AccessController
•
Authenticator, User, HTTPUtilities
•
15
Potential Enterprise ESAPI Cost Savings
ESAPI 2.0 Maturity: The Good

Broad set of security controls

Solid implementations of many features

Generally defaults to secure mode
ESAPI 2.0 Maturity: The Bad

Complexity

Multiple ways to do things

Reference implementations rely too much on singletons

Using thread local data is double-edged sword

Bloated interfaces

Only “toy” reference implementations of several interfaces


Authenticator

AccessController
Asymmetric crypto still mostly broken
ESAPI 2.0 Maturity: The Ugly
ESAPI 2.0 Maturity: The Ugly


Dependencies galore

Would you believe 30 third party jars???

Dependency injection should help (target for 2.1)
Tight coupling



Most controls use ESAPI logging and exceptions; exceptions have
IDS dependency
Almost everything uses SecurityConfiguration
Difficult to handle variations within single application

Encrypt with different ciphers? Kludge required! (not thread-safe)
Basic ESAPI Approach – Examples

In Java:
String input = request.getParameter( "input" );
// Throws ValidationException or IntrusionException
// if problem
String cleaned =
ESAPI.validator().getValidInput("Secure input example",
input,
"SafeString", // regex spec
200, // max lengyh
false, // no nulls
true); // canonicalize
String safeHTML = ESAPI.encoder().encoderForHTML(cleaned);
Basic ESAPI Approach – Examples

In PHP:
$cleanTmp
= array();
// local in scope
$cleanParams
= array();
// local in scope
$cleanTmp['username']
=
ESAPI::getValidator()->getValidInput(
"Secure input example",
$input,
"SafeString",
200, false, true);
$cleanParams['username'] =
ESAPI::getEncoder()->encodeForHTML($cleanTmp['username']);
OWASP ESAPI Project Scorecard
Feature Set vs. Programming Language
Authentication
2.0
1.4
1.4
1.4
2.0
planned
Identity
2.0
1.4
1.4
1.4
2.0
planned
Access Control
2.0
1.4
1.4
1.4
1.4
2.0
planned
Input Validation
2.0
1.4
1.4
1.4
1.4
1.4
2.0
2.0
Output Escaping
2.0
1.4
1.4
1.4
1.4
2.0
2.0
Canonicalization
2.0
1.4
1.4
1.4
1.4
2.0
???
Encryption
2.0
1.4
1.4
1.4
1.4
2.0
Random Numbers
2.0
1.4
1.4
1.4
1.4
2.0
Exception Handling
2.0
1.4
1.4
1.4
1.4
1.4
2.0
2.0
Logging
2.0
1.4
1,4
1.4
1.4
1.4
2.0
2.0
Intrusion Detection
2.0
1.4
1.4
1.4
Security Configuration
2.0
1.4
1.4
1.4
2.0
TBD
WAF
2.0
1.4
1.4
Using ESAPI – A Simple Example
(from Swingset Interactive)
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF8"%>
<%@include file="header.jsp" %>
<%
String name = request.getParameter("name");
if ( name == null || name.equals("") ) name = "anonymous";
%>
<h2>Exercise: Enter Malicious Input</h2>
<form action="main?function=OutputUserInput&solution" method="POST">
<p>Enter your name:</p>
<input name='name' value='<%=ESAPI.encoder().encodeForHTMLAttribute(name) %>'>
<input type='submit' value='submit'>
</form>
A Simple Example (continued)
<!-- Continued from previous page. -->
<p>Hello, <%=ESAPI.encoder().encodeForHTML(name)%></p>
<code>
<%
String encodedName = ESAPI.encoder().encodeForHTML(name);
encodedName = encodedName.replaceAll("&", "&amp;");
%>
<!-- Show what the HTML actually is encoded as. -->
Source:
<%=encodedName %>
</code>
<%@include file="footer.jsp" %>
Using ESAPI – Advanced Example

So, for any of you using Google+, does this look familiar?
https://plus.google.com/_/notifications/ngemlink?path=%2F%3F
gpinv%3DgU47oPXLOt8%3Apox7sn5mwqF

It's an invitation to join Google+ that you email to your friends.
Presumably, this is a cryptographic token (although it could
just be an object reference into some database).
Question: What if you wanted to implement something similar,
but say for a coupon service that you could email to one of
your friends for some specific merchandise and you didn't
want to have to store it in a database?

You could do it with an appropriate cryptographic token.
Advanced Example (cont'd)
What information would you need in this cryptographic token? How
about:
1) The currently authenticated user's user account name
2) The target user account name of your friend
3) A merchandise ID
4) The coupon value
5) The coupon expiration date
Of course, you want it to be secure in the following sense:
a) protection of all identities involved (confidentiality)
b) unforgeable
c) secure from tampering
d) immune to replay attacks
How much code would that take you?
Advanced Example (cont'd)
With ESAPI, it's something like this:
// Creating the token…
CryptoToken ctok = new CryptoToken();
ctok.setUserAccountName(
ESAPI.authenticator().getCurrentUser() );
ctok.setAttribute("targetUserAcct", targetUserName);
ctok.setAttribute("merchandiseID", merchandiseId);
ctok.setAttribute("couponPrice", price);
byte[] nonce = ESAPI.randomizer().randomBytes(16);
ctok.setAttribute("nonce", Hex.toHex(nonce, false) );
// Store nonce somewhere to prevent replays.
ctok.setExpiration( 30 * 24 * 60 *60 ); // 30 days (in secs)
return ctok.getToken(); // Return encrypted token
Advanced Example (cont'd)
// Consuming the token…
CryptoToken ctok = new CryptoToken(tokenString);
Date expDate = ctok.getExpirationDate();
// Check if expDate > current date and do something ...
String hexNonce = ctok.getAttribute("nonce");
// Check if nonce replayed; error if yes. Rm from table...
String targetUserName = ctok.getAttribute("targetUserAcct");
String MerchandiseId = ctok.getAttribute("merchandiseID");
String price = ctok.getAttribute("couponPrice");
// Logic to remove available coupons from originating user
String userAcctName = ctok.getUserAccountName();
...
Extending ESAPI to Use AppSensor

ESAPI reference model comes with a rudimentary intrusion
detection system.


It's usable, BUT...AppSensor is way more cool. (That's a different talk!)
To change ESAPI to use AppSensor, modify the following line in
the ESAPI.properties file:
ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector

The line above should be changed to:
ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector

Add the AppSensor jar to your app's classpath.

Customize AppSenor's configuration files to your liking.
Extending ESAPI in General

Find the interface you wish to define / extend.

Create a new class that implements said interface.


Use reference implementation as a model when appropriate.
Find where that interface is used in ESAPI.properties file and
replace the fully qualified class name of the reference
implementation with your fully qualified class name. (See
AppSensor slide for an example.)

Make sure you new class in your application's classpath.

Test and retest.

If generally useful, contribute to ESAPI via “contrib”

Email ESAPI Dev list (see “Getting Help” slide) to contribute.
ESAPI Future Directions

ESAPI Summit at AppSec USA 2011

Plan overall ESAPI direction

Plan ESAPI 2.1 for Java



Eliminate 3rd party jar dependencies using dependency injection
Other road map items
For details, see https://www.owasp.org/index.php/ESAPI_Summit
What I Learned

Frustration





Humor very important; self-deprecation works great.
(So does promising someone a beer. Just hope I don't see them all
at once!)
Development moves slow compared to your day job. Patience!
Reward

Opportunity to work with some of the best in the business

Increases your visibility (for better or worse)

Eliminates rusty coding skills (if it applies)
More frustration

Waiting on NSA, and waiting, and waiting

More frustration: Can't share detailed findings. :-(
Q&A
l
Ask now, or email me at: <[email protected]>