[PR] review my code [tomcat]
sundarrajboobalan opened a new pull request, #746: URL: https://github.com/apache/tomcat/pull/746 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] review my code [tomcat]
csutherl closed pull request #746: review my code URL: https://github.com/apache/tomcat/pull/746 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] review my code [tomcat]
csutherl commented on PR #746: URL: https://github.com/apache/tomcat/pull/746#issuecomment-2312385197 I'm not sure what the goal of this was, or if it was an accident, but this isn't usable so closing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Cookie parsing and upcoming updates to RFC6265
On 26/08/2024 15:14, Christopher Schultz wrote: All, On 8/16/24 11:25, Mark Thomas wrote: On 16/08/2024 13:40, Tim Funk wrote: How about missingEqualsCookie="allow | ignore"? The proposed options were: - ignore - name - value By using [allow | ignore] instead of yes/no, it opens the door to additional behaviors. (such as reject which triggers a http error) Agreed. I think maybe we should couple this new configuration attribute with an enabled-by-default Valve (maybe only in 11/12, disabled-by-default in 9/10) that detects empty cookie names and throws an exception and/or returns a 400 response. "ignore" should remove the cookie entirely and allow requests containing these to be serviced. Using the "value" option with this Valve enabled would cause a 400 response. Or it could be worked-into an existing Valve/Filter such as the HttpHeaderSecurityFilter or similar. Or we could add a "reject" option to the configuration setting that triggered an exception. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Cookie parsing and upcoming updates to RFC6265
On 26/08/2024 15:09, Christopher Schultz wrote: Mark, On 8/16/24 04:32, Mark Thomas wrote: On 14/08/2024 19:12, Konstantin Kolinko wrote: I think that 1) We would better switch to "ignore" mode right now, in all supported versions. Based on past experience I am extremely hesitant to change anything related to cookie handling behaviour unless we have to. I'd prefer to use "name" as the default more for 9.0.x and 10.1.x. I'm prepared to be convinced otherwise though. 2) The "empty name" option seems to be the correct behaviour, But as the majority of web applications would not need this feature, I think that\ "ignore" would better remain the default behaviour. No objections to that. I'm going to start working on this "noEqualsCookie" option. Suggestions for a better name still welcome. cookiesWithoutEquals? That sounds better to me too. Thanks. We haven't had any releases so I can easily do a rename. Unless there are objections, I'll do this tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Cookie parsing and upcoming updates to RFC6265
On 26/08/2024 14:58, Christopher Schultz wrote: What good is a cookie with no name? I'm not sure. I know we had some users that wanted a cookie without a value (I guess it is some sort of boolean flag). That makes more sense to me than a cookie without a name. Is this one of those "optimizations" where an application has only one cookie and doesn't want to waste all those bytes on a pesky cookie _name_? I haven't yet found (or thought of) a use case for this behaviour. The place to start researching is probably: https://github.com/httpwg/http-extensions/issues/159 I haven't read all the links yet. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1920229 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml
Author: markt Date: Tue Aug 27 15:59:06 2024 New Revision: 1920229 URL: http://svn.apache.org/viewvc?rev=1920229&view=rev Log: Update after review from schultz - only small parts of AJP is trusted Modified: tomcat/site/trunk/docs/security-model.html tomcat/site/trunk/xdocs/security-model.xml Modified: tomcat/site/trunk/docs/security-model.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-model.html?rev=1920229&r1=1920228&r2=1920229&view=diff == --- tomcat/site/trunk/docs/security-model.html (original) +++ tomcat/site/trunk/docs/security-model.html Tue Aug 27 15:59:06 2024 @@ -13,7 +13,13 @@ Vulnerabilities in deployed web applications are application vulnerabilities, not Tomcat vulnerabilities. Data received by an HTTP connector is untrusted. - Data received by an AJP connector is trusted. + Data received by an AJP connector is untrusted apart from: + + The standard request attributes and any arbitrary request + attributes permitted by + allowedRequestAttributesPattern + + JMX is an administrative interface and users with access to it are trusted. The Manager and Host manager web applications are administrative Modified: tomcat/site/trunk/xdocs/security-model.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-model.xml?rev=1920229&r1=1920228&r2=1920229&view=diff == --- tomcat/site/trunk/xdocs/security-model.xml (original) +++ tomcat/site/trunk/xdocs/security-model.xml Tue Aug 27 15:59:06 2024 @@ -21,7 +21,13 @@ Vulnerabilities in deployed web applications are application vulnerabilities, not Tomcat vulnerabilities. Data received by an HTTP connector is untrusted. - Data received by an AJP connector is trusted. + Data received by an AJP connector is untrusted apart from: + + The standard request attributes and any arbitrary request + attributes permitted by + allowedRequestAttributesPattern + + JMX is an administrative interface and users with access to it are trusted. The Manager and Host manager web applications are administrative - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml
On 26/08/2024 15:18, Christopher Schultz wrote: + Data received by an AJP connector is trusted. Maybe clarify which data you are talking about? I'm guessing that "request attributes" and certain headers should be considered trusted, but the request entity for example is not. Thanks. Good catch. I've updated the docs. Any further changes before I add some links to this page from the security docs? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [QUESTION] Purchase UML tool using Google security funding
On 26/08/2024 15:41, Christopher Schultz wrote: Personally, I am leaning towards spending the $99 so we can remove the watermark from the Tomcat docs. 1. $99 is nothing, even if it ends up being tied to a single person. I've been thinking about this some more and I'd prefer the floating license since that is what we really want - so anyone on the PMC can use it. There might be a few hoops to jump through to use it but I think it is worth it to ensure we can edit these docs going forward. That is $129. Which is still not very much. 2. Maybe they would give ASF one of more licenses at no charge? I suspect not. They have a free non-commercial edition. It just adds the watermark. I wouldn't want to put the burden of updating all diagrams on just one committer, even if you are kind of volunteering, here. Hence my leaning more towards the floating option. While I am happy to do this now, should someone else need to update these diagrams a few years down the line I'd like everything they need to do that to be in the PMC private repo. There is no great rush here but I'd like to get this sorted while it is top of mind. Therefore, I plan to purchase 1 floating license for the Tomcat PMC with the Google funding early next week unless there are objections. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Cookie parsing and upcoming updates to RFC6265
Mark, On 8/27/24 11:31, Mark Thomas wrote: On 26/08/2024 15:14, Christopher Schultz wrote: All, On 8/16/24 11:25, Mark Thomas wrote: On 16/08/2024 13:40, Tim Funk wrote: How about missingEqualsCookie="allow | ignore"? The proposed options were: - ignore - name - value By using [allow | ignore] instead of yes/no, it opens the door to additional behaviors. (such as reject which triggers a http error) Agreed. I think maybe we should couple this new configuration attribute with an enabled-by-default Valve (maybe only in 11/12, disabled-by-default in 9/10) that detects empty cookie names and throws an exception and/or returns a 400 response. "ignore" should remove the cookie entirely and allow requests containing these to be serviced. Using the "value" option with this Valve enabled would cause a 400 response. Or it could be worked-into an existing Valve/Filter such as the HttpHeaderSecurityFilter or similar. Or we could add a "reject" option to the configuration setting that triggered an exception. At what stage would this trigger an exception? Coudl the application somehow catch that exception? I would think that a 400 response might make more sense because what does "reject" mean to an application when Tomcat is doing the rejecting? It wouldn't be much different than "ignore" other than you have to tell the client it's being "rejected". That suggests a 400 response to me. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml
Mark, On 8/27/24 11:59, Mark Thomas wrote: On 26/08/2024 15:18, Christopher Schultz wrote: + Data received by an AJP connector is trusted. Maybe clarify which data you are talking about? I'm guessing that "request attributes" and certain headers should be considered trusted, but the request entity for example is not. Thanks. Good catch. I've updated the docs. Any further changes before I add some links to this page from the security docs? I think: " Vulnerabilities in deployed web applications are application vulnerabilities, not Tomcat vulnerabilities. " ...ought to mention that Tomcat-provided web applications are in-scope for security vulnerability reports. Manager and host-manager are quite important while ROOT, docs, and examples would be limited to e.g. "low importance" because they should never be deployed into a production environment. s/multi-cast/multicast/g This list is sufficiently long that we might want to break it down a little into separate sections with separate titles e.g.: Trusted Environments The following environments, user, and code are always considered trusted. Reports that users with control over these environments will be rejected on the basis that those users are in fact trusted and have administrative or equivalent access: * Deployed web applications * Access via JMX * Access via Java Attach API or other debugging interfaces * ... As I write this, it seems to be falling apart a little. Maybe this comment will spark someone else's creativity. But the list seems to be getting long and I'm a very strong supporter of "Parallel Structure"[1] in writing, and this is all over the place. -chris [1] https://en.wikipedia.org/wiki/Parallelism_(grammar) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
