-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Terrence,
On 8/18/18 10:39 PM, Terence M. Bandoian wrote: > On 8/17/2018 8:52 AM, Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Mark, >> >> On 8/17/18 3:54 AM, Mark Thomas wrote: >>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote: >>>> Due to security concerns and general fussiness on my part, >>>> I'd like to prevent users from requesting JSP pages directly, >>>> except for the login page. I want all requests to be handled >>>> by servlets. That way I can legitimately claim that all >>>> requests are being validated, input scrubbed, JSP's cannot be >>>> taken advantage of w/o their servlet chaperones being >>>> present, etc. >>> I'm struggling to understand what risks exists with JSPs that >>> don't with Servlets. After all, a JSP is just an alternative >>> way to write a Servlet. Tomcat translates the .jsp file to the >>> .java source for a servlet, compiles it and runs it. >>> >>> Can you elaborate? >> JSP support for input validation, etc. is basically non-existent. >> I'm sure someone has a crappy library that can do it, and yes, >> you can implement everything in JSP using miles of tag libraries >> and stuff like that, but in the application world, that's a >> serious no-no. >> >> MVC (or some version of it, under various names) is the "proper" >> way to build software, and JSPs are relegated to the "V" portion >> of that paradigm. >> >> Once you have decided that JSPs are squarely in the "V" category, >> it's no longer appropriate for them to be treated as "C" >> components and therefore they should not be accessed directly. >> Protecting them from direct-access is a reasonable decision for a >> number of reasons, including security if you have pages that >> cough-up sensitive information under the assumption that >> authentication and authorization requirements have previously >> been satisfied. >> >> Sure, the container's authentication and authorization should be >> able to protect those JSPs just fine, but the application may >> have other controls in place that also need to sanity-check >> things before the JSP takes over. >> >> So, while there isn't anything particularly "dangerous" about >> direct-access to JSPs, there are a number of "best practices" >> that suggest that hiding them is a good idea. >> >> I hope that helps explain Cris's (likely) reasoning a little >> more. >> >> - -chris > > > As far as I know, there is no input validation that can be > performed in servlets that can't also be performed in JSP pages > using the same Java code. Also, I'm not aware of any functional > limitation that prevents JSP pages (classes) from being used as > controllers. As I understand them, JSPs can do anything that can > be done in servlets and offer additional facilities and > ease-of-use. They may be thought of as view-generators only but I > don't think that's a functional limitation. > > Could a servlet filter be used to reject external requests for JSP > pages? You are absolutely correct that (modulo a few edge cases), JSPs can do anything servlets can do. The issue is that they really should not do all of those things, and if you don't agree, that's all well and good: you can put your JSP files anywhere you want and allow direct-access. But for those who wish to implement a separation-of-concerns in their applications, hiding JSPs behind a standard mechanism (i.e. /META-INF) is a reasonable course of action. My post was intended to give background for why anyone would want to do this, not that everyone should do this because of some fundamental problem with JSPs. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt7BFQACgkQHPApP6U8 pFjEVBAAgOOuo7K0nBZsiCNLy4QbNlDiUUeubz0h1lF5ECbMWcamB9Kd9n5k/qzx VKDcLVuL46Sb6AJ/4wxomx4DIzOq2umhqLLxugo55ZZmD1w0HPT8+iQjq9wHUl9t tHX56E9oGFzJP+mYdBVDMpYrXFE5j9AXVw00LiwRDCqwMqdctqftkFudYcEYIte9 nm87gCbbUgcBWs2MqEZFEBUWURUFYOpYBCCY9Hwmwt/ijmOkkO9OK2VCBNGFZtnG 6xH8VKuQARip+dkS3+DeyGFerJVW05REi1nq2ZSwn7JbOSXd60PcalJo57MRyE6u 6b98b3UEQEUaUopCSmY5LaqfAMmlKu8Yl4da8Z1PVgwVBZZh+rKKUE+M9M/Kb//l DmgfrPs/G4tQcZr2jpMkXs63CvcWlyYHH3pvO/bf+ZcWq6w0yCl6JPK7/I1J1+zl z8+AO8tCgvFXuy6c6KH5zABV2tlpLmKb1jbcd3hRGDExZQ+agZUHWqsAGYi7P17K ToULyRrwKjdIm3PS7ljbJYo0gJ9FTqk1ChKl/Gy0KvzElY5KAt2ry19AGl8snT2w goMihDcVKD7b448HEEqPmNle7SRRPJH/yvNeUMumFskTIChKwNOqU5LavwdwZJ4g atGbrg1W+HeF600Ex/9VZ6hS6CbNdxmjgQ3FBBiALIiPdTv45S4= =Zj+o -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
