This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
How to I prevent URL tampering? With a filter? Is there a simple, but correct and secure way to prevent tampering of URL's returned by a servlet? I was thinking something along the line of: http://mycompany.com/myproduct/mywebapp?client=123&page=abc&digest=13AF39K9754DE where the validation string would be generated by a strong algorithm that encrypts "client=123&page=abc" and the session id?... I don't want to reinvent the wheel... thanks.
Brian Pipa
Ranch Hand
Joined: Sep 29, 2003
Posts: 299
posted
0
Define what you think the meaning of "URL tampering" is. I can think of a few different things that might be called URL tampering - each has a potentially different solution. Brian
Changing the client ID for example. Basic security means that the servlet cannot trust anything being requested from a page. You validate the session id (a filter can check if the user has logged in and is authenticated), but I want to prevent an already authenticated client to see products of another client by changing the URL. Or am I reading this wrong: that the session ID is, in and of itself, sufficient to re-authenticate/validate subsequent incoming requests...
William Brogden
Author and all-around good cowpoke
Rancher
Joined: Mar 22, 2000
Posts: 12267
1
posted
0
I think you are on the right track with something like a MD5 digest to detect tampering. For real protection it seems to me you could encrypt all of the parameters to a single base64 encoded string. Bill
Why can't you just store the client id in the session rather than passing it around in the URL? If the client can only see data for one client (themselves), this is a unique value.
in this case, i think he means 'client' in the following scenario:
the end user is NOT the clientid in question. As an example, the end user might be a sales man, tracking sales leads for numerous "clients", and of course, he should only see his own clients.
So the question is.. once you've passed through container-managed auth, or even custom-coded auth.. how do you prevent an "authenticated" user (our salesman) from viewing someone else's clients, simply by typing in a new clientid into the browser address bar?
I have a system at work where customer service reps should only be able to see and report on certain clients. And also... the actual clients should be able to log in and see certain (very minimal) information. The way I've done it is to create a "User" object when the user first logs in, and from the database I load up all of their permissions. Then on any JSP page, or processing servlet, I'll show links, or hide links, allow a request, or disallow a request, all based on the results of code like exmplified here: So this kind of code can be used to determine if the salesguy is allowed to call a certain action (like: deleteClient). The same technique might be used to restrict which clients he can see. You might build (on login) a List of all the clientids that the sales guy has permission to view. Then every time you are doing processing on clientid, you'd first check to see if the given clientid is found in this sales-guy specific list. If not, you've got someone trying to spoof their way into the system. [ October 13, 2003: Message edited by: Mike Curwen ]