Java security in web application, typical attacks

 

This article gives an overview about different attack mechanisms against Java web applications and J2EE applications. It introduces available security concepts in Java like JAAS and Sandbox security. Furthermore, security related design patterns are explained

 

Remove Comments

Delete comments in deployed documents. An intruder could use this information to attack your side. You should not use any HTML comments in your JSP.

  <!--  HTML comment: looks up user data in table tuser -->

Even if you use a comment like the following in your JSP, there can be a situation, in which the JSP is not rendered and the comment is visible to a intruder (-> directory browsing).

  <% /* JSP comment: looks up user data in table user */ %>

Directory Browsing

Directory browsing allows other people to see all your JSP files without being rendered. They could retrieve valuable information about your application from these files. You have multiple options to protect your JSP files:

·         Deactive directory browsing on server and application level.

·         Protect the JSP directories with JAAS.

·         Change the default servlet coming with Tomcat. This servlet does provide the browsing feature.

Multiple Level of Security

Features like Directory Browsing, Session Time Out can be configured on server level and application level in the web.xml. You should have tight server level settings so that a incautious developer have a secure application by default.

Typical problems of web applications

·         Self made Session id

·         Incomplete validation of user input

·         Server configuration

Do not reinvent the Session handling. The session provided by nowadays application server should be secure. There might have been problems for some application servers in the early days but this is a long time ago.

Imagine you would use a timestamp as session. An intruder could easily take over an existing session by trying out current timestamps.

Normally a Tomcat session looks like

http://localhost/MyApplication/listUser.do;jsessionid=2CFB532547A143436A46727B3B4C7C0A

If you use a timestamp as session id you will have something like:

http://localhost/MyApplication/listUser.do;mySessionId=2006-05-25-19:31:050

Even if your session id is more complicated than a timestamp, you should keep in mind that an attacker could create a list of sessions in search for a pattern in your session id.

SQL Injection in Java Web applications

Imagine a login form in a web application where the user inputs a user name and a password.

Your application issues a SQL statement:

select username from user where username= 'Peter' and password = 'secret'

If the user inputs for password something like

secret' or '1'='1

Your query will be something like

select username from user where username= 'Peter' and password = 'secret' or '1'='1'

The same kind of injection can happen with any kind of search form. If a intruder wants to reduce your product prices he could input the following in your search form.

Blablub';update product set price = 1 where product_id=55 and '1'='1

Your search query will be something like

select from product where name = 'Blablub';update product set price = 1 where product_id=55 and '1'='1'

These kind of attacks are typical for applications using JDBC directly. A good protection is to use prepared statements or Object Relational Mapping solutions like Hibernate, EJB or JDO.

Java Script attacks

Cross side scripting

When a intruder can take over your session he is working with your account. Imagine somebody takes over your session in a Internet Shop and orders products. You will get a lot of problems.

An intruder could post links into a forum to a internet shop having very low prices. Once you click on this link the website is loaded into a frame. Outside the frame there is a Java script application sending input of your frame or your session to another website. Once the intruder has access to your session we will hold your session open to misuse it later or when you are not available.

This is not a problem specific to Java applications but to web applications in general.

You could enforce that your application is not running inside another frame, to solve this security problem.

Another approach to have a improved security is to enforce a maximum session life time. If your users can accept that their session is not living longer than two hours, you could invalidate all older sessions periodically. This makes it impossible for intruders to keep sessions alive for a longer time.

Attacking forms

If you validate forms using JavaScript or you keep information in your form with hidden fields you can be attacked easily. Let us assume that we have a multi page form and you save the customer level in a hidden field. Dependent on the customer level a customer gets a special discount.

Using a web proxy like Scarab you can easily rewrite hidden fields and get a special discount for your order.

Security Design Pattern

Secure Transport Object (STO)

In distributed environments you have to transport serialized objects from one application server to another. The transport item could be a message, a serialized object of a Remote EJB or any other kind of data on a enterprise service bus.

The connection between your application server could be insecure or your transport item could have to pass multiple intermediates.

In this situation the pattern Secure Transport Object is a good choice to protect your data. It is a Data Transfer Object (DTO) which is protected by encryption. The sender encrypts the data using a password or a public key. The STO passes any number of intermediates and reaches the target which decrypts the STO using the same password or a private key.

You could implement a more fine grained approach as well, allowing that only some attributes of an object are protected.

Intercepting Validator Pattern

In order to validate all input in a proper manner and to protect your application against JavaScript or SQL injection you can use the Intercepting Validation Pattern. Instead of validating input decentralized in your application you have a central mechanism to validate the user input.

Secure Based Action

This pattern defines a single point of entry for your application and enforces security restriction. For example, you could implement a Filter Servlet validating that you are allowed to call the specified method. In a Struts application you could overwrite the default controller and add the validation of security constraints