captain holly java blog

Evaluating WebScarab

Posted in security, spring, Uncategorized by mcgyver5 on July 29, 2009

I was asked to do a security assessment on a co-worker’s Cold Fusion application. It is protected on every page by a NOT findnocase(cgi.http_host,cgi.http_referer) check to ensure the request came from the same domain. This is a good way to prevent forced browsing and most url injection attacks because if you mess with the URL, this tag knows it and stops all the shenanigans.
This is where a proxy comes in. I’ve worked a bunch with Paros and some with Burp, but my employer does not allow me to download these without some extra paperwork. Webscarab, for some reason, is allowed. Webscarab is written entirely in Java, has a zippy UI and has widening adoption.

Webscarab allowed me to do forced browsing on the application and learn that the application relied solely on that domain check to make sure the user was authenticated (That is, they could only get to the site through the login form). Webscarab also allowed me to find many XSS bugs.

Webscarab is infinitely scriptable (with beanshell).

Webscarab has a tool that evaluates session identifiers for their strength. I would guess that most web frameworks these days have very strong session identifiers. In fact, I challenge anyone to find an example of a weak session identifier on any web app that shouldn’t be replaced anyway for one hundred other reasons.

Startup Options
Webscarab starts in Lite mode, which is just the web proxy, by default. To get the full meal, you have to start with java -DWebscarab.lite=false -jar webscarab.jar
Default memory is 64MB and this can get used up quickly. Online examples show webscarab having ~510 MB available. This is achieved by adding -Xms32m -Xmx510m to the java startup args. Just like with some other java desktop apps (Like IntelliJ Idea) you can click on the Green|Yellow|Red bar along the bottom of the window to force garbage collection and free up some memory.

Things That Could Be Improved:

  1. Inconsistency: Some features are available through a right click, some through a double click, some from a menu item and others from buttons or tabs somewhere on the screen. Some fields look editable but aren’t. Some are editable on one click, others on two. Some edit fields select the whole field when clicked, but typing appends to the end of the existing entry.
  2. Other screens have a delete button. Not the Proxy Listener Tab. To delete a listener you must stop it. If I a listener fails to start, it may not be stopped and so cannot be deleted. I have to stop any other service using the same port as my listener, THEN start my listener, and THEN stop my listener to delete it
  3. The interface for getting rid of conversations is difficult to use. Webscarab can fill up pretty fast with banal conversations and the only easy way to get rid of them all is a restart. There is a Tools –> remove conversations menu item, but no regex that I enter seems to get rid of conversations.
  4. There should be some way to construct the proxy filters based on existing requests. By this I mean when a request is trapped that you never want to see again, you can flag it in some way to add it to the ignore list.
  5. Judging from several posts to the mailing list, Webscarab only works with Sun’s brand of java.

To address user experience as well as other issues, Webscarab is undergoing a total rewrite. This is currently known as Webscarab NG. They will be using the Spring Rich Client Platform. The new product also has database integration. This is a work in progress and needs lots of testing. So, if you are looking for an open source project to help, this would be an excellent choice. According to the email list, the Webscarab NG project leader has been directing his work at the OWASP Proxy lately. Even though Webscarab NG is in development, development also continues on the current Webscarab.


TCJUG = Spring 3.0

Posted in spring, tcjug by mcgyver5 on May 19, 2009

I went to the May Java Users Group lecture last week.  I came away with the feeling that the Spring Framework was about the coolest thing in the world.  The presentation, however, was mostly about Spring 2.5, with a few new Spring 3.0 things.

The highly anticipated 3.0 feature is the REST support in Spring.  While browsers only implement GET and POST, the new REST wiring in Spring allows you to do such things as tell a form to submit using the idempotent PUT method.  It also allows you to vary your request mapping based on the HTTP method.  For example, every web developer in history has built a form that must both be filled with default data (i.e.  a GET request) and submitted (i.e. a POST request).  The flow ends up at the same URL, but now you can branch behavior (either update the database or select from the database) based on the HTTP method used to reach the form page.

The powerful annotations of 2.5 are enhanced in 3.0, allowing less reliance on XML. The wiring is now defined in the classes themselves. This has the disadvantage of requiring a compile when you change the code, whereas XML did not, but it has the advantage of reducing the number of places you need to change things. It also, as the creator of Spring pointed out in a podcast[1], changes your definition from where and when to just when because the where is implicitly defined by where in the source code you place your annotation.

@requestParam in method signature eliminates the need to pull values out of Request Object.

  • Previously you may have done:   method(HttpServletRequest request, HttpServletResponse response){ String theName= request.getParameter(“theName”);
  • Now, you can do:  method(@RequestParam(“theName”) String theName);

paths for request mapping can have wildcard/variables as in artist/{artistId}/album/{albumId}/

Binding complex types to a form. Instead of just text in a form field, you can inform a simple html text element that it is, in fact, a horse, or a currency or a date, or even part of a larger object like a book order.

flexible method signatures. This is a 2.5 feature. For example, older versions required a return type, here you can go ahead and return void instead of null if your method does not need to return anything.

ETag caching.  An Etag is a header in the response object.  It looks like this:

ETag: 333565bb8c284d8afad71192f209435d

That long string represents a message digest of the content, generated by the server, and serving as a unique identifier. When the browser requests the page again, it sends along this long string and if it matches what the server has stored, the server returns a 304 message, “the resource has not changed”.  This article shows how an implementation might be hand-coded in Spring. 3.0M1 has a filter built in called ShallowEtagHeaderFilter that does what the article suggests.  By shallow they mean, “the generated jsp is the same and even though we worked to generate it, we won’t bother sending it over the wire”.  By deep, they mean that somehow, the underlying data structure can be checked for changes, and the jsp won’t even be generated.  A deep Etag filter is in the “maybe” stage.

Paths in Spring MVC can be altered to, for example, put .json at the end to return json output.

Right now, to validate a form, spring users generally pass the request through a class that implements Validator, which is fine, but once you are high on annotations, you will want to use annotations for validation as well.  This is not yet implemented in Spring 3.0 but it will soon follow <a href=”″>JSR 303 Bean Validation</a> recommendations.

See also:

  1. Java Posse podcast interview with Spring founder Rod Johnson covers some of the same things.
  2. Google Guice and SpringSource have partnered to standardize on annotations
  3. summary of spring 2.5 features.