from mobile (sorry for typos ;)
On Fri, Jun 20, 2025, 18:16 Hrvoje Lončar <horv...@gmail.com> wrote: > Well, I should say it was a weird way to fix it. > > For example, if you don't have a DoS attack AFAIK defaults should be set to the values preventing DoS Waiting for the DoS is not a good idea :) 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/>* >
