What are the security constraints when connecting to the database in a JSP?

[Robert Insanovation White]

If talking about good programming practices, I know that Servlets are meant to do the JDBC tasks, JSP are only for displaying the final information forwarded by the Servlet.

JSP are Servlets too, but I heard an idea that it is safer to make database operations in a Servlet.

The idea is that I have a few JSP that use JSTL tags to retrieve some database information. By doing this I was concerned that this may be bad design, though I really wanted to get in fit with the JSTL tags.

Are there any security weaknesses if doing some JDBC stuff in a JSP, by using JSTL or plain Java code in <%...%>?

P.S. In my JSP I only retrieve data, not modifying it.

[Tim Holloway]

The problem with putting business logic in JSPs is that for large-scale apps, this makes for really messy JSPs. I first ran into this issue with Microsoft ASPs and PHP pages.

When you mix code and display template in one file it has several consequences that quickly outweigh the convenience of having everything in one place.

1. Java Code and HTML/JSP syntax is very different. An intelligent text editor has to do extra work to detect which edit mode to use and to switch to it. When I used Emacs on a 200 MHz non-GUI machine as my editor (using its Java mode), I had time for a nice long scream every time the cursor moved down from a JSP text line to a Java text line or vice versa. It's much easier to have a source file containing only one type of coding and thus employ only one edit mode.

2. Java debuggers typically don't have much (if any) support for doing breakpoints and traces in JSP-embedded Java code. That makes maintenance a lot harder. That's also true, incidentally for complex EL expressions.

3. The preferred design paradigm (it's more than just a pattern) for GUIs, whether local or web-based is Model/View/Controller (MVC). That's because it splits the functions and characteristics of the display and its processes into neatly-delimited components (Separation of Concerns). Often the View isn't code at all, it's a template (declarative statements), as is the case where you pair a Controller Servlet with a JSP. Declarative programming is a lot easier than free-form programming. Your choices are limited, so there are fewer potential ways to screw up and it's easier to do automated validation of syntax (and to a degree, semantics). On the other hand, you don't want limitations on your business logic, so it makes more sense to have to code that part in Java.

[Robert Insanovation White]

Tim Holloway, thank you for sharing your great experience.

Just to sum up, it's mostly about good design code, but the security isn't affected (when using Java code in JSP)?

[Tim Holloway]

Well-designed code is less likely to contain bugs of all kinds, including security bugs.

The danger in coding a "read-only" query on a JSP is perhaps best summed up in this classic geek cartoon:



You can suffer SQL injection attacks even if the code's all in a separate Java module, but when it's in a JSP - like I said - things get messy and it's easier for stuff like that to happen.

[Rob Wehrstein]

+1 on injection attacks. Always validate form inputs on web pages to prevent injection attacks. Or, at the least, validate inputs if the data becomes part of a database query down the chain. And make sure the validation is done server-side. I'm not sure if I'm answering your question, as this weakness is not specific to JSP.

[Stefan Evans]

In terms of runtime execution of the code, there isn't any security difference between executing a servlet and a JSP - as you pointed out, a JSP gets converted to a servlet at the end of the day.
The JSTL SQL tags in and of themselves aren't inherently insecure. Of course you can introduce SQL Injection as easily as you can in server side code, but the <sql:param> tag is there for you to use.
However the SQL tags are not massively recommended either - in fact the documentation on those tags pretty much says they are useful for simple sites and prototyping, but not really fit for use in a large application.

The main reasons for not doing it have already been mentioned. Testability. Maintainability. Readability. Probably a whole bunch more of -ability things.