Debugging running web applications

I've always found it easier to test with code when testing *anything*. So when I see large web applications, my first instinct these days is to build it with code. Recently I was testing a web app that had its own built in web server. Here are the steps I performed to get it up and running.

1. Get a VM and configure the application inside the VM.

2. Identify how the server can be started in debug mode. Usually these servers have startup scripts and shutdown scripts. Look at those. Sometimes you get lucky (like me) and find a debug mode startup script. The debug script will contain a line like this, which adds to your command line arguments while starting the server (some long java command)

-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

3. Verify that port 8787 is actually listening on the server, along with the other normal ports on which your web server runs (say 80,443 for e.g).

4. If you're using Virtual Box, setup port forwarding so that you can reach all the ports on the guest (80, 443, 8787) from the host. Netcat into the guest ports from the host and verify that things work properly.

5. Now download IntelliJ on your host and make sure it launches.

6. Import your project into IntelliJ directly from the svn/cvs/whatever repository using the 'Intellij Idea -> checkout from version control' at the start. You might have to install the svn/cvs/git client on your host as well, if you do not already have it.

7. Now configure a remote debugging configuration in IntelliJ. Here is a great StackOverflow post to help you do this. Give it a name 'remote_debug_project' or whatever you want.

8. Click Run. Debug remote_debug_project. The lower pane should open up and say something like 'Connected to the target VM, address: 'localhost:8787', transport: 'socket'

9. Set a breakpoint in code that you know will definitely be triggered. Maybe choose the 'login page' verify password function.

10. Visit the web page. Login. The breakpoint should get triggered now. Enjoy a more powerful way of testing web apps now.

If your clients give you source code and you can build it, I definitely encourage this way of testing stuff. The time you take to find stuff out with code is way way lower than with black box testing.

Installing Glassfish on Ubuntu 12.04

This is what I needed to do to get the Glassfish application server running on Ubuntu 12.04.

a) Install JRE for Ubuntu 12.04. Download the version applicable for you from the official website.

b) Configure your system to use the JRE you just downloaded. You can do this as follows:

---- First add the version of JRE you downloaded to the list on your system.

sudo update-alternatives --install /usr/bin/java java /bin/java 0

---- Then ensure that all Java programs will use that version.

sudo update-alternatives --config java

c) Install a JAR archiving program. I used Fastjar from the apt repository.


sudo apt-get install fastjar

d) Download the Java EE SDK with Glassfish and JDK from the official website. Make sure you download the version applicable to you.

e) Once the download is complete ensure that the file can be run. If it doesn't have executable permissions, run chmod 755 to make it executable.

f) Run the installer using ./filename and follow the prompts. If you're lucky everything should go well. If you're not it'll hang at the penultimate step, taking forever to create a new domain.

g) The problem apparently is with Glassfish and some funny bug which needs your real hostname to be in the /etc/hosts file. At least that's what fixed it for me. Here is what my /etc/hosts file looks like.

127.0.0.1    javaee    localhost.localdomain    localhost
10.0.2.15    javaee    localhost

Maybe you don't even need the 2nd line. Maybe I'll confirm that some day. Or someone will :)

h) Reboot once (maybe not needed) and run the installer again. All should be good this time round.

i) You can also Cancel the installer if it hangs while creating a domain and create a domain manually using asadmin as follows.
sudo ./asadmin --user admin
asadmin>create-domain
asadmin>start-domain

... and follow the instructions there. Have fun :)

Restrict signed Java applets

There's a ton of information on the Internet on how to sign Java applets and restrict unsigned Java applets as well. Very strangely there is very little information on doing the same for signed applets.

I did manage to find information which eventually helped me out; just that it took an insane amount of searching. Hence this little blog..which just collects all the information I found and puts it in 1 place.

First of all, the reason (as you already most probably know) to restrict signed applets, is that they're all powerful and can perform dangerous file I/O and network operations. So it's a nice thing to be able to restrict them from doing so, if needed. So here are the steps to do so, in a nutshell:

a) Sign your Java applet using keytool and jarsigner. A self signed applet is sufficient for demo purposes. The same logic can be used in case a trusted CA signs the certificate.

b) Once the applet is signed it's usually packaged into a JAR file prior to deploying it.

c) It's then deployed by embedding it into the HTML of a web page.

d) When the user visits the page, there's a pop-up which will now appear, asking the user to grant the applet additional permissions. Note here that if you click Run, the signed applet has complete control and can make numerous file and network I/O calls. If however, you click Cancel, you're not granting it permissions. The applet still runs (contrary to what one might intuitively think) but behaves like an unsigned applet.

e) What we now want to do though, is to limit what the applet can do, when the user clicks Run. For example: If all the user wants to do, is write to /tmp and nothing else, why should it have a million other privileges?

f) There's 2 ways to do it. One is to call every single relevant method in the applet from JavaScript. The second way is to write a policy in java.policy. Without frustrating you further, I'm going to show you, with a little sample code on how to do both.

g) First of all here is the Java code that I used as a POC. It's grabbed and tweaked from some tutorial online and not my own.

import java.applet.*;
import java.awt.*;
import java.io.* ;
import java.util.*;

public class FirstApplet extends Applet{
  public void init() {
    createFile("/abc/testsignapplet.txt");
  }
 
  public void test_HTMLbutton_method_invoke() {
    createFile("/abc/booboo.txt");
  }

  public void test_js_onload() {
    createFile("/abc/doodoo.txt");
  }

  private void createFile(String filename) {
    FileOutputStream out = null;
    try {
      out = new FileOutputStream(filename);
      out.write(("Testing jar signing process...:" + new Date()).getBytes());
    } catch(Exception ex) {
      ex.printStackTrace();
    } finally  {
      try {
        if(out != null) {
          out.close();
        }
      } catch(IOException e) {}
    }
  }
}

h) Here is how you must call the public methods of the applet from either an HTML element or from JavaScript. The line in the last < script > block which embeds the applet is possibly not the best way to do things; it's just there to show you guys how to call a method via HTML and JS, which is the point of the post.

i) Doing so, will cause the applet to still behave as an unsigned applet. If there's any malicious code in any of those functions, it's not going to be able to break out and cause havoc.

j) The other way of limiting the operations an applet can perform is by editing the file called java.policy. On a Ubuntu system, by default this file is inside your home directory. It is named .java.policy.

k) Back the file up and then delete all the lines in that file. Now add these lines to the file. This limits the applet loaded from http://localhost/applets/ from writing to any other directory except /abc.

grant codeBase "http://localhost/applets/*" {
  permission java.io.FilePermission "/abc/*", "write";
};

l) Note that a cool GUI tool called policytool can also be used for this purpose. If you have JRE or/and JDK on your machine, you should have policytool as well. You can add/edit/remove policies using it as well.

m) Test your applet using appletviewer first. It's a tool which you can use to check if your policies are working properly, before deploying the applets everywhere.

appletviewer -J-Djava.security.policy=/home/arvind/.java.policy sample.html

n) If the results are as expected, launch the applet in the browser. All the HTML and JS calls to methods should be blocked :)

----------

p.s - It's a good idea to have the Java Console launched while you're doing this stuff. It throws exceptions that you can then see and modify your approach accordingly. The Java Console can be launched using javaws -viewer and ticking 'Show Console' in the Advanced Tab.

Other Java related settings can be tweaked too in here. A good guide to follow can be found here - http://seanthegeek.github.com/harden-java/