JSP/Servlet - Try to solve a bug in web-page

[b4u]

Hi,

I have a question regarding security on a web page developed using JSP & Servlets.

Let's imagine the following scenario, I'll simplify so you can understand about my problem:

listProducts.java
Servlet that makes a select on the database, for a list of products, then puts the data in the request, and forwards it to "listProducts.jsp".
Servlet is url-mapped to: "/listProducts".
URL: http://www.whatever-domain.com/products/listProducts

listProducts.jsp
Displays the list of products. Each one has an ID, which equals the primary key on the database.
If the user clicks a product, I'll call "deleteProduct?ID=12" (for example to delete product with id=12).
The list of products is different for each user logged in (user info on session), so it's not just a dump-all list. Let's imagine something like ... "User can delete only the products he has inserted".
URL: http://www.whatever-domain.com/products/listProducts.jsp (if accessed directly without going through the above servlet, there will be no data shown)

deleteProduct.java
It's the Servlet that deletes the products. It reads the ID from request, then it will execute the delete on the database (actually it calls a bean, which might call a Stored Procedure, but let's make it simple).
After that, it forwards to "deleteProduct.jsp".
Servlet is url-mapped to: "/deleteProduct".
URL: http://www.whatever-domain.com/products/deleteProduct

deleteProduct.jsp
Just a regular JSP file that displays a message like: "Product XYZ was Successfully Deleted!".
URL: http://www.whatever-domain.com/products/deleteProduct.jsp (if accessed directly without going through the above servlet, there will be no message shown)


This works great, to some extend ... now I'll have to correct an ENORMOUS BUG ...

If a smart user sees the list, he can view the code and see the list coding as well ... and can see something like:
ID=1 - Product A
ID=2 - Product B
ID=3 - Product C

If it clicks the product on the web page, he deletes one of those products listed ... one of his own products, so no problem here. But if he types the address:

http://www.whatever-domain.com/products/deleteProduct?ID=5

He is directly calling the servlet that deletes products, and will in fact delete the product id=5, which belongs to another user ...

Now I could, in the "deleteProduct.java" servlet, re-check if the ID belongs to the user, but the matter is a bit more complicated than that, and I want to avoid unnecessary repeated code (also I didn't do it in the first place).

So before I start coding some nasty code, I would like to ear some opinions on how could I control this ... with something like (correct/point me somewhere):

1# How can I see if the access on a particular Servlet was made through "direct access" (by typing on the address bar of any browser)?

2# And if I can implement #1, will a user be able to "change" the html code or javascript functions "on-the-run"? I mean, if you type "javascript:alert('ok');" on the address bar, you'll have an alert box displayed ... can a user use this to access/change the HTML DOM?



These situations make me think about currect security of the billions of web pages around ... many of them must be secure for sure ...

Thank you for your attention, and for your much appreciated help.

 

[torpid]

Originally posted by: b4u
Hi,

I have a question regarding security on a web page developed using JSP & Servlets.

Let's imagine the following scenario, I'll simplify so you can understand about my problem:

listProducts.java
Servlet that makes a select on the database, for a list of products, then puts the data in the request, and forwards it to "listProducts.jsp".
Servlet is url-mapped to: "/listProducts".
URL: http://www.whatever-domain.com/products/listProducts

listProducts.jsp
Displays the list of products. Each one has an ID, which equals the primary key on the database.
If the user clicks a product, I'll call "deleteProduct?ID=12" (for example to delete product with id=12).
The list of products is different for each user logged in (user info on session), so it's not just a dump-all list. Let's imagine something like ... "User can delete only the products he has inserted".
URL: http://www.whatever-domain.com/products/listProducts.jsp (if accessed directly without going through the above servlet, there will be no data shown)

deleteProduct.java
It's the Servlet that deletes the products. It reads the ID from request, then it will execute the delete on the database (actually it calls a bean, which might call a Stored Procedure, but let's make it simple).
After that, it forwards to "deleteProduct.jsp".
Servlet is url-mapped to: "/deleteProduct".
URL: http://www.whatever-domain.com/products/deleteProduct

deleteProduct.jsp
Just a regular JSP file that displays a message like: "Product XYZ was Successfully Deleted!".
URL: http://www.whatever-domain.com/products/deleteProduct.jsp (if accessed directly without going through the above servlet, there will be no message shown)


This works great, to some extend ... now I'll have to correct an ENORMOUS BUG ...

If a smart user sees the list, he can view the code and see the list coding as well ... and can see something like:
ID=1 - Product A
ID=2 - Product B
ID=3 - Product C

If it clicks the product on the web page, he deletes one of those products listed ... one of his own products, so no problem here. But if he types the address:

http://www.whatever-domain.com/products/deleteProduct?ID=5

He is directly calling the servlet that deletes products, and will in fact delete the product id=5, which belongs to another user ...

Now I could, in the "deleteProduct.java" servlet, re-check if the ID belongs to the user, but the matter is a bit more complicated than that, and I want to avoid unnecessary repeated code (also I didn't do it in the first place).

So before I start coding some nasty code, I would like to ear some opinions on how could I control this ... with something like (correct/point me somewhere):

1# How can I see if the access on a particular Servlet was made through "direct access" (by typing on the address bar of any browser)?

2# And if I can implement #1, will a user be able to "change" the html code or javascript functions "on-the-run"? I mean, if you type "javascript:alert('ok');" on the address bar, you'll have an alert box displayed ... can a user use this to access/change the HTML DOM?



These situations make me think about currect security of the billions of web pages around ... many of them must be secure for sure ...

Thank you for your attention, and for your much appreciated help.

Sorry, any implementation that does not check the user's right to the data is half-assed. You need to implement some common code to check whether the user is authorized to look at / delete each record. There's no way to check if the user typed in a URL versus clicked on it short of some ridiculous javascript. I don't know what makes your security checks so "complicated" but they need to be done. Perhaps you need to re-think how your security infrastructure works.

 

[b4u]

I was hopping there would be a way of making the web-pages being accessed only from other web-pages from the same "project". I know this would be some werd config thing, but that would allow me to skip some stuff. If the user works only within the web-pages, it works fine.

But if he tries to go around, it will fail ... well, I guess it's time to start thinking about coding the stuff.

Not much difficulty here, besides understanding someone else's code ... I'll take the chance to tweak some things out.

 

[kamper]

First rule of web coding: never ever trust anything from the client. Verify everything every time it comes in. You can count on javascript and browsers and stuff for convenience (so the user only hurts themself by messing around) but anytime anything malicious could happen you have to pull out all the stops and code it right.

 

[b4u]

Originally posted by: kamper
First rule of web coding: never ever trust anything from the client. Verify everything every time it comes in. You can count on javascript and browsers and stuff for convenience (so the user only hurts themself by messing around) but anytime anything malicious could happen you have to pull out all the stops and code it right.

Yes, I subscribe to that rule of double-tumb ... but wouldn't it be possible, in this or any other case, to have some filter that would apply to all jsp & servlets, and in the filter be able to check if the request came from the same web-pages and not from any other web-page (link) or from the address typed directly on the browser?

(That wouldn't solve a smart user who changes a page dynamically, though)

 

[kamper]

If it wouldn't stop a smart user then it's not acceptable. Checking referrers is completely unreliable and checking if the user typed the url in the address bar is not possible. You can't even assume that your users are using a browser.

 

[Mark R]

You need to store the currently logged in user's rights in a secure place (e.g. a session variable held on the server side). Before making any changes to your dB you need to verify the user's rights on the server side. Nothing else is reliable. You cannot rely on javascript. You cannot rely on URLs being correct. You cannot rely on checking referrers.

This does mean a lot of potentially very similar repeated code - but you should be able to write a few routines that will cover the vast majority of the situations, and then code the remainder individually.

If you have a good relational database then it may be simpler to implement your security at the database query level, rather than at the application level - In a project I'm currently working on, I'm gradually going through all the queries in my application, and rewriting them so that virtually every query includes a join to the user permissions table. Similarly, every delete statemement includes a some sort of 'where' condition to restrict it to the current user's permissions. I'm taking this opportunity to revisit the database layer to optimise and rewrite queries, adding paranoid error checking and improved transaction handling.