Any web application can have different levels of access permissions for various pages of the application. The levels of access rights / authorizations can be Admin users, End users, guest user’s etc., End users should not be able to access the administration pages and these access restrictions are usually implemented at JSP level.

The annotation of helper methods and classes on the backend can be overlooked by depending on the access restrictions provided by JSPs and so the problem is that many of these Helper methods, and the Service methods they call, don’t enforce their own security; they rely on the JSPs and the access rights XML to enforce their own security.

The result is that a user can call any form-action method of a helper from any JSP that can access that helper, even if different permissions would normally be required.

The fix is adding a set of annotations which will be added to helper methods and classes. These annotations mark the authorization required to perform a given form-action, before invoking the form-action method.


  • Burp Proxy (used the intercepting capability of burp)
  • JRE1.5 or later

About BURP:

BURP is an open source security testing tool used to identify security vulnerabilities in web applications. It has various features for testing. These include proxy, spider, intruder, repeater, sequencer, decoder and comparer.  The proxy feature of burp was used to test access right vulnerabilities in the application.

Burp Proxy: Using Burp proxy, one can intercept the traffic between the browser and target application. This option works in similar fashion to the man-in-the-middle attack vector. After setting up burp as a proxy to intercept the requests from the browser, switch the intercept mode “on” in the suite. When a request is intercepted by burp, user has two options, Forward and Drop. The Forward option allows the user to send the packets from the source IP to the destination IP. The Drop option allows the user to drop the packet if you feel it does not need analysis.

Test Approach:

Burp is used to test if security has been implemented correctly

  1. For each Helper class, capture a request and edit it to call specific form-actions that can be called from various types of users. (Not logged in users, End users, Admin Users, and guest users etc.,)
    1.  An end user should only have access to the form-actions they are intended to have access to (End user authorization, and ‘no authorization required’). Security verification will throw an error when end users try to access a method they do not have access to (admin authorization, Internal Admin authorization, and not a form-action).
    2. Admin users will have access to the form-actions they are supposed to. Admin user, if they choose to, can access admin methods through the buy-side (by capturing and editing requests) and security will not block the request. Admin users cannot access Super Admin methods.
    3. Actions that are supposed to run (valid security token) run properly
  2. Also test XSS vulnerabilities in the input fields by passing script into field values

Sample requests from BURP:

User has to modify the helper and use the helper he wants to test (for advanced testing)



Form action parameters that have to be modified (These are the methods under test)


Consider a case where a helper class, say H1 has two methods M1 and M2. M1 should be accessible to all users (admin and normal users) whereas M2 should be accessible only to admin users. Consider two JSPs, say JSP1 is accessible to all users and it can access the helper class H1 and JSP2 is accessible only to admin users and it can access the helper H1. In this case, if the methods in the helper are not annotated properly, normal users (who don’t have access to M2 in H1) with some advanced knowledge can access the admin method M2 by accessing the jsp JSP1 and modifying the form action parameters in the request sent from JSP1 to access the admin methods of H1.



Testing all the helper classes led to proper use of annotations for all the helper methods and classes which were overlooked earlier at the mercy of security implemented at JSP level. Many XSS vulnerabilities were also observed and were fixed. However, for testing access related vulnerabilities using burp, testers need to know which JSP can access both admin and buy-side related helpers. These testing methods are highly useful for applications that have different access levels for different users. Using these testing methods can help testers identify major security flaws in the application well ahead in time and save a lot of time and resources, which wouldn’t have been possible through testing from UI.