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
