DATDA

Defense Against The Dark Arts - ESAPI

Chris Schmidt

Aspect Security

Cheif Architect / Application Security Engineer

Open Web Application Security Program

Leader - Enterprise Security API

Member - Global Projects Committee

chris.schmidt@aspectsecurity.com

---

1. Don’t Panic

The key to securing your enterprise, and you applications is to not give into FUD. Don’t Panic - there is a solution, if fact - there are a lot of solutions. In this paper we will talk about one solution, the Enterprise Security API and how you can leverage it to address some of the key concerns in protecting your application.

2. Enter the Enterprise Security API

The Enterprise Security API is a free open-source library designed to make it simpler for developers to retrofit security into existing applications or provide a strong foundation for new development. The core of the ESAPI are the interfaces which expose easy-to-remember methods that enable developers to use security controls in an application without having to focus on how to implement it.

The API includes a basic set of reference implementations of the various components which allows ESAPI to be used almost completely out-of-the-box with very little configuration for standard tasks such as validating user input, encoding untrusted output, and dealing with difficult requirements like encryption.

3. Open Source Software

ESAPI has one of the most liberal open source licenses available, allowing you to use the library in other open source projects, commercial ventures, and alter the code however you see fit.

4. Community Driven Development

The ESAPI community drives our feature set and development. We listen to what the community is asking for and try to simplify it into interfaces that are easy for developers of any level to understand and use

ESAPI aims to bridge the gap betwen innovation and security by enabling developers to focus their energy on functionality with the confidence that the security just works.

5. Installation

Installing ESAPI is extremely easy

First you have to download the distribution from the ESAPI website. Then you simply extract the distribution and copy the library and it’s dependencies into your application’s classpath.

If you are using Apache Maven to manage your dependencies, this step is even easier, you simply add ESAPI as a dependency for your application and it is there for you to use.

The final step is to copy the configuration files for ESAPI into your application’s classpath. If you use maven, you will have to download the starting configuration files from the ESAPI site.

6. Configuration

The only requirement to start using ESAPI is to configure it’s master salt and master key for the encryption routines. The ESAPI README explains in detail how to perform this step.

Once you have your master salt and key generated and entered into your ESAPI.properties file you are ready to secure your application. It’s really that simple!

7. Top 5 Ways to Protect Your App and Not Get Pwnd

Now let’s talk about how to use ESAPI - how can you leverage the ESAPI to make sure that next year’s presentation will not highlight a breach in your application?

7.1 #5 - Encrypt Sensitive Information

Number 5 on our countdown is to make sure that every piece of sensitive information you are storing on behalf of your customers is encrypted. There is nothing more embarrassing for an organization than to have to send emails or make phone calls to your entire customer base notifying them that not only was there a breach in your product, but that you have also leaked their credit card numbers, social security numbers, or some other piece of personally identifiable information about them.

The Sony Playstation Network breach was one of the largest single data breaches last year - netting over 77 million records. Many have called this one of the worst breaches of all time.

Sony made claims that the breach was the result of the so-called “Advanced Persistent Threat” An advanced persistent threat is an agent that is embedded into your systems in an undetectable manner for some period of time. During that time, the agent is collecting information and infiltrating further and further into your network.

In fact it was unpatched and out of date software on Sony’s publicly accessible servers that was the source of the breach. It hardly takes an advanced attacker to launch a port-scan and fingerprint your publicly accessible servers, and when they are running out of date software there are a million places where a potential attacker could obtain pre-fabricated exploits to get in.

The result of the breach was the initial loss of 77 million records and a second breach led to the loss of an additional 25 million records from other Sony properties.
What information did the attackers really get? Well - every piece of information that I list here is valuable to an attacker, especially attackers that may want to become that advanced persistent threat or those looking for a quick buck by selling off the personal information of a hundred million people.

Full names, addresses information, email address, birthdate, PlayStation Network credentials, answers to the security questions and potentially credit card information was stolen.

Originally Sony claimed that no credit-card information was leaked and that customers should not be concerned about them - later they backpedalled saying that credit card information “could” have been stolen. This insinuates that either A) the credit card information was not actually encrypted, B) the credit card information was not encrypted with decent encryption algorythms, or C) the attackers also obtained encryption keys which allowed them to decrypt the information.

Everything else is presumed to have been stored in clear text in the database. What could you do with all that information?

It is important to remember that credit card information is not the only sensitive information that we store about our customers. Anything that could be considered personally identifiable information about those customers should be treated as sensitive information and protected accordingly.

Using the ESAPI encryptor allows you to easily encrypt sensitive information before it ever goes to the database and decrypt it before it is used in your application with a couple simple lines of code.

7.2 #4 - Monitor User Behavior

At #4 on our list we encourage you to be your own little “Big Brother” for your application. Your application is like your opwn little nation in a huge world of applications, and as the business owner you are the government for your application and your users are your citizens. You are, to use the words of a good friend of mine, their “Benevolent Dictator” in the virtual world. They look to you for protection, enforcement of local laws, and most importantly to give them cool new stuff. While the “Big Brother” approach scares the hell out of most people in the real world - it is an extremely natural and well-accepted approach to information security. Intrusion Detection and Prevention systems have been deployed on networks for decades. They are a proven effective means of stopping attacks before they occur or notifying administrators that something is up. Traditional IDS/IPS systems however have fallen short in the application tier. ESAPI introduces an application layer Intrusion Detection system to address this concern.

The most important piece of using an application IDS is to understand your users’ behaviors. Typical good user behavior on a login page has a simple story - User comes to login page, user enters credentials, credentials are verified, and the user is logged in.
However, we all know that no one is perfect, and even the best of us occasionally mistype a password or username.

But what about a user that comes to your application and tries several username and password combinations. This seems like suspicious behavior. With intrusion detection you can identify these patterns and flag them. Once you have identified them you can instruct the application to simply monitor the situation and notify someone about it or you can tell the application to take action and maybe blacklist an ip-range for 5 minutes or lock out the valid usernames and send an email to the owner of the account letting them know that you have noticed suspicious activity and have temporarily locked out their account with instructions on how they can resolve the situation.

Some friends at OWASP have taken this idea and turned it into one of the best solutions available today for application runtime intrusion detection and prevention called AppSensor. AppSensor installs sensors throughout your application to watch for patterns in user behavior and empowers your application with the ability to respond to potential threats before they become attacks.

Additionally, AppSensor is built on top of ESAPI functionality so it integrates seemlessly into the ESAPI for complete coverage in your application. It allows you to quickly and easily deploy powerful intrusion detection and prevention into your application with very little overhead.

7.3 #3 - Fix Your URL

Perhaps what has lead to some of the least advanced and most fruitful attacks of all time is simply providing attacks with everything they need right in your URL or on a form. Allowing attackers to much around with things like account numbers, amounts, and other pieces of information that should be tied to them directly opens up a whole new world of hurt for your application. Don’t believe me? Just ask Citigroup.

Citigroup made the mistake of allowing a user to specify which of their accounts they would like to access. There’s no harm in that, but they also neglected to verify that this value that was being given to them by a client was indeed an account that was associated with the client themselves. As a result, over 200,000 credit cards were compromised and leaked to the internet.

How does that work though? How can an attacker so readily access someone elses account information. I don’t want to pick on Citigroup any more at this point so we will replace them with an organization called “Big Bank Inc.” which has an online banking portal. We’ll say for the purpose of this demonstration that the developers over at Big Bank have made it even easier for the attackers than Citi did by exposing the account number in clear readable format right in the URL bar of the browser. So let’s say this is your application URL. This URL allows you to load up all the pertinent details about a specific account. Now, what happens if I just tweak the account number on the URL a little bit?
This is an Access Control problem with a couple different solutions. Most applications have no concept of data level access control, so retrofitting them with such a thing may be well beyond the budget for resolving the issue. In the example of Big Bank, Inc. or Citigroup for that matter, this would be the solution that makes the most sense. The risk of exposing customer’s banking information is pretty serious and you want to ensure that even if I make the account number harder to guess that if an attackers happens to stumble across one that maps that they can’t just access it on luck. Using ESAPI, the function used by developers to make this access control decision is as simple as a single line of code. Is the logged in user allowed to “view” the specified account number?

However, extensive data access control doesn’t make sense for every application - a lot of the time it is a great deal more trouble to implement and manage than can be justified by the risk. In these situations a different approach can be used. ESAPI introduces the concept of the Indirect Object Reference Map. This map is populated when a logged in user queries for their data. For instance a customer may have 4 accounts in their name - when the query to the database says “Get me all accounts where the customer’s id is ‘Bob’” the 4 accounts are retrieved. The indirect object reference map stores a reference to that object based on something other than a piece of data directly tied to that account. For instance a random string of characters or random number is often used as the reference key.

This approach solves two problems - it eliminates the direct reference, for example the account number, from having to be passed around between client and server, and second it limits the data that a customer can access to only the data that is prepopulated in the indirect object reference map.

7.4 #2 - Validate User Input

Let’s talk about Validation - and even more, let’s talk about HBGary Federal.

There are a lot of lessons to be learned from the HBGary Federal hack. The first and most obvious probably being if you don't keep a clean house, it's probably best not to go leaving the front door unlocked and tell every thief in town that you are coming for them.

Like most successful hacks, this attack had a lot of layers and the first layer was predictably simple to peel back. HBGary used a CMS system for their website - an old, clunky, custom written job that had been neglected for a decade with no updates.

The assumption that a lot of business owners are guilty of making is that there is nothing of value on their website, it is just a public facing system and it's not like we even take credit cards! In a perfect world, this may be true - unfortunately, we live in an imperfect world where people, yes even people trained not to do so - share passwords across several systems.

When anonymous discovered the SQL Injection flaw, they grabbed the user database from the HBGary Federal database. Among the users were Aaron Barr (CEO) and Ted Vera (COO) both of which were administrators for the CMS system and also in positions of power within the organization.

As a result of the shared passwords, anonymous gained access to shell accounts, e-mail, twitter and linkedin accounts for both Aaron and Ted and the rest, as we say - is history.

SQL Injection is to date one of the most pervasive flaws on the internet. It is quite literally all over the place. Experts have been talking about it for nearly a decade, frameworks have introduced defenses against it, and still it is as simple as firing up the open source sqlmap on nearly any website on the internet and being a little patient until the flaw is discovered and exploited. The vector is so well known and documented that attackers don’t even have to do anything anymore other than know how to use the command line to run a tool that does all the discovery and exploitation for them.

In it’s most naive form (which is what was present on the HBGary Federal CMS System) SQL Injection is performed by simply injection some valid SQL right into the parameter on the URL. Using a single tick to break out of the data context and execute the sql passed in.

In this example, a simple validation verifying that the parameter passed in was indeed just a number could have prevented a world of hurt (at least for a few minutes) for HBGary Federal.

So how does this problem keep happening over and over again throughout the internet? It’s simple. A lot of programmers attended a Computer Science program in school Whether or not they finished it is completely irrelevant. Nearly every book in existence illustrates the insecure way to access a database from an application. By dynamically constructing a string and appending untrusted, or tainted data as we call it, into the sql query. This problem is not specific to any one language. As a matter of fact, nearly every programming book I have seen for every language has illustrated this as the first example of a database connection.

A better way to do it would be to show that the information is being validated prior to being appended to the string to ensure that the value being appended is what the application expects and not something else.

The best way is to not rely on your developers at all and instead rely on the database vendors by using Prepared Statements, or parametrized queries that know how to properly escape for the database implementation you are using. In the rare event that this is not a possibility it is unequivocally important to ensure that the data is validated and sanitzed prior to being included in a query to the database.


7.5 #1 - Display Data Properly

Number 1 on our countdown is by far the solution to the most prevalent flaws on the web today. Displaying your data properly - or as we call it in the security community, output encoding or output escaping.

Cross Site Scripting is nothing new to social networks. By their very nature, social networking sites have to have a more lax validation policy where html is concerned - users expect to be allowed to customize their public profiles, add widgets and videos and do stuff that they normally would be able to do on other sites. Every social network has suffered worms - self propogating cross-site scripting exploits that spread like wildfire throughout the network.

Facebook is no exception to this rule and suffered one such attack last year. The attack first exploited human behavior by claiming to be a video of a bully . Secondly, the attack exploited the behavior of the php parse_url function, which would handle the input differently if it started with whitespace. The page featured a placeholder image that looked like a video player "preview" like you see on youtube, when the user clicked on the video to play it, the exploit (which started with whitespace) - the exploit added a script element to the page and loaded anything it wanted from evilhax0r.com while playing the requested video for the user. Most users didn't even realize that they had been compromised until later.

Let's talk about XSS for just a second. XSS is still one of the most underrated bugs there is due to the fact that a lot of people don't really grasp the full scope of what is available to an attacker when they discover an XSS vulnerability in your application. The likelihood of an attacker successfully exploiting an XSS bug is dependant on whether it is persistent, reflected, or DOM-Based. In the case of Facebook's Bully Worm - it was a persisted reflective XSS attack. That is to say, the attack itself was persisted but still required user interaction by way of enticing them to click a link to execute the payload. So why is XSS so dangerous?

Using XSS an attacker can gain complete control of your customer’s browser. They can do things like install a keylogger to monitor and report keypresses capturing credit card numbers and passwords, install malware on the customers computer allowing them permanent backdoor access into that system, or stealing the users authenticated session to “become” them on your application.

When it comes to displaying user-provided data in your application, knowing the context in which that data will be displayed is the key. I’m sure this comic strip would sound a great deal less dirty if we understand the context where it appears in the story.

In web applications there are many contexts in which user-provided or otherwise untrusted data can be displayed. Each context has it’s own set of rules for escaping. ESAPI exposes these well-known contexts in a simple bohemian style to ensure that developers are escaping correctly when they display untrusted data on a page. Whether that data will be displayed between 2 HTML tags, the value of an attribute, as part of a url in a link, data assigned to a javascript variable, the value of a style definition, an element within a block of XML, a value of an XML attribute, an XPath query string, or one of many other contexts.

Escaping data correctly ensure that even if a crafty attacker finds a way to bypass your awesome data validation and embed an attack payload into your application, that the attack itself is rendered useless by not allowing the attack to break out of the data context and become code.

8. Conclusion

If you garner any key piece of information from this presentation, I can only hope that you take away the importance of writing secure application code to protect yourself and your customers from attacks. I have presented today information on 5 ways you can protect your application, how you can leverage the Enterprise Security API to do so, and what the fallout of not doing so could be. As entrepeneurs and businessmen we can no longer afford to rely on our crunchy perimeter security to protect the soft chewy center of our enterprise - we expose our applications to the world and by doing so, we expose ourselves and all of our customers to the risks of doing so. It is our responsibility as organizations, consultants, and customers to ensure that everything is being done to protect our information and our customers’ information.