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

 

 

Jsp buffer and autoFlush - Refresh

 

<%@ page buffer=sizekb %>

Gives the size of the page buffer in kb or none for no buffer. Default 8kb. If buffer is none, all output is immediately flushed.

JSP 1.0 gives page writers flexibility by buffering its output before sending the response to HTTP. The buffering allows error recovery and forwarding, even after generating some content. Once the buffer has filled, it will be flushed. So applications must still detect their errors early.

The following example generates an XML section (for variety). If the form's query is missing the 'name' parameter, it will redirect the results.

<?xml version='1.0'?>           <form>           <%           if (request.form["name"] == null)           pageContext.forward("redo-form.jsp");             for (var name in request.form) {           out.print("<" + name + ">");           out.print(request.form[name]);           out.println("</" + name + ">");           }           %>           </form>

<%@ page autoFlush="true" %>

Tells JSP to flush the page buffer when it fills. Default is true.

If autoFlush is false, the JSP engine will throw an exception if the buffer overflows.

 

Jsp and Html Comments

JSP and HTML Comments

In a jsp we should always try to use jsp- style comments unless you want the comments to appear in the HTML. Jsp comments are converted by the jsp engine into java comments in the source code of the servlet that implements the Jsp page. The jsp comment don't appear in the output produced by the jsp page when it runs. Jsp comments do not increase the size of the file,  jsp page are useful to increase the readability of the jsp page.

In Jsp two types of comments are allowed in the Jsp page:

1) Hidden comment: This comment will not appear in the output.

<%-- Hidden comment --%>

2) Output comment: This type of comment will appear in the output.

<!-- Output comment>

 

 

JSP - Not to Cache Jsp page in browser

 

JSP – Not to Cache Jsp page

 

<%

response.setHeader("Pragma","No-cache");

response.setHeader("Cache-Control","no-cache");

response.setHeader("Cache-Control","no-store" );

 

%>

 

Oracle DEFINE Command

Using the DEFINE Command with& Substitution Variable

 

Syntax:

 

 

 

Step 1:

 

Create the substitution variable using the DEFINE

command.

 

DEFINE employee_num = 200

 

 

Step 2:

Use a variable prefixed with an ampersand (&) to substitute the value in the SQL statement.

SELECT employee_id, last_name, salary, department_id

FROM employees

WHERE employee_id = &employee_num ;

 

Oracle Constraints.(you might be knowing...just for refresh)

Oracle Constraints…

 

 

We can add, drop, enable and disable constraints in the Oracle…

 

 

Syntax for adding a constraint..

 

ALTER TABLE table

ADD [CONSTRAINT constraint] type (column);

 

 

e.g.

 

ALTER TABLE EMPLOYEE

ADD CONSTRAINT emp_manager_fk

FOREIGN KEY(manager_id) REFERENCES employee(employee_id)

 

 

 

Syntax for dropping a constraint…

 

 

ALTER TABLE EMPLOYEE

DROP CONSTRAINT emp_manager_fk

 

 

 

 

Syntax for enabling and disabling a constraint…

 

ALTER TABLE EMPLOYEE

DISABLE CONSTRAINT emp_manager_fk

 

ALTER TABLE EMPLOYEE

ENABLE  CONSTRAINT emp_manager_fk

 

 

 

 

Call stored procedures with IN, OUT, and IN/OUT parameters.

his example demonstrates how to call stored procedures with IN, OUT, and IN/OUT parameters.

    CallableStatement cs;

    try {

      // Call a procedure with no parameters

        cs = connection.prepareCall("{call myproc}");

        cs.execute();

     // Call a procedure with one IN parameter

        cs = connection.prepareCall("{call myprocin(?)}");

        // Set the value for the IN parameter

        cs.setString(1, "a string");

        // Execute the stored procedure

        cs.execute();

     // Call a procedure with one OUT parameter

        cs = connection.prepareCall("{call myprocout(?)}");

        // Register the type of the OUT parameter

        cs.registerOutParameter(1, Types.VARCHAR);

        // Execute the stored procedure and retrieve the OUT value

        cs.execute();

        String outParam = cs.getString(1);     // OUT parameter

    // Call a procedure with one IN/OUT parameter

        cs = connection.prepareCall("{call myprocinout(?)}");

        // Register the type of the IN/OUT parameter

        cs.registerOutParameter(1, Types.VARCHAR);

        // Set the value for the IN/OUT parameter

        cs.setString(1, "a string");

        // Execute the stored procedure and retrieve the IN/OUT value

        cs.execute();

        outParam = cs.getString(1);            // OUT parameter

    } catch (SQLException e) {

    }