JAWR is an open source tool written in Java that compresses and organizes an applications JavaScript/CSS source.  I found out about JAWR through the DWR mailing list.  It took me awhile to check it out, but I finally got around to it.  I have been working on a DWR application with an ExtJS front-end and I thought this would be a perfect place to try JAWR. 

First Impressions:

Setting up JAWR is simple!  The project is well documented and by following the quick start I was able to get up and running in no time.  JAWR does a lot more than JavaScript/CSS compression — here are some of the features:

• Allows you to componentize and organize your JavaScript sources.  Not only does this improve your code it also makes maintenance a lot easier.
• Debug mode allows you to debug your JS source with the modification of one property – Great for development.
• DWR 3.x plugin that compresses interface files generated by DWR as well as static DWR scripts.
• Gzips the response.

JAWR does a lot more.  All developers working on Java web apps should check it out — sooner rather than later!

In my first Ratproxy post I provided instructions on building Ratproxy in a Windows/Cygwin environment.  In this post I will discuss running and using Ratproxy in a Windows/Cygwin environment. 

Run the Ratproxy executable (ratproxy.exe):

1. Open a windows command prompt in the directory where ratproxy.exe lives.
2. Enter: ratproxy.exe -v C:\cygwin -w ratproxy.log -p 8282 -d yourdomain.com -lfscm.  The -p parameter specifies the port that Ratproxy will use  (by default Ratproxy will use 8080) and the -d specifies the domain we will be testing (obviously enter your own domain here).  The rest of the parameters are straightforward and can be reviewed in the official documentation. 

Configure your browser to use Ratproxy:

Now that Ratproxy is running you need to configure your browser to use the proxy.

Internet Explorer 7

1. Tools > Internet Options
2. Connections  > LAN Settings
3. Select ‘Use a proxy server for your LAN’
4. Address: The location where Ratproxy is running (localhost or 127.0.0.1 should work).
5. Port: The port you chose to bind Ratproxy to (in this example 8282). 
6. Now close and open a fresh browser window. 

Firefox 3.0

1. Tools > Options
2. Network > Settings
3. Select ‘Manual proxy configuration’
4. HTTP Proxy: The location where Ratproxy is running (localhost or 127.0.0.1 should work).
5. Port: The port you chose to bind Ratproxy to (in this example 8282). 
6. Now close and open a fresh browser window. 

If you don’t have this configured correctly or if Ratproxy is not running your browser will display an error indicating that the proxy server refused connection.

Do Stuff – and let Ratproxy do the hard work!:

That’s it.  Now all you need to do is step through your website highlighting the main errors that you think may be vulnerable.  Ratproxy will be tracking your session behind the scenes. 

Generate a formatted HTML report of Ratproxy findings:

1. Open the Cygwin bash shell.
2. cd to the ratproxy directory
3. Enter: sh ratproxy-report.sh ratproxy.log > report.html

Ratproxy will generate a nicely formatted HTML report.  That is all for this post, I hope it was helpful.

Recently, I have been studying web application security and some of my research led me to Ratproxy.  Ratproxy is a web application security audit tool recently released by Google.  In this post I will show you how to install Ratproxy in a Windows environment.

What you will need:

1. In order to run ratproxy in a windows environment you will need Cygwin (http://www.cygwin.com/).
2. The current Ratproxy release — http://code.google.com/p/ratproxy/.

Installing Cygwin:

From the Cygwin home page (http://www.cygwin.com/).:

1. Select the “Install or update now!” link to download the Cygwin setup.
2. When the download is complete run setup.exe.
3. Select “Install from Internet” > Next.
4. The next few screens are self explanatory.  You will choose your installation directory (the default is fine) and a few other options (all of the default options should be fine).
5. After you choose a mirror the download will begin.  After the download is complete you will be presented with a screen prompting you to select the packages you would like to install.  VERY IMPORTANT- There are a few utilities required to build Ratproxy that are not installed by default by the Cygwin installer.
   1. make - Located in ‘Devel’.
   2. gcc-core – Also located in ‘Devel’.
   3. openssl-devel - Also located in ‘Devel’.
   4. openssl (The OpenSSL runtime environment) – Located in ‘Libs’ or ‘Net’.

The preceding four packages must be installed or you will not be able to build or run Ratproxy.  Make sure they are not being skipped (there should be an X in the box next to each item).

Building Ratproxy:

Once Cygwin is installed with all of the required packages you are ready to build Ratproxy.

1. Unzip Ratproxy into your Cygwin directory (c:\cygwin).
2. Modify the make file packaged with Ratproxy – The Ratproxy Makefile contains a flag that is not compatible with the compiler installed with Cygwin.  This can be fixed by making a small modifcation to Makefile.
   1. Open Makefile (located at the root of your Ratproxy install).
   2. Look for this line — CFLAGS  = -Wall -O3 -Wno-pointer-sign -D_GNU_SOURCE
   3. Remove -Wno-pointer-sign

The affected portions of the Makefile should now look like this:

PROGNAME = ratproxy
CFLAGS	 = -Wall -O3 -D_GNU_SOURCE
LDFLAGS  = -lcrypto -lssl

3. Flare-dist – Now you need to download the Flare action script decompiler for Windows. From the Ratproxy root open the flare-dist directory. Directions for downloading the Flare action script decompiler are in the README file. Download the distribution at http://www.nowrap.de/download/flare06doswin.zip. Then unzip the file into Ratproxy/flare-dist. You should now have a file called flare.exe (remove the file that was distributed with Ratproxy — flare with no extension).
4. Make Ratproxy – Now we are ready to make Ratproxy.
   1. Open your Cygwin bash shell (by selecting your Cygwin shortcut or by running Cygwin.bat).
   2. Navigate into the Ratproxy directory – At the command prompt enter ‘cd /ratproxy’ (remember we saved Ratproxy at our Cygwin root).
   3. Run make – At the command prompt enter ‘make’

The ‘make’ command should run and complete successfully. You will be left with a compiled ratproxy.exe in your Ratproxy directory. Important: In order to run Ratproxy you will need to make sure the Cygwin/bin directory is in your Windows path (else the exe will blow up when you run it).

To add the Cygwin libraries to your Windows path (in Vista).

1. Right-click the ‘My Computer Icon’ and select ‘Properties’.
2. Select ‘Advanced system settings’ and then select the ‘Environmental Variables’ button.
3. Find the ‘Path’ variable under ’System variables’ and select the ‘Edit’ button.
4. Append ;C:\Cygwin\bin to the ’Variable value’.

You can now use that executable to run Ratproxy according to the documentation on the Ratproxy site.  That is all for this post in part two I discuss running Ratproxy.

DWR and Spring is a great combination. The Spring integration in DWR can support many configurations but many times this can lead to confusion. The goal of this article is to provide developers with a working skeleton for several common environments (using Spring MVC, not using Spring MVC, using the DWR Namespace, etc.).

References

Before we get started you may want to take a quick look at the official DWR documentation.

The DWR Namespace Handler:

Spring 2.x introduced an “XML Namespace Handlers” feature. DWR 2.x allows you to leverage this feature through a custom namespace — eliminating the need for the DWR configuration file (dwr.xml). If you are using DWR > 2.0.x and Spring > 2.x this is the recommended approach if you want seamless integration (almost) between DWR and Spring.

There are a myriad of configurations to consider.  I have included what I feel or the more popular choices.  Please select a link for a detailed description of each configuration and to download a fully functioning basic example:

1. I am using DWR 3.x, and Spring 3.x …
2. I am using DWR 3.x and Spring 3.x and I would like to use Annotations without Spring MVC.
3. I am using DWR 3.x and Spring 3.x and I would like to use Annotations with Spring MVC.
4. I am using DWR 2.0.x, Spring 2.x, and Spring MVC
5. I am using DWR 2.0.x, Spring 2.x, but I am not using Spring MVC

dwr.xml:

If you are using an older version (pre 2.x) of DWR or Spring, DWR still provides integration with Spring through the Spring Creator. This configuration requires a dwr.xml configuration.  Information on this set-up is covered in the DWR manual.

If you are using DWR 2.0.x, Spring 2.x dwr.xml is not required. You can use the new DWR namespace feature in your Spring xml even if you are not using Spring MVC.

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

Step 1: Web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> 

   <listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>

   <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
       classpath:dwrSampleApp2.xml
     </param-value>
   </context-param>

   <servlet>
     <servlet-name>dwr</servlet-name>
     <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
     <init-param>
       <param-name>debug</param-name>
       <param-value>true</param-value>
     </init-param>
   </servlet>

   <servlet-mapping>
     <servlet-name>dwr</servlet-name>
     <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping> 

</web-app>

Since we are not using Spring MVC there are two things that we need to take care of in the web.xml:

1. We need a way for our application to find and load our Spring configuration. There is more than one way to do this but I recommend using a Spring ContextLoadListener.
2. The DwrSpringServlet needs to be specified and all DWR requests need to be mapped to it.

Step 2: Spring xml/Application Context (for this example, dwrSampleApp2.xml)

1. Add the DWR namespace declarations to dwrSampleApp2.xml:

   <beans
     xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
     xsi:schemaLocation="http://www.springframework.org/schema/beans
   
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   
   http://www.directwebremoting.org/schema/spring-dwr
   
       http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd">
   

2. Configure DWR with the configuration tag.

   For this example we are returning an Address POJO from our DWR service. We need to tell DWR to convert the Address POJO with DWR’s “bean” converter. The configuration tag’s children elements mimic the behavior of dwr.xml elements. If you are familiar with the options available in dwr.xml — setting up this tag should be second nature.

   Add the dwr:configuration tag to dwrSampleApp2.xml:

     <dwr:configuration>
       <dwr:convert type="bean" class="org.uk.ltd.dwr.dev.model.Address" />
     </dwr:configuration>
   

3. Expose your Beans to DWR with the remote tag.

   Add the following bean to dwrSampleApp2.xml:

     <bean id="dwrService" class="org.uk.ltd.dwr.dev.service.DWRService">
       <dwr:remote javascript="dwrService">
         <dwr:include method="getAddress" />
       </dwr:remote>
     </bean>
     
   

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

If you are using DWR 2.0.x, Spring 2.x, with Spring MVC, dwr.xml is not required. You can use the new DWR namespace feature in your Spring xml.

This page assumes you know how to use Spring MVC, you have a Spring Dispatcher Servlet mapped (dwrSampleApp), and you are ready to integrate Spring with DWR. I strongly encourage you to have a working configuration before attempting to integrate DWR.

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

Step 1: Web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
  <servlet>
    <servlet-name>dwrSampleApp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value> classpath:dwrSampleApp.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>dwrSampleApp</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwrSampleApp</servlet-name>
    <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping>
</web-app> 

We have added two mappings to the Dispatcher Servlet (*.html and /dwr/*). The problem with the “*.html” mapping alone is that it will not handle all of the DWR requests (described in the next section ‘Spring Application Context’). So, depending on how you have your mappings configured the /dwr/* mapping will or will not be necessary. The key thing to remember is that DWR requests need to be mapped to the configured DispatcherServlet.

Step 2: Spring xml/Application Context (for this example, dwrSampleApp.xml)

1. Add the DWR namespace declarations to dwrSampleApp.xml:

   <beans
     xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
     xsi:schemaLocation="http://www.springframework.org/schema/beans
   
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   
   http://www.directwebremoting.org/schema/spring-dwr
   
       http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd">

2. Create a DWR Controller and a way for Spring (SimpleUrlHandlerMapping) to map DWR requests to this controller. The DWR Controller needs to handle the following requests:
   • /dwr/engine.js
   • /dwr/util.js
   • /dwr/interface/**
   • /dwr/call/**

   Add the DWR Controller to dwrSampleApp.xml:

    <dwr:controller id="dwrController" debug="true" />  

3. Create the mapping from DWR requests to the DWR controller. There are several ways to create this mapping but I feel the following is the easiest to comprehend and the least verbose option:

   Add the SimpleUrlHandlerMapping to dwrSampleApp.xml:

   <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
     <property value="true" name="alwaysUseFullPath"></property>
     <property name="mappings">
       <props>
         <prop key="/dwr/**/*">dwrController</prop>
       </props>
    </property>
   </bean>

   Please note the use of the alwaysUseFullPath property. If this is not set to true (by default it is false) we will have to map all of the required DWR requests:

   <prop key="/interface/**">dwrController</prop>

   etc., etc.

   Why? Because we have mapped /dwr/* to the DispatcherServlet in web.xml, what gets passed into the SimpleUrlHandlerMapping is everything after the /dwr/ (We are not matching on the entire path, because alwaysUseFullPath is false by default). I think not understanding how the SimpleUrlHandlerMapping works is one of the most common problems with this configuration. This has nothing to do with DWR directly, but the DWR mailing list pays the price!

   Another important note about Handler Mappings:

   It is important to note that the creation of the SimpleUrlHandlerMapping may cause your existing mappings to fail if you have not explicitly created a Handler Mapping in your Spring configuration.  By default Spring creates a BeanNameUrlHandlerMapping if you have not explicitly created a Handler Mapping.  So when the SimpleUrlHandlerMapping is created for DWR, Spring will no longer create the default BeanNameUrlHandlerMapping and existing mappings will not work.  Spring allows you to have multiple Handler Mappings, so to fix this you need to create a BeanNameUrlHandlerMapping explicitly in your spring.xml (in addition to the SimpleUrlHandlerMapping).  See the Spring documentation section 13.4.1 for more information.

4. Configure DWR with the configuration tag.

   For this example we are returning an Address POJO from our DWR service. We need to tell DWR to convert the Address POJO with DWR’s “bean” converter. The configuration tag’s children elements mimic the behavior of dwr.xml elements. If you are familiar with the options available in dwr.xml — setting up this tag should be second nature.

   Add the dwr:configuration tag to dwrSampleApp.xml:

   <dwr:configuration>
     <dwr:convert class="org.uk.ltd.dwr.dev.model.Address" type="bean" />
   </dwr:configuration>

5. Expose your Beans to DWR with the remote tag.

   Add the following bean to dwrSampleApp.xml:

   <bean class="org.uk.ltd.dwr.dev.service.DWRService" id="dwrService">
     <dwr:remote javascript="dwrService">
       <dwr:include method="getAddress"/>
     </dwr:remote>
   </bean> 

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

Have you ever worked on a web application that just didn’t work in Firefox? Many companies still use IE exclusively internally and any web application they develop will never be tested on another browser. This makes debugging client side script very challenging (unless you enjoy the pain of dealing with the Microsoft Script Debugger). Personally, I don’t enjoy the dreaded “Object Error” that seems to be just about the only error IE is capable of displaying. Enter FireBug Lite: A FireBug version that works in IE. Sure, it is a bit more work (to use it you have to include a JavaScript file) but it is way better than anything Microsoft currently has. Check it out: http://www.getfirebug.com/lite.html.

If you develop applications for the web understanding the latest security exploits is crucial to securing your site.  WebGoat by the Open Web Application Security Project is a great tool to test your knowledge.  WebGoat is a J2ee application designed to deploy to Tomcat.  The application contains numerous security holes and lessons dedicated to showing users (hands on) how to exploit them.  I highly recommend WebGoat and enjoyed going through the lessons.  You will need WebScarab for the advanced lessons.