On 8/21/2018 11:44 AM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Cris,
On 8/20/18 1:31 PM, Berneburg, Cris J. - US wrote:
Hi Mark
Thanks for taking the time to reply. :-)
cjb> Due to security concerns and general fussiness on my part, I'd
like cjb> to prevent users from requesting JSP pages directly
[...]. That cjb> way I can legitimately claim that all requests
are being validated, cjb> input scrubbed, JSP's cannot be taken
advantage of w/o their cjb> servlet chaperones being present, etc.
mt> I'm struggling to understand what risks exists with JSPs that
don't mt> with Servlets. After all, a JSP is just an alternative
way to write mt> a Servlet. Tomcat translates the .jsp file to the
.java source for a mt> servlet, compiles it and runs it. mt> Can
you elaborate?
See Chris Shultz's reply about MVC. He pretty much nailed it.
For me, it's a twofold combination of (a) security concerns and (b)
separation of responsibilities.
a. Security - shrink the attack surface.
It's worth pointing-out that what's shrinking is the attack surface
*of the application*, not necessarily of JSP (as a technology) itself.
While I agree 100% with (a), here, it's not because there is anything
inherently risky about JSPs. It's that most people end up writing
really awful JSPs that are full of holes.
b. Separation of duties - I want the JSP's to simply render pages
and the non-JSP servlets to do all the heavy lifting.
This item (b) allows you to more effectively achieve (a) IMHO. Also,
"separation of concerns" allows you to focus on one task in one piece
of code, instead of having a JSP that needs to enforce security,
sanitize inputs, query a database, manage the result set, etc. all
while providing error-handling, etc. Anything that makes code more
maintainable is a big +1 in my book.
One of the ways I have kept my code as maintainable as possible is by
not using JSPs :)
- -chris
So, you don't like JSPs. Okay by me. Others have found them useful.
Back on topic, do JSPs have to be registered with the container using
servlet mappings in web.xml or some other mechanism in order to serve as
targets of forwards by servlets? Further, does doing so make those JSPs
accessible via external requests? I suspect the answer to both
questions is yes which means an additional mechanism will have to be
introduced to block that access which I believe was the original
question. Servlet filter?
In some cases (e.g. GET requests), it may be simpler to perform any
required validation in the JSP.
Also, shouldn't all JSPs be located in WEB-INF? If I remember
correctly, built-in protection is provided to prevent access to the
source code of JSPs within WEB-INF. In addition, I'd recommend
pre-compiling JSPs when possible.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
