The purpose of this article is to provide assistance in testing thick client applications developed with Java Network Launch Protocol (JNLP) technology. I will delve into the topic in detail, beginning with what is a thick client. Read on for not-to-be-missed testing tips. This article covers the following essentials:
- Settings that need to be configured in Java before launching the application.
- Obtaining the source code using JNLP.
- De-serialization and interception of requests and/or responses.
What is a Thick Client?
A thick client is a client in-client server network or architecture (independent of the server) that provides rich functionality. In these application types, the majority of processing is carried out at the client side and involves only a periodic connection to the server.
A thick client can also be known as a fat, heavy or rich client.
Yahoo Messenger, G-Talk, Microsoft Outlook, online trading portals, amongst others are examples of thick clients.
Main Categories of Thick Clients:
What is JNLP?
The Java Network Launch Protocol (JNLP) is an XML-based technology that enables launching of Java executables hosted on a remote web server. Java Web Start and Java Plug-in software are considered JNLP clients, as they have the capability to launch remotely hosted applets and applications on a client desktop.
How does JNLP work?
Imagine that you could specify the class path resources in your application (e.g. files, JAR files, images, properties etc.), spread across the web and provide URLs, rather than rely on the local file system as normal Java applications do. This feature allows you to deploy the application automatically (such as installing application files and launching them properly) just by declaring where your files are on the web.
Subsequently, imagine adding capabilities, like distinguishing between versions of the same file depending on some local parameter etc. For example, you could say "If the locality is 'Chinese', use the input framework extension and those JAR files there" or "If the client uses 'Windows', launch the installer here before running the application."
This will save a lot of time and effort coding (and such installation problems are very common), and allow developers to have a great number of new unimagined capabilities.
However, there is a subtlety. Who will configure the JVM to launch your application in this way? The answer is: another application, a launcher that will prepare the JVM to correctly execute your program. Bear in mind that JVM needs files to be copied locally on the file system in order to use them.
The JNLP protocol consists of a set of rules that describe how this launching mechanism should be implemented. So, rather than setting the classpath variable, an XML file can be written (or more than one) that carefully describes what the launcher (called the JNLP Client) should do before setting up a JVM instance to run your application. The XML-based file .jnlp performs the following functions:
1. Instructs the Java web start to take over the execution of the application.
2. Loads or downloads each required jar file – depending on whether it is the first time that the JNLP software is executed,
the web server responds with each jar file request (Not Modified vs. other HTTP/1.1 304).
3. Starts the Java VM with the required execution parameters.
4. Starts the Java application with the required parameters and properties.
How do you check the source code for sensitive data?
The .jar files contain the source code of the application. The source code can be inspected to check if any sensitive data is present or re-engineered to create a fake, malicious version of the application. It also is capable of identifying of any client-side application protections, e.g. code obfuscation that has been applied to the application itself. Code obfuscation can be incorporated in an application as an intellectual property rights protection mechanism to prevent the source code from being disclosed.
The easiest way to obtain the .jar files is through a manual download. This can be done by opening the .jnlp file in Notepad to view files that need to be downloaded. These files are under the <resources> module with <jar href=”http://abc.org/def/ghi/jarfilename-1.jar”/>.
You may also use the jnlpdownloader.
Important configurations for the smooth running of JNLP applications
In parallel, events are taking place in the local workstation. These actions can be mapped using the native sun Java plug-in control panel. Before clicking the .jnlp shortcut, the following actions must happen:
2. Find the location of the temporary internet files (Java control panel → general → temporary internet files → settings).
Now you can click the JNLP application link and launch it.
The Java console popping in the background is the first thing that appears. Click on the console and press 5 to trace the application execution which provides a view from the Java VM perspective. You can gather important information from this window, including the location of log files.
The log files are usually located at:
If the application is self-signed, you will see an error when you launch a file, which is the result of Java security settings that restrict you from accessing applications with security flaws.
To overcome this, the security level needs to be reduced to “Low” (Java Control Panel → Security → Low).
Interception and de-serialization of traffic
You may face issues while intercepting the traffic, as JNLP applications tend to be proxy-unaware thick clients. Requests and responses of such a client can be intercepted using Burp Suite’s “Invisible Proxy Mode”.
Here are the steps to do this:
1. Make an entry in your hosts file (this can be found at C:WindowsSystem32driversetc) mapping your destination domain to the loopback (127.0.0.1).
2. Navigate to Burp Suite’s Proxy à
3. Add a Proxy Listener.
- Add the destination’s port as the “Bind to port”.
- Choose “Loopback only” as the “Bind to address”.
- Set “Redirect to host” as the destination IP address.
- Set the destination port number as “Redirect to port”.
- Check “Support Invisible Proxying (enable only if required)”.
More information on Invisible Proxying can be obtained here.
Some Java thick clients serialize the communication between the client and server. Although serialized requests and/or responses can be intercepted using the default’s proxy settings in Burp, very little can be done while the traffic is serialized. As a result, it is necessary to de-serialize the traffic so that we can view/tamper the requests and/or the responses for testing.
To de-serialize the traffic, Burp Suite’s “BurpDSer-ng” plug-in along with the “Xstream” plug-in can be used.
You can download the BurpDSer-ng plug-in from https://github.com/omercnet/BurpJDSer-ng.
The BurpDSer-ng plug-in de-serializes Java objects and encodes them in XML using the xstream library.
Now, create a folder named “libs” in your Burp Suite’s root directory and copy all the downloaded .jar files into it.
Start Burp with the extender via the command:
java -classpath <name_of_your_BurpSuite>.jar;BurpJDSer-ng.jar;xstream-1.4.4.jar;"<Absolute_path_to jars_folder>"/* burp.StartBurp
E.g.: java -classpath burpsuite_free_v1.6.jar;BurpJDSer-ng.jar;xstream-1.4.4.jar;"E:ToolsAppSecBurpSuitelibs"/* burp.StartBurp
The screen below shows the Burp Suite’s Root directory.
Once Burp starts, the extender loads and you will get a new tab every time serialized traffic is intercepted.
I hope this article provides insight into how to navigate the world of testing thick client applications based on JNLP.
Other Useful Tools:
1. You may use Process Monitor to test the application’s interaction with the local file systems and Registry.
2. Java Decompiler (JD-Gui) can be used to decompile the downloaded .jar files.
- Application Security Testing of Thick Client Applications
- Pentesting Java Thick Applications with Burp JDSer
- Tips for Fat Client, Web App, and Mobile Pen Testing Serialized Object Communication Using the Burp Suite
- JNLP Application Security Assessment – Setting the scene
Happy testing to you!
About the author:
Krithika M. M. is an EC-Council Certified Security Analyst (ECSA) and a Certified Ethical Hacker (C|EH). She has extensive experience along with a keen interest in Application Security, Mobile Application Security, Network Penetration Testing, Secure Code Review and Secure Configuration Audit. She is currently a Security Analyst at Paladion Networks.