The problem is that we don't have any hard data that supports either side of the argument (i.e. if it is easy or hard to fix security issues?). So here is a challenge that should provide some visibility into this important question.

Challenge: Fix the SQL Injection vulnerabilities that exist in this version of Hacme Bank.

• You are free to use whatever techniques and tools you have and are comfortable with
• The fixes should be provided as a new code drop or as a diff of the current version.
• Please take notes of HOW MUCH TIME and effort it took to fix the problems
• Ideally, detailed information about the fixes would be provided
• Ideally, detailed information about the Workflow used to 'apply and test' the fixes would be provided

Let us know if you are taking this challenge

Good luck

Challenge: Perform a security review on Microsoft's demo app .NET StockTrader Sample Application starting with the security issues disclosed here NET StockTrader from MSDN: The new WebGoat? and seing if more can be discovered.

Extra items:

• There is a reply comment from Microsoft's Gregory Leake saying they will fix this, so it will be interresting to compare the before and after versions
• Analyse previous versions of this application and map their security profile (would be quite interresting to be able to track the lifecycle of a particular vulnerability across multiple releases)

Challenge: Wrap WebServices around the new (under dev) OWASP proxy and consume them from O2. The idea is to be able able to control this Proxy (which is a spin of from OWASP's WebGoat) from O2's WebAutomation modules in order to:

• Help with PoCs
• Allow the creation of site maps 
• Allow the reconstruction of the exact sequence of request/response events
• Show how O2 can integrate with Java Apps

To kickstart the process Here is Rogan's description on the owasp-leaders mailing list:

The OWASP Proxy is intended as a library that can be used by developers of tools like WebScarab, so that they don't have to reinvent the wheel.

As mentioned in my original mail, some people are taking the proxy classes from WebScarab and wrapping their own code around them. Unfortunately for them, WebScarab's proxy was never designed for this,
and consequently they had to mess around with a bunch of dependencies that the WebScarab proxy class requires, but that they had no need for themselves.

WebScarab's proxy and HttpClient implementation were also not as "binary-clean" as some people would have liked. For example, while parsing message headers, WebScarab would normalise "Host:  host" (note
two spaces between ":" and "host") back to "Host: host" (only one space). For some people, that was a big deal, and prevented them from using WebScarab entirely. Amongst other things, it meant that WebScarab
was unsuited to testing client-side vulnerabilities. OWASP Proxy uses a byte[] to represent the entire message that is sent between client and server and vice versa, and then layers more friendly methods for accessing specific message properties on top of that.

So, OWASP Proxy is intended to address these issues. It is a small (45kB jar) library (not a stand-alone executable) that Java developers can use when they need to add intercepting or logging proxy capabilities to
their own programs.

OWASP WebScarab-NG will be rewritten around this library as time permits.

For interested people, the simplest proxy would look something like:

  import org.owasp.proxy.daemon.Listener;

  Listener l = new Listener(8008);
  new Thread(l).start();

  // wait until told to exit

  l.stop();

This obviously has no customisation, though.

To customise the listener, extend the Listener class:

  public class MyListener extends Listener {

   public MyListener(int port) throws IOEception {
     super(port);
   }

   @Override
   protected Response requestReceived(Request request)
     throws MessageFormatException {
     request.deleteHeader("Accept-encoding");
     return null;
   }

  }

This example disables transfer of gzip or deflated content, by preventing the Accept-Encoding header from reaching the server.

Similarly, one can intercept responses by overriding two methods:

 @Override
 protected boolean responseHeaderReceived(Conversation conversation)
   throws MessageFormatException {
   return false; // default is true
 }

 @Override
 protected void responseContentReceived(Conversation conversation,
   boolean streamed) throws MessageFormatException {
   conversation.getResponse().deleteHeader("Set-Cookie");
 }

One overrides "responseHeaderReceived" to return false to disable response content streaming. OWASP Proxy defaults to streaming response contents to the client as chunks are read from the server. This makes the proxy more responsive, as the response content does not have to be buffered in the proxy before being sent to the client. However, if you want to modify the response in some way, you don't want it being streamed to the client before you can modify it.

"responseContentReceived" is called once the entire response has been read from the server. If the "streamed" parameter is false, (resulting from responseHeaderReceived), then it is possible to modify the response and have that modified response returned to the client.

At this stage, it is not possible to modify the response headers in "responseHeaderReceived". This is a limitation that I'd like to remove. With any luck, it should not prove to be too difficult. Naturally, caution should be exercised when modify response headers if the content has not yet been read, as it could change the way in which the response content is interpreted by the OWASP Proxy. e.g. removing a "Transfer-Encoding: chunked" header!

As you can see, I'm quite happy to discuss the OWASP Proxy with interested parties! I look forward to your feedback.

Rogan

In previous versions of O2, I've tried to use GraphViz and Glee, but the fact that they were not dynamic (like the graphs in the UbiGraph examples) created a number of limitations which I felt could only be resolved once we had a better visualization engine (GLEE is still used by the TraceViewer module in O2).

The UbiGraph capabilities seem really interesting, so this challenge is going to be a good case study on how to integrate with 3rd party solutions, and maybe we will get out of it a new way to visualize O2 generated data

And the problem not limited to popular Frameworks (and custom / legacy versions of it), most enterprise apps (the one with 500k+ lines of code) tend to have their own custom developed frameworks (or APIs).

So in this challenge we are going to go over the process of adding support to a particular framework/API that is currently not supported.

Challenge: Gain visibility into JSF (Java Server Faces) and find vulnerabilities (or prove their non existence) of applications that use it.

The first step is to gain additional understanding of what JSF is and how they work. Here is a number of links to get us started:

• http://java.sun.com/javaee/javaserverfaces
• http://www.owasp.org/index.php/Java_Server_Faces
• http://www.jsftutorials.net
• http://jsfcentral.com
• http://www.roseindia.net/jsf/jsftags.shtml

The next step is to find a couple demo apps that we can use as case studies during this challenge.

There are a couple little details which will make this a hard challenge (but hey, that's what makes it interresting):

• This is a C++ app: O2 so far has been mainly designed for .NET and Java
• The scanning environment (as described by the authors) is Scientific Linux SL release 4.7 (Beryllium): O2 currently is designed to run on Windows (have not tried it using Mono)
• Some of the issues are design issues: this means that we will have to be creative on the creation of rules/scripts required to find them (nothing I have not done before :)  )
• We don't have (yet) the source code that was used to create the published results: hopefully this will be sorted in the next couple days