Thanks!
50 as default would be much better and I guess it will cover the most of
cases.
Just out of curiosity, does CSRF protection implemented hepls with attack
or it does not matter?
On Mon, 23 Jun 2025, 09:02 Mark Thomas, <ma...@apache.org> wrote:
> On 23/06/2025 01:17, Hrvoje Lončar wrote:
> > If someone else has a problem with latest "security fix",
> > here is a working solution to run your Spring Boot app directly from
> > Eclipse STS
> > without installing a Tomcat and deploying to it.
> > Now you can submit forms the same way as you did before.
> > You can filter out my fix from production environment with `@Profile`
> > annotation.
> >
> > @Configuration @EnableWebSecurity(debug= *false*)
> > @EnableMethodSecurity(prePostEnabled
> > = *true*, securedEnabled = *true*, jsr250Enabled = *true*) *public
> > **class *HttpSecurityConfig
> > { // ... @Bean @Profile(Str.*DEV*)
> > WebServerFactoryCustomizer<TomcatServletWebServerFactory>
> > configTomcatConnector() { * return *factory ->
> factory.addConnectorCustomizers(
> > connector -> { connector.setMaxParameterCount( 1000 );
> > connector.setMaxPartCount(
> > 1000 ); } ); } // ...
>
> If you opt to do that then make sure to do one of the following:
> - ensure uploads are only accessible to trusted users
> - have 8GB heap spare (16GB if running on Java 8)
>
> or your application will be exposed to a trivial DoS that can disable
> the server via an OOME.
>
> I would *strongly* recommend increasing maxPartCount only to the minimum
> necessary for your application to work.
>
> Note: It looks like the default for maxPartCount will increase from 10
> to 50 in the next release round.
>
> Mark
>
>
> >
> > }
> >
> >
> > On Sun, Jun 22, 2025 at 3:19 AM Hrvoje Lončar <horv...@gmail.com> wrote:
> >
> >> The actual problem now is my embedded Tomcat when I start my Spring Boot
> >> app from Eclipse STS:
> >> I get the same error, but I don't know where to configure Tomcat and
> where
> >> to add this new paramerer.
> >> Anyone?
> >>
> >> On Fri, Jun 20, 2025 at 1:28 PM Maxim Solodovnik <solomax...@gmail.com>
> >> wrote:
> >>
> >>> 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/>*
> >>>>
> >>>
> >>
> >>
> >> --
> >> *TheVegCat.com <https://thevegcat.com/>*
> >> *VegCook.net <https://vegcook.net/>*
> >> *horvoje.net <https://horvoje.net/>*
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
