Mark,
On 8/28/24 06:48, Mark Thomas wrote:
On 27/08/2024 17:34, Christopher Schultz wrote:
Mark,
On 8/27/24 11:59, Mark Thomas wrote:
On 26/08/2024 15:18, Christopher Schultz wrote:
<snip/>
+ <li>Data received by an AJP connector is trusted.</li>
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.
I've restructured the page. I've added the things you suggested. Any
better?
Yes, I like your work, here. I committed some minor changes. Mostly
re-wording the "giving the attacker administrative rights before an
attack is cheating" bit.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
