Security Tips for Struts based web application

Some Tips on Securing web based application (Struts -2, Mysql, Hibernate, JBoss 7.0.2)

1. AUTOComplete OFF

Add autocomplete=’’off” tag in form tag to prevent auto-fill user credentials in the form.

2. Session Time out implementation: Session time

Configure session time in web.xml. It takes time in minutes.

 

3. Brute force attack:

If your application has any login/password screen then there is a possibility for brute force attack if you have not implemented captcha or blocking of user after some unsuccessful login attempts. There could be many solution to solve that issue:

a. Introduced captcha in login/password screen

b. After two-three unsuccessful attempt, ask user to fill up a captcha screen.

c. Block the user after certain unsuccessful attempt and unblock him through administrative user or automatically after certain period of time.

Point to remember before implementing any of the above solution:

Solution (a) will be easy to implement but it will be inconvenient to user if application is regularly used by him/her and application is only for some restricted user set for example for an Organization.

Solution (b) would be a good fit, mainly popular site like gmail, yahoomail etc. use it but then one has to make sure that user should not be allowed to attempt again by changing the session either by opening application in new tab of browser or opening in different browser.

Solution (c) is more apt if application is quite sensitive and we really do not want user to try more then specified number of time. Again solution should take care of new sessions and different browsers.

We have implemented a database based solution where we kept failure information of a user in database and updated it based on successful login or reset it after certain period.

4. Insecure Direct Object References:

The functionalities/pages which need to be accessed through application flow are directly accessible by providing their URI in the address bar i.e. directly going to a particular page through change in its object id from URL. It is observed for most of the functions, the attackers can manipulate these references to access unauthorized data without any access control check or other protection. The Forward & Back button can also be used to access the function directly bypassing the application flow.

Include below code in .jsp page to disable back button.

 

Include this code in .java file to disable back button in default interceptor.

5. Absolute path disclosure/Path traversal is possible:

Application displays the absolute path for all the function/objects which may be misused for getting the access of even those functions which needs to be protected by application flow & access to be allowed only to authenticated & authorized users which are supposed to use these. The attacker can manipulate the parameter to access the pages directly.

There could be two solutions for it:

1. Masked actual URL with some fixed URL (I have seen this in many site but could not implement it.)
2. Implement role based access control on particular page access. In case of struts one can extract the role from session which can be populated at the time of login. In default interceptor check user’s role and corresponding allowed action. If called action is not allowed then throw user on login screen.

 

6. Failure to Restrict URL Access:

No check is implemented in the application to restrict the access of protected links as web application is not checking the URL access rights before rendering protected links and buttons. As observed the lower level user e.g. tester not having the access link to functions related to admin as add, modify or delete the user/role etc. can directly access & use these functionality through supplying the URL address of these pages in the address bar without any authorization check.

This point would be solved if one implements solution 2 of point 5.

7. Application Error message/ Exception handling:

Application is unable to handle the exceptions/ Runtime error as it displays the error message showing the details of platform info & database structure which may be misused by the attackers. Application error messages reveal the server details.

Different webserver handle this differently. In JBOSS we have handled it through web.xml of application. We have put checks for 500,404 and thrown a error page.

8. Cross-Site Request Forgery:

The same request was sent twice in different sessions and the same response was received. This shows that none of the parameters are dynamic (session identifiers are sent only in cookies) and therefore that the application is vulnerable to this issue.

If all points from 1-10 are rectified. This issue will be automatically addressed.

9. Client-Side (JavaScript) Cookie References:

Appscan found a reference to cookies in the JavaScript. The complete logic of cookie generation is available to client which can easily be retrieved & misused. Remove business and security logic from the client side

Please write below code in web.xml.

 

10. Insecure HTTP Methods Enabled:

It is possible to upload, modify or delete web pages, scripts and files on the web server. The Allow header revealed that hazardous HTTP Options are allowed, indicating that WebDAV is enabled on the server which means GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS are permitted. Disable WebDAV, or disallow unneeded HTTP methods

Make below changes in web.xml and above issue will be resolved. This is a specific solution for JBoss. Tomcat and other server provide some other mechanism to solve this issue.