[ANN] Apache Tomcat 8.5.33 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.33. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled forward from the 9.0.x branch. The notable changes since 8.5.32 include: - Correctly decode URL paths (+ should not be decoded to a space in the path) in the RequestDispatcher and the web application class loader. - When pre-compiling with JspC, report all compilation errors rather than stopping after the first error. A new option -failFast can be used to restore the previous behaviour of stopping after the first error. Based on a patch provided by Marc Pompl. - Make the Jasper (JSP Engine) Java file generation process multi-threaded. By default, one thread will be used per core. Based on a patch by Dan Fabulich. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to prevent user access to JSP pages?
-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
RE: how to prevent user access to JSP pages?
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
Re: how to prevent user access to JSP pages?
On Mon, Aug 20, 2018 at 1:19 PM, Berneburg, Cris J. - US wrote: > Hi Woonsan > > Thanks for providing an "option C". :-) There is still much for me to learn. You're welcome. :-) > > 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. > > cjb> a. [...] adding a for each folder. > > cjb> b. [...] JSP files under the WEB-INF folder. > > wk> c. Implement a servlet filter which is mapped to /* with dispatcher > wk> options: REQUEST, INCLUDE, FORWARD. The filter may check the request > wk> URI or include/forward URI (through request attributes). > > While I have a general idea of what you mean, I don't know how to implement > that. Is that a standard practice? I think the option uses standards and doesn't depart from standard practices. The chapter 6 of the servlet spec [1] describes what Filter is, when/how it can be used, its lifecycle, etc. Dispatcher options are explained in 6.2.5. Your servlet filter implementation may be invoked as pre-processing component before other resources or servlets. When .jsp is accessed directly, your filter may be invoked as REQUEST dispatcher option (the default unless configured manually), you can check the resource path info through HttpRequestServlet#getRequestURI(). e.g, /examples/hello.jsp. If you want to check the cases where the JSP is included or forwarded through RequestDispatcher, you may check servlet request attributes described in the section 9.3.1 (for inclusion) or 9.4.2 (for forwarding). So, you might want to check include/forward path first and find requestURI afterward to check everything and modify the response as a result. For example, you can choose to send a 4xx response if the condition doesn't meet your requirement. All of those are based on servlet standards. HTH, Woonsan [1] https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf > > -- > 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
RE: how to prevent user access to JSP pages?
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. b. Separation of duties - I want the JSP's to simply render pages and the non-JSP servlets to do all the heavy lifting. -- Cris Berneburg, Lead Software Engineer CACI, IRMA Project phone: 703-679-5313 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Hi Woonsan Thanks for providing an "option C". :-) There is still much for me to learn. 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. cjb> a. [...] adding a for each folder. cjb> b. [...] JSP files under the WEB-INF folder. wk> c. Implement a servlet filter which is mapped to /* with dispatcher wk> options: REQUEST, INCLUDE, FORWARD. The filter may check the request wk> URI or include/forward URI (through request attributes). While I have a general idea of what you mean, I don't know how to implement that. Is that a standard practice? -- Cris Berneburg CACI Lead Software Engineer
RE: how to prevent user access to JSP pages?
Hi Chris Thanks for your insight and reply. cjb> I'd like to prevent users from requesting JSP pages directly, cjb> except for the login page. cs> Why except for the login page? I would include the login page cs> as something that should be fronted with a (non-JSP) servlet, cs> even if that servlet doesn't do anything right now. It gives cs> you great flexibility in the future. OK, that sounds reasonable. cjb> I want all requests to be handled by servlets. That way I can cjb> legitimately claim that all requests are being validated, input cjb> scrubbed, JSP's cannot be taken advantage of w/o their servlet cs> it's easy to put a servlet in front of everything that does cs> *not* provide everything above, but... let's just assume that's cs> all being competently done. Well, it is still a work in progress. cjb> a. One way I read is by adding a for each cjb> folder. One use case is for JSP include files. That looks cjb> possible but makes it seem like these are exceptions and not cjb> the rule. I want "deny, deny, deny" to be the default and the cjb> one or 2 allowable JSP pages to be the exception. cs> This is certainly doable, but it's a lot of work, and you have cs> to maintain those blacklists as your application grows. Agreed, and yuck. cjb> b. Another way mentioned is by having most of the JSP files under cjb> the WEB-INF folder. That way the users don't have access to the cjb> JSP's but the servlets do. [...] Also, that would require moving cjb> most of the JSP files. cs> This is the way I've always seen it done, and the way I would cs> recommend that you do it. OK, gotcha. cs> It *does* require that you move all your JSPs, but that's a one-time cs> headache and it sets a precedent for the future of your project(s): cs> put all your JSPs under /WEB-INF. cs> You will of course also have to fix every include/forward that you cs> have in your application I was afraid of that. :-/ Looks like yet another round of refactoring. :-) cs> fix every include/forward that you have in your application to cs> include/forward to /WEB-INF/foo.jsp instead of just /foo.jsp. OK, thanks for letting me know how to do that. Will it work for both scriptlet <%@ include file="abc.jsp" %> and JSP includes? -- Cris Berneburg CACI Lead Software Engineer
RE: how to prevent user access to JSP pages?
Hi Louis Thanks for replying to my request for help. :-) 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. cjb> a. One way I read is by adding a for each cjb> folder. One use case is for JSP include files. That looks possible cjb> but makes it seem like these are exceptions and not the rule. I cjb> want "deny, deny, deny" to be the default and the one or 2 allowable cjb> JSP pages to be the exception. lz> can't you create a Security Folder and list out only the JSPs lz> that you want to allow the users access to? My application is lz> a third party application so I didn't develop it but they use lz> a folder that has a list of .jsps that I can access so I assume lz> they have set it up in the code. It sounds like you're suggesting something like option (a), using security constraints linked to folders. lz> Or am I just telling you the end state that you want to achieve lz> without actually coding suggesting any coding for you? Yeah, that's an end-state, and the security folder would be one possible method of getting there. -- 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
[ANN] Apache Tomcat 9.0.11 available
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.11.
Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.
Apache Tomcat 9.0.11 is a bugfix and feature release. The notable
changes compared to 9.0.10 include:
- Correctly decode URL paths (+ should not be decoded to a space in
the path) in the RequestDispatcher and the web application class
loader.
- Add a default location for the native library: ${catalina.home}/bin
- Make the Jasper (JSP Engine) Java file generation process
multi-threaded. By default, one thread will be used per core. Based
on a patch by Dan Fabulich.
Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
Downloads:
http://tomcat.apache.org/download-90.cgi
Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html
Enjoy!
- The Apache Tomcat team
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: how to prevent user access to JSP pages?
David Thanks for taking the time to reply. :-) cjb> Due to security concerns and general fussiness on my part, I'd like to cjb> prevent users from requesting JSP pages directly [...]. That way I can cjb> legitimately claim that all requests are being validated, input scrubbed, cjb> JSP's cannot be taken advantage of w/o their servlet chaperones being cjb> present, etc. dw> JSPs are servlets. dw> For us, the common way would be for your non-JSP servlets to authenticate dw> the request (and save the results in the request), and then your JSPs can dw> check if the request has been authenticated before progressing further. dw> Of course, if it's just a login check, you can save the results of the dw> authentication in the session, and when missing, redirect to your login. It's more than just initial authentication, which the application does perform. I want to: 1. Prevent users from requesting pages directly to: a. Prevent errors due to missing query data from bypassed process. b. Reduce the application's attack surface size. 2. Hide JSP's from security scanning software. Again, shrinking the app's attack surface. See Chris Shultz's reply about MVC, which captures my concerns most eloquently. -- 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
Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?
I've solved this by removing the completely and doing a 301 redirect to https:// in nginx (which is in front of Tomcat) instead: https://nginx.org/en/docs/http/converting_rewrite_rules.html Also added HTST header as suggested in this thread: https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#HTTP_Header_Security_Filter On Fri, Aug 17, 2018 at 8:24 PM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Mark, > > On 8/17/18 11:49 AM, Mark Thomas wrote: >> On 17/08/18 14:57, Christopher Schultz wrote: >>> Mark, >>> >>> On 8/17/18 4:09 AM, Mark Thomas wrote: On 16/08/18 13:40, Martynas Jusevičius wrote: > Hi, > > my initial observations suggest, and SO post [1] seems to > confirm, that when > > > CONFIDENTIAL > > > is specified on a security-constraint in web.xml, Tomcat does > two things: 1. automatically redirects to HTTPS 2. appends > Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 > CET response headers > > Is that correct? >>> It is broader than that. Tomcat adds those headers to any resource that is protected by any security constraint. >>> > I had added the CONFIDENTIAL because I want the redirect to > HTTPS. What I don't want is Tomcat overriding my caching > headers and effectively disabling browser caching. >>> Those headers shouldn't disable browser caching. >>> >>> Expires: 1970 certainly effectively disables browsed caching. >> >> My understanding was that the browser caches the resource but marks >> it as stale which means it needs validation on the next request. > > That's essentially the same thing. The server can still return a 304 > response if the browser thinks it has an up-to-date copy, but it's > still a round-trip to the server that might be avoided. > They will mean the client has to revalidate the request. How relatively expensive that is will depend on the resources. >>> > Why in the world would those two things be conflated? >>> Security. Any resource protected by a security constraint should not be stored in a shared cache else information disclosure could occur. >>> >>> I'm curious, too: I can understand the "Cache-Control" header, >>> but why the "Expires" one? What about some CSS file that can >>> surely be cached by the browser? >> >> Looks like an HTTP/1.0 solution from a very short amount of >> research. Revalidation for a static file shouldn't be too >> expensive. >> >>> Is it possible for a servlet to override a single header -- say, >>> the "Expires" header? It might be nice to have a facility to >>> allow applications to override maybe just this one header (or, >>> optionally, just one *other* header). I glossed-over the servlet >>> spec and I don't see much in the way of proscriptions for >>> precisely how to handle security-constraints e.g. when it comes >>> to setting headers. >> >> It depends when the header is added. In this case the Authenticator >> adds them before the filter chain is invoked so it should be >> possible for an application to remove them. > > That's very good to know. > > There are very few headers that Tomcat automatically adds (at any > stage). Could those be described somewhere including when/where they > are added and whether they can be overridden? > > For example, I tried (and failed) to override the "Date" response > header at some point while testing my "replay response" sample code. > It might be nice to know that Tomcat adds (overwrites) that header > fairly late in the process. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8 > pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV > Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR > j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT > lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq > +qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA > leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3 > ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I > 5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5 > se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG > d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE > 1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ= > =8Svp > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
