we are having one web application developed using spring and deployed in jboss application server. And every thing working fine and recently security team team has done audit and found some of the issues.
Here the issue is they formed the URL as and tested and it is working fine.
here instead of parameter name logoutFlg (which is a hidden variable in jsp and defined in form bean) they manipulated as logoutFlg. (given one dot at the end) and tried accessing the URL then it is giving the exception
So would like to know how to handle such manipulation issues and redirect to the user defined page? where exactly I need to handle? We somehow handled this error in one of the customized filter but the issue here if we put the code the images in the pages are not getting loaded properly.
What we need to consider is 1. security 2. functionality
Since the initial problem is security, you would have probably considered OWASP guidelines to manage/validate all the parameters getting using some frameworks or custom filters complying with the application. However, I do not see any concern in this scenario since user doesn't manipulate the parameter values instead he manipulates the parameters(or key) itself.
To my understanding the it is a threat when
1. User bypass the validation process to submit an unusual request to be processed and the application code is capable of finding it out
2. User changes the parameters values to make the system behave in a different way in which is not intended (say for example, if you have a role id of the person as hidden and the user/attacker changes it to be a system admin role id or so)
3. User adds "new" parameters to the request which changes the behavior of the request
4. User manually creates his own request
All the above attacks can be taken care by application code and configurations but not changing the parameter which the application itself cannot understand. Say for example, in your case if I add "loggedInFlag" instead of "logoutFlg" the request should definitely fail and this what is called exception, this is because my application do not understand. If the security raised a concern it should never denote that "exception is the problem" - it is no where a concern. However, it would be concern if the exception from application like above is directly displayed to the end user in the UI - this is a threat. In this case we should be having no loop holes in the exception handling. So please verify what you are defending your application from in terms of security.
When 1. Security is solved efficiently and appropriately the 2. Functionality would be automatically addressed
To the current scenario. Let us know what is logic in your filter that you have mentioned. A code snippet would be quite helpful.
Additionally, since you have posted this in struts forum, I expect this spring application uses struts for view part. If it is Struts then it has a global exception configuration wherein we can handle each exception type specifically
Security forum is the best place for this topic. You would get more help
Have Fun with Java
little,little.. little by little makes a lot..
Srinivasa Rao Ammina
Joined: Jan 24, 2012
Dear Shankar Tanikella,
Thank you for the brief email and explanation on the issue.
Here the security concern is we should not display the Odd UI messages and we need to redirect to the respective error page.
I tried with the global exception but unable to forward the pages to custom exception jsp page.
what i can see from the stack trace is the control reaches Action Servlet, the struts exception configuration should have taken care of this, we are missing something. Anyways, for the safer side are the error pages defined in deployment descriptor? If no, do it, we can do it based on http status code and exception type (ex. throwable) as well. If struts cant catch it this would. For example,
This can never miss
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: java.lang.IllegalArgumentException: No bean specified