Thursday, 23 June 2011

The ESTAPI idea

the ESTAPI (the Enterprise Security TESTING API) was an idea that pop-up a couple years ago at the OWASP AppSecEu in Poland.

Basically the idea is that what is more valuable to app/framework developers, is NOT another API that they have to bake into their product, BUT a set of Unit/Integration tests that they can use to validate what they are doing.

In this world ESAPI would be an example of what that could look like, BUT what would be the expectation is that app and framework developers implement the same 'behaviour/capability' into their code.

And then ESTAPI would be used to develop AND validate those capabilities.

Let's take a simple example: HtmlAttributeEncoding and JavascriptEncoding across the multiple ESAPI language implementation? (Java, .NET,PHP, etc...) Shouldn't ALL of them pass the same ESTAPI test? surely ALL should have the same behaviour right? (i.e. given the same input, provide the same output)

Same thing for the popular Java Frameworks (Spring, Struts, Tapestry, JSF, etc...). We should be using ESTAPI to measure (and understand) how those frameworks behave.

Of course that there are cases where the devs will chose to use the ESAPI.jar (& its dependencies), BUT my view for a while now, is that 'THAT esapi.jar' adoption should NOT be the first step in ESAPI usage. This 'adaption' COULD be one of the options later down the line, but the first step should be on a bunch of ESTAPI tests adapted to the targeted app.

What I also like about the ESTAPI idea, is that it will give drive (and push) the ESAPI team to really segment and separate the esapi.jar dependencies. Since it will be much easier (or practical) to write ESTAPI tests on single-focused JARs, with its dependencies injected (i.e. using DI)

Monday, 6 June 2011

FluentSharp - An API for .NET developers

Key to the OWASP O2 Platform environment is its ability to quickly write scripts and mini-tools. In fact I took that to such a level, that I now write O2 in O2 (i.e. without using VisualStudio).

At core of O2 Scripting there is an .NET development environment (by default in C# but any .NET language is supported), and since O2 is starting to be use independently by developers, I separated the O2 core into a new API which I'm calling FluentSharp (see CodePlex project http://fluentsharp.codeplex.com/):

The main http://fluentsharp.codeplex.com/ page contains an example of how this API works and the reasoning behind the 'Fluent' concept.

I expect developers to embrace this API since it can improve their productivity, while creating smaller and more readable code. The first place to start is to use FluentSharp to build Unit-Tests and Integration-Tests (which once created can be extended into Security Tests using O2 :)  )

Wednesday, 1 June 2011

Using O2 to exploit HacmeBank

Just posted this to the o2 mailing list:

Hi ..., no worries about being confused, O2 is VERY confusing for new users :)

On HacmeBank have you seen the O2 Scripts that automate a number of its exploits?

Here are a couple pointers for you to start:
Other resources:

Finally here is a exercise for you:

"...reuse this HacmeBank IE Automation script

public API_HacmeBank login(string userName, string password)
{
loginPage();
ie.field("txtUserName").value(userName);
ie.field("txtPassword").value(password);
ie.button("Submit").click();
return this;
}

on this script (instead of the Altoro SQLi)



(the SQLi script above will fuzz the login sequence and take a screenshot after each request
..."
Note that the scripts above are the ones that you will find on your local C:\O2\O2Scripts_Database\_Scripts folder