File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Security and the fly likes Items exposed thru' URL Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Items exposed thru Watch "Items exposed thru New topic
Author

Items exposed thru' URL

Lakshmi Anantharaman
Ranch Hand

Joined: Aug 01, 2001
Posts: 58
First of all - "Hacking Exposed J2EE & Java: Developing Secure Web Applications with Java Technology". = this book sounds cool and the newsletter just reminded me of something I was considering implementing at work .
Our enterprise J2ee application consist of a lot of links (mostly from a list-view) . These links expose "ids" or primary keys and incrementing or playing around with the links can possible allow you to view next record and other pages .
How can this be avoided . What would be a better approach -
1) Is there a way to trap user manilpulation on the address bar (with scripting )so that I can redirect it to an error page .
2) Should I encrypt my id and decrypt them on the server side so as incremnting a number , does not display details of another item .
3) Should JSP files names be changed and handled as *.X files with some filtering in between .
[ October 22, 2002: Message edited by: Laksh Anan ]
Brian Buege
Author
Ranch Hand

Joined: Oct 16, 2002
Posts: 42
Originally posted by Laksh Anan:
First of all - "Hacking Exposed J2EE & Java: Developing Secure Web Applications with Java Technology". = this book sounds cool and the newsletter just reminded me of something I was considering implementing at work .
Our enterprise J2ee application consist of a lot of links (mostly from a list-view) . These links expose "ids" or primary keys and incrementing or playing around with the links can possible allow you to view next record and other pages .
How can this be avoided . What would be a better approach -
1) Is there a way to trap user manilpulation on the address bar (with scripting )so that I can redirect it to an error page .
2) Should I encrypt my id and decrypt them on the server side so as incremnting a number , does not display details of another item .
3) Should JSP files names be changed and handled as *.X files with some filtering in between .
[ October 22, 2002: Message edited by: Laksh Anan ]

Laksh-
Boy, you've got a pretty interesting issue here.
Let me go through your options and see what I can add:
#1. I'm not sure if there is a way to do this or not (I don't think there is), but I'm not enough of a client-side scripting guru to know for sure.
#2. This would work. Use a fast, low strength symmetric algorithm like DES or just Base 64 encode the binary equivalent of the key number (this would probably be fastest). I don't think you'd suffer that much of a performance hit either - DES flies on modern CPUs.
#3. I'm not quite sure what you mean here. You could remap the JSPs to something else, but I'm not sure that the savy user couldn't figure out that instead of display.jsp, you're calling X.php... Let me know if I'm misunderstanding this one though... It's getting late and I may not be reading your post correctly.
Another idea is that you could use JavaScript client side (via onClick) to POST the data to the server instead of using a GET (which is what anchors do by default). This wouldn't obfuscate any ids, but it would keep them off of the address bar so that they wouldn't be easily manipulated by users... Then you could configure your JSPs to deny HTTP GET requests and only accept POSTs. This would prevent all but the craftiest user from goofing with the address bar.
Good problem to work on though. If you get a chance, post a follow up to let us know what you did and how it worked!


Brian Buege<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0072225653/brivacom-20" target="_blank" rel="nofollow">Hacking Exposed J2EE & Java: Developing Secure Web Applications with Java Technology</a><br />Visit the <a href="http://www.hackingexposedjava.com" target="_blank" rel="nofollow">Companion Website</a>
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

My $.02
#1 There is no safe way to do the first situation since you are assuming it MUST come through a browser and that all browsers behave the same. Someone writing HTTP directly to a Telnet client can get around all of this.
It is safer to maintain state via a session id, and this is the only data a user has access to. User ID's etc should only be managed on the server side.
There was a local bank that maintained the user id on the URL. They did some moderately clever things to hide that fact, that if you are a bank and you are dealing with user data, 'security through obscurity' is not enough.
As soon as someone works out what you're up to, they have complete access to client records.
#2 is the same as above - don't put the user id on the URL. Oh, and don't confuse Base64 encoding with encryption, like I've seen done at other places. (This isn't what Brian was suggesting, but it's worth keeping in mind)
#3 I'm not sure what you are trying to accomplish with this.
Hope this helps.
Dave
Brian Buege
Author
Ranch Hand

Joined: Oct 16, 2002
Posts: 42
David-
I kind of assumed that Laksh was talking about ids or PKs for a database table, not actual User IDs... Stuff like productIDs, vendorIDs, stuff like that... I interpreted the question in the context that his main focus was not allowing the user to drive the web interface manually by modifying the address bar, not to specifically protect any information.
If we're talking about user IDs or other authentication credentials, I need to recompose my answer because none of my four points really apply.
Laksh, can you clarify your post for us? Thanks!!!
[ October 23, 2002: Message edited by: Brian Buege ]
Lakshmi Anantharaman
Ranch Hand

Joined: Aug 01, 2001
Posts: 58
Originally posted by Brian Buege:
David-
I kind of assumed that Laksh was talking about ids or PKs for a database table, not actual User IDs... Stuff like productIDs, vendorIDs, stuff like that... I interpreted the question in the context that his main focus was not allowing the user to drive the web interface manually by modifying the address bar, not to specifically protect any information.
If we're talking about user IDs or other authentication credentials, I need to recompose my answer because none of my four points really apply.
Laksh, can you clarify your post for us? Thanks!!!
[ October 23, 2002: Message edited by: Brian Buege ]

Thanks you for your replies . I missed marking email notification of activity in this post . I am working throu them . I think I am going to settle for some kind of encoding (option 2) . But shall get back .
Yes Brian you were right in assuming what kind of id where exposed .
But the third option again you were right I was going to hide the filename such that with the use of some kind of template mechanism .
Use template A (a.jsp) but the body of this page would be determined by some state or flag .
Thanks you again for these responses .
[ October 23, 2002: Message edited by: Laksh Anan ]
Patrick Finnegan
Ranch Hand

Joined: Mar 05, 2002
Posts: 179
If the data is sensitive then there should be authentication on that area of the site. For example if the uri is www.mysite.com/database/list1 and the user changes this to www.mysite.com/database/list2 the authentication should deny access to /list2 if the user is not in the role assigned access to /list2.
Lakshmi Anantharaman
Ranch Hand

Joined: Aug 01, 2001
Posts: 58
Patrick ,
Thanks for your input - my pages are completely driven by permission but that leaves a lot of places open for manipluation . Our permission would restrict the user from entering into an page or doing specific operation in a page . But catching something like viewing another item would go "uncaught" mostly because ,right now we do not have a context level permission filters "this person -- with this item(list2)" .
This becomes critical especially if list2 is an item (say invoice ) that is sensitive , invoice just being an example

Originally posted by Patrick Finnegan:
If the data is sensitive then there should be authentication on that area of the site. For example if the uri is www.mysite.com/database/list1 and the user changes this to www.mysite.com/database/list2 the authentication should deny access to /list2 if the user is not in the role assigned access to /list2.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Items exposed thru' URL
 
Similar Threads
CMR fields
Calling bpel from java
Pdf conversion.
Is it possible to perform reverse process in recompiling .class files?