Well, I should say it was a weird way to fix it. For example, if you don't have a DoS attack and you upgrade your Tomcat, that would be a big surprise as it was to me. Lucky me I have nice users that contacted me and told me some features of my web app stopped working. Moving to next minor release shoulnd't be a surprise even if it is bug fix such you mentioned. Default value should be higher and it should be clearly noted that you have to lower it down to go to safe side regarding DoS attacks.
But then again, if you have an actual attack, you're forced to fix something anyway, so setting the parameter to lower value (as default should be set to higher values) would be the better fix than upgrading the whole Tomcat, especially if you can expect major changes that could surprise you as they did me few days ago. Installing a new version is maybe not the best way to go while fixing vulnerabilites under attack if easier option is available (lowering value to be lower than default). Default value of 10 would be appropriate for major release when you expect major changes and you're prepared to additional work regarding upgrade. But switching from one minor release to another shouldn't break existing setup, it should only fix bugs. BR, Hrvoje Lončar On Fri, Jun 20, 2025 at 1:02 PM Mark Thomas <ma...@apache.org> wrote: > On 20/06/2025 11:54, Hrvoje Lončar wrote: > > Thank you very much > > Mark ThomasThat was the case :( > > Absolutely weird to make such a major change in a minor release from > > NN.MM.39 to NN.MM.42 > > It was a response to a DoS security vulnerability. > > Feel free to add your views on what the defaults should be to the BZ > discussion. > > Mark > > > > > > > > > > On Fri, Jun 20, 2025 at 10:01 AM Mark Thomas <ma...@apache.org> wrote: > > > >> On 20/06/2025 02:07, Hrvoje Lončar wrote: > >>> Hi! > >>> > >>> Hope it's the right place to ask for help or/and advice. > >>> Few days ago I switched to latest Tomcat 10.1.42. > >>> After deyploy POST is not working due to missing CSRF token. > >>> When I inspect HTTP request, CSRF token is in a payload as "_csrf" and > >> the > >>> value is correct. > >>> But at the backend side I get > >>> > >>> * AccessDeniedException = Invalid CSRF Token 'null' was found on the > >>> request parameter '_csrf' or header 'X-XSRF-TOKEN'.* > >>> > >>> Everything works fine with 10.1.39. > >>> To be sure tried on 2 different Ubuntu servers - test and production > >>> instance. > >>> > >>> Anyone else having the same problem? > >> > >> Maybe related to: > >> > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=69710 > >> > >> Try setting maxPartCount on the connector but be aware of DoS risks as > >> the value gets higher. > >> > >> Mark > >> > >> > >>> > >>> Some technical info: > >>> - Ubuntu 24.04.2 LTS > >>> - nginx/1.27.5 to handle SSL certificate > >>> - Apache Tomcat 10.1.39 and 10.1.42 > >>> - Java 21 > >>> - Spring Boot 3.5.0 > >>> > >>> Thanks! > >>> > >>> BR, > >>> Hrvoje > >> > >> > >> --------------------------------------------------------------------- > >> 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 > > -- *TheVegCat.com <https://thevegcat.com/>* *VegCook.net <https://vegcook.net/>* *horvoje.net <https://horvoje.net/>*
