Web Vulnerabilities: Part 4— Java
Web Enthusiasts and Developers welcome to the fourth and final part of our blog series on Web Vulnerabilities and how to secure them, and this time we will be looking into one of the most used and famous languages, which is used for client-server web applications with a reported 9 million developers! Let’s get started with Java!
Introduction:
Java is a programming language and computing platform first released by Sun Microsystems in 1995. There are lots of applications and websites that will not work unless you have Java installed, and more are created every day. Java is fast, secure, reliable, and has strong support for web development.
A Java web application is a collection of dynamic resources (such as Servlets, Java Server Pages, Java classes, and jars) and static resources (HTML pages and pictures).
1. Denial of Services (ReadLine)
The readLine() method of BufferedReader class in java can be used to read data from a socket or file; however the readLine() method reads data until it encounters a new line or carriage return character or EOF in the data, but if none of these are found then, readLine() will continue reading data indefinitely.
If an attacker has any control over the source being read, the attacker can inject data that does not have these characters and cause a denial of service on the system. Even if the number of lines to be read is limited, an attacker can supply a large file with no newline characters and cause an OutOfMemoryError exception.
OWASP’s Enterprise Security API provides a safer alternative to readLine() called SafeReadLine(). This method reads from an input stream until the end-of-line or the maximum number of characters is reached, effectively mitigating this risk.
Another solution is to override both the BufferedReader and the readLine() method and implement a limit for the maximum number of characters that can be read. In the absence of a more secure method, avoid taking input from the client whenever possible and ensure data being read is trusted.
2. SQL Injections
SQL injections are caused by unchecked user inputs being passed to a back-end database for execution. The attacker may embed SQL commands into the data he sends to the web application, leading to unintended actions being performed on the back-end database. When exploited, a SQL injection may cause unauthorized access to sensitive data, updates or deletions from the database, and even shell command execution.
This code snippet obtains a user name by invoking request.getParameter(“name”) and uses it to construct a query to be passed to a database for execution(con.execute(query)). This seemingly innocent piece of code may allow an attacker to gain access to unauthorized information. If an attacker has full control of a string userName obtained from an HTTP request, he can for example set it to ’OR 1=1;−−. Two dashes are used to indicate comments in the Oracle dialect of SQL, so the WHERE clause of the query effectively becomes the tautology name=’’OR 1=1". This allows the attacker to circumvent the name check and get access to all user records in the database.
Many SQL injections can be avoided relatively easily with the use of better APIs.
J2EE provides the Prepared Statement class, that allows specifying a SQL statement template with?’s indicating statement parameters. Prepared SQL statements are precompiled, and expanded parameters never become part of executable SQL. However, not using or improperly using prepared statements still leave plenty of room for errors.
3. Cross Site Scripting (XSS) Attacks
XSS Attacks have been with us in every part of this blog series, including this fourth part. In these, an attacker injects a malicious script which can lead to account hijacking, exposure of sensitive data, installation of malicious software, and more.
Luckily, OWASP has a free and very easy to use HTML sanitizer, licensed under the Apache 2 License, which has been created especially to protect against XSS Attacks in Java. It contains different methods for dealing with different types of XSS vulnerabilities. Get started by importing it in your java file, using “import org.owasp.html.HtmlPolicyBuilder;” From here, using the sanitizers class, you can clean the incoming input easily:
For example, using “public static final PolicyFactory IMAGES” allows only <img> elements from HTTP, HTTPS, and relative sources.
One other technique used to prevent XSS Attacks is called Contextual Output Encoding. There exists a package called the OWASP Java encoder library, which is intended for quick contextual encoding. It is important to remember that you should use this library with the HTML sanitizer stated above to increase your chances of better security. Together with the above two libraries, you can make your application more secure against XSS Attacks.
Conclusion
We have looked at the most common web vulnerabilities a java web developer can face. Keep in mind these few principles:
- Never trust the user input, always sanitize the input before performing any actions.
- Test your application under heavy load and make sure you don’t provide any scope for unnecessary inputs or requests to be taken from the user.
- Never present any information other than the necessary because all the attacker needs is a small piece of information to exploit the application.
- Use the packages provided by OWASP for easy protection against XSS Attacks.
And with that, we conclude our journey on web vulnerabilities. Starting with Node.js, then Django, PHP, and eventually Java, we have explored various threats and ways to secure them. Cyber security is an ocean and hopefully, this series has given you an insight into the world of securing Web Frameworks. We hope you have enjoyed reading this blog series and gained a valuable perspective on web vulnerabilities. Do check out the previous parts of the series if you haven’t already!
“It takes 20 years to build a reputation, and a few minutes of cyber-incident to ruin it” — Stephane Nappo
