tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berneburg, Cris J. - US" <cberneb...@caci.com>
Subject RE: how to prevent user access to JSP pages?
Date Mon, 20 Aug 2018 18:10:47 GMT
Chris (and Mark)

Bingo!

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?

cs> JSP support for input validation, etc. is basically non-existent. I'm
cs> sure someone has a crappy library that can do it, and yes, you can
cs> implement everything in JSP using miles of tag libraries and stuff
cs> like that, but in the application world, that's a serious no-no.

+1

Yeah, messy.

cs> MVC (or some version of it, under various names) is the "proper" way
cs> to build software, and JSPs are relegated to the "V" portion of that
cs> paradigm.

cs> Once you have decided that JSPs are squarely in the "V" category,
cs> it's no longer appropriate for them to be treated as "C" components
cs> and therefore they should not be accessed directly.

+1

Yup, separation of responsibilities.

cs> Protecting them from direct-access is a reasonable decision for a number
cs> of reasons, including security if you have pages that cough-up sensitive
cs> information under the assumption that authentication and authorization
cs> requirements have previously been satisfied.

cs> Sure, the container's authentication and authorization should be able
cs> to protect those JSPs just fine, but the application may have other
cs> controls in place that also need to sanity-check things before the JSP
cs> takes over.

+1

Beyond merely having the bouncer allowing the person into the club, there are other validation
and sanity-checks that need to happen, which I would prefer to be centralized, not in both
the JSP's *and* non-JSP servlets.

cs> So, while there isn't anything particularly "dangerous" about direct-
cs> access to JSPs, there are a number of "best practices" that suggest
cs> that hiding them is a good idea.

If some authenticated user can directly access a JSP page and manipulate the parameters, they
can keep reloading the page while varying conjured arguments to find and exploit potential
weaknesses.  Am I mistaken, but does vulnerability scanning software seem to feed on that
sort of thing?  Maybe it's just an illusion, but I feel like there is more security control
if a user must access a servlet first.

cs> I hope that helps explain Cris's (likely) reasoning a little more.

Exact-ically.

--
Cris Berneburg
CACI Lead Software Engineer


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Mime
View raw message