DoS vector - session pool exhaustion

So we have noticed that any time our application’s login page is requested, a new session is created on the server. This makes it quite trivial for an attacker to exhaust the session pool simply by rapidly repeating a GET request on the login page.
In the old JSP world, we could handle this by disabling automatic session creation for certain pages, and by carefully invalidating sessions on the server side for failed login requests.
Is there a similar set of practices to prevent this type of attack on a Vaadin system?

It might be possible to mitigate this by building the login page with Hilla (never tried) if you don’t wanna leave the Vaadin Ecosystem. But personally I would suggest to use a static page served with a reverse proxy as landing page and use an external authentication provider as login page so that all Vaadin pages require authentication.

4 Likes

Technically that is still possible with Vaadin, although we do not have a modern example doing so. In Vaadin 8 version of Bakery demo app we had login page implemented as Spring Boot served JSP, the same could be done in Flow as well.

The option to make it with Hilla as @knoobie said, is also a possibility, but we do not have sample for that either.

Naturally with typical SSO integrations this problem does not exists.

Your question is a good one, and valid concern when the login page is exposed to public. Quite many typical Vaadin applications are served in the internal network only, when there is no concern either.

One potential way to mitigate the problem would be to study if you can invalidate HTTP session on UI detach on login page (as we have the Eager UI close feature nowadays). Alternatively pagehide or beforeunload event listener can be added with JavaScript and invalidating HTTP session eagerly.

1 Like

Thanks for the comments.

I’m going to go the route of the standalone JSP. I thought that might be necessary, but I thought I’d check here first to see if there was a Vaadin-based solution I wasn’t aware of.

If you are on Spring stack and I recall correctly, removing your LoginView.class from Vaadin (and disabling/customizing something in Spring Security configs :thinking:) brings in the default Spring Security generated login page. In some project I spent quite some time to get rid of it :-) It is rather plain HTML generated by a raw filter, so JSP may be better if your want to customise it al lot.