Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSP submit page security  RSS feed

 
Terence Xa
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would like to know is it a common practice in JSP development to have a data entry page submitting to a JSP page that specially is used for capturing and storing data. Let's say I have customer_data.jsp with all the entry fields, and then I have customer_save.jsp. Now, customer_save.jsp does not contain HTML code and is not meant for user to see, it does backend saving and then redirects back to the relevant page.

I wonder whether is there security issues associated with having customer_save.jsp being able to be executed by a user through the browser. Of course they would see a blank page, but nevertheless the fact that this JSP page is callable by user, means they are able to execute backend code. In worst case scenario, I'm afraid they might be able to inject something nasty.

I'm also wonder whether most JSP projects would rather have data entry page submit to some sort of servlet, compared to a dedicated JSP page.

In the past, I have had done projects where I use tokens to prevent execution of the customer_save.jsp by anyone. When a user runs customer_data.jsp, I would assign a random string to the user, and this string will be stored in a session variable and also on a hidden field on user's html page. When user submits to customer_save.jsp, I would then check this random string being submitted and whether it matches the one stored in session. Only if validated, then I would allow the page's code to run, otherwise, kick them away. Is this a good approach?

Just a recap of the example:
customer_data.jsp is the data entry page
customer_save.jsp is the page that captures data being submitted and then storing to database
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now, customer_save.jsp does not contain HTML code and is not meant for user to see, it does backend saving and then redirects back to the relevant page.

Then it should not be a JSP, but a servlet! JSPs are for generating textual output like HTML, not for business logic and DB access. The servlet would then forward to a JSP with the results of its processing.

In worst case scenario, I'm afraid they might be able to inject something nasty.

Most, if not all, JSPs should not be directly accessible. That's why they're often kept in a subdirectory of WEB-INF, because nothing in WEB-INF is directly accessible by the client.
 
E Armitage
Rancher
Posts: 989
9
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSPs should not contain any Java code at all and so should not be processing anything. All business logic should be written in classes that have nothing to do with JSPs or servlets. When the user captures data, submit to a servlet. In the servlet read all you need to read from Servlet specific APIs (eg request parameters) then call the classes that actually contain the business logic. This way

1.) You develop and test your business processing without involving servlets or servlet containers
2.) Your business processing logic is now reusable from other projects that may or may not be servlet based applications
3.) It is easy to change to different web frameworks because the web framework specific code is not mixed with the other application business logic.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!