File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes URL Tampering - How to Prevent Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "URL Tampering - How to Prevent" Watch "URL Tampering - How to Prevent" New topic
Author

URL Tampering - How to Prevent

Ab Beland
Greenhorn

Joined: Oct 09, 2003
Posts: 3
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
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


My Java Freeware:<br />MACCC - <a href="http://maccc.pipasoft.com" target="_blank" rel="nofollow">http://maccc.pipasoft.com</a><br />Nator - <a href="http://nator.pipasoft.com" target="_blank" rel="nofollow">http://nator.pipasoft.com</a>
Ab Beland
Greenhorn

Joined: Oct 09, 2003
Posts: 3
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: 12761
    
    5
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
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

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 ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

That makes sense. Thanks Mike.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URL Tampering - How to Prevent
 
Similar Threads
another design question on 'program to interfaces' or not
URLyBird 1.3.3: Validation of currency on the rate field
How do I refresh a jtable after I delete a row?
<auth-method>BASIC</auth-method> doubt??
JSF dynamic image