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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
