Recently I was asking to keep the user from manipulating one of the variables on the URL.
I was able to make some changes to the code to keep that variable name from being passed on the URL, however, if the user tries to manipulate it on the URL, they still can, meaning if they add it back into the URL, they can retrieve records and reports from other companies they are not supposed to have access to.
I was thinking in a broad level about what do I need to do, do I need to somehow keep the user from being able to change the session variable value on the url. I think what I would like to do if it is available, is find way to release a message to the user like, "This action is unauthorized." upon the presentation of the change on the URL to the browser.
Also, is there a way to "freeze" the session variable so that the user cannot change it on the url?
jatan bhavsar wrote:One suggestion change method to post instead of get in case you are using get method.
As Ulf has already pointed out, it is a complete myth that POST is somehow more secure than GET. Regardless of whether data is passed on the URL, or in the body of the request it is insecure unless encrypted via SSL.
1) Create a session variable in your application where you would store the "parentId"
2) In the report where you are using the parentId to filter the query you will have to read the session variable and add it to the query instead of the report parameter value. However, inorder to make it run from your desktop you may need the parameter otherwise it will always be null.
e.g. in the beforeOpen method of the query
var sessionParentId = null
sessionParentId = params[
this.queryText = 'select distinct home_short_name from home where parent_id = ' +sessionParentId;
3) While calling the report do not pass the parentId in the URL.
I have implemented step 2 and 3, but I am having trouble with step1. I have a base servlet to which I added this code:
Then I created a small servlet called parentchk, and it has this in it:
My problem is that when I follow steps 2 and 3, the application doesn't know what parentid it is on.
Does anyone have any suggestions on how I could implement this?
Michele Smith wrote:Is this sufficient:...
I don't know, are they? What did your testing efforts tell you?
Seems to me, you need to dig deeper into your application code to understand whether or not user authentication/authorization has been implemented. Does your application have a login page? If it does, start there. If not, then you don't have a current authenticated user. Just by themselves, the declarations you gave don't provide authentication/authorization.
At this point, I am just wanting to capture a parameter on the url with a session, not implement new authentication. I recognize there can be improvements to this design, however, it is not as critical as capturing the parameter passed on the url (querystring). Thanks,
Before you post any more code, please consider these:
1. This is a public forum. You may be violating some of your company's policies by posting real code here.
2. To get to the bottom of this issue, you'll probably have to post more code to give more context.
The code you posted from your Login servlet still doesn't tell enough. I suggest you go through http://docs.oracle.com/javaee/5/tutorial/doc/bncas.html and see if you can spot something that your application is also doing. Then go from there. If your app doesn't do anything like what the tutorial describes, then your app probably is in need of some serious re-design.
Michele Smith wrote:At this point, I am just wanting to capture a parameter on the url with a session, not implement new authentication. I recognize there can be improvements to this design, however, it is not as critical as capturing the parameter passed on the url (querystring).
This is where you often get into a Chicken-or-Egg situation: You can't change code easily because of issues in the design but you don't want to change the design because you can't change code easily. Sometimes, you just have to bite the bullet and go back to the drawing board. Here's one thing for sure: Good designs foster easy code changes.