Some hints to avoid security holes on web applications

 

Security is an important issue in web projects . This article shows you different kinds of attacks that can affect to the web projects build in j2ee.

Comments

You may enter comments on your jsp or HTML files while you are coding as shown below, but you should make sure that these comments will not express any vital information about your system . An intruder can view the comments and he may use this information to intrude into the system.

  <!--  HTML comment: any information -->

Even if you we use jsp comments certain servers allow directory listing of files in your system .so jsp files can view with out being rendered and the comment is visible to any intruder .

  <% /* JSP comment: any information */ %>

Directory Browsing

There are servers like tomcat which in default allows the directory browsing , this allows other to see your JSP files without rendered. So an intruder can see the pages like normal jsp files and the information about your application become vulnerable.To prevent these they

  • block directory browsing on server and in application .
  • Protect the files with JAAS

Putting All in the HTML directory

Most of the beginners put all there files to HTML directory of the application but these files can be accessed directly once the user knows the URL of the page. If need to access these pages only through the application resources the we have to kept it out side the HTML directory . This will make directory management easy.

Self made Session id

The session provided by application server are secure. But if the intruder knows the pattern of session ids provided by the servers like for tomcat session will look like follows, http://localhost/MyApplication/listUser.do;jsessionid=2CDDNNNNA46727B3B4C7C0A.An intruder can take over existing session by searching this pattern.

SQL Injection in Java Web applications

Imagine a log in form in your application where the user name and password need to be enter and your application uses following SQL statements to validate the user to allow / denies access

select username from user where username= 'javasql' and password = 'sqlpassword'
If the gives  password as
sqlpassword' or '1'='1

Your query will be executes like

select username from user where username= 'javasql' and password = 'sqlpassword' or '1'='1'

The same kind of injection can be used to update your system values like changing one password as if you are searching an employee with his name as

'some string';update user set password = 1 where name=55 and '1'='1

Your search query will be something like

select from users where name = 'some string';update user set password = 1 where name=55 and '1'='1';

Use of prepared statements will protect from these type of attacks

Java Script attacks

Cross side scripting

The type of attacks normally happened when your application can be run on different frames . When your application can run on different frames intruder can open your application on a particular frame intruder can send the values of your application using JavaScript working out side that frame. Once the intruder got access to your session, the system will hold your session and misuse it when you are not available.

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

Attacking forms

If you are validating forms using Javascript and if it has multiple pages to complete the process , there may be hidden fields to holds the values through the pages . The intruder can easily attack these hidden fields. These “hidden” fields can be seen by performing a ‘view source’ on the web page. Some developers make this mistake by passing application configuration parameters to back end programs using hidden fields.

Special characters

Input containing special characters such as ! , & and NULL could make the web server to execute an OS command or will cause other unexpected behavior. The user inputs must parsed to avoid these kind of attacks.

Caching

Caching pages cause problem . To prevent the caching of request/response on proxy servers/web caches ,we can set following data on the response headers

Header Value
cache-request-directive no-cache
cache-response-directive must-revalidate
expires 0
cache-control no-cache, must-revalidate
pragma no-cache


e.g. aHttpServletResponse.addHeader(“pragma”, “no-cache”);