HTTP/2 Rapid Reset Vulnerability

Targets Web
1

My understanding is that Xojo uses HTTP 1.1

Does that mean it is immune from this major vulnerability?

https://www.securityweek.com/rapid-reset-zero-day-exploited-to-launch-largest-ddos-attacks-in-history/

2

Yes, of course.

1 Like
3

It looks like if you are using Nginx too, it could be affected:

4

I saw that post and my takeaway that using the defaults protects you.

6

Thank you Tim.

I’m not familiar with Nginx configuration and after reading the blog post it looks (for me) that

  • limit_conn
  • limit_req

are not set by default and could help. At least that is what I understand. I hope there are some defaults to those too.

Regards

7

I could certainly add those directives to Lifeboat configurations.

@Ricardo_Cruz do you think these limits could interfere with normal Xojo Web operation?

(@Greg_O I welcome your input as well, but fully understand that you may not want to comment)

8

The built-in back end for Xojo apps is a custom http server implementation of http/1.1, but in any scenario where an app would be exposed to the internet, it should be behind a proxy and possibly a load balancer like Nginx or Apache.

It’s been a while since I was deep into http server protocols, but it’s hard for me to believe that a proxy would serve http/2.0 connections for an app that can only handle http/1.1 because the connections are so different (a request/response vs a bi-directional stream).

3 Likes
9

Setting those properties is something that any Web application exposed to Internet will want to have. Please note that, if the request fails because of it, Xojo Web won’t try to send it again, so the value can’t be very limited.

Not sure if Nginx supports this but, depending on the type of application, this value needs to be different depending on the IP. So, connections from outside a whitelist will have a more restrictive value.

For example, a web application exposed to the internet where its admin panel is also accessed from a Call Center. The Call Center’s IP definitely needs a higher amount of allowed connections.

In any case, using a CDN (like CloudFlare, DosArrest, …) is more than recommended. It will help dealing with these attacks, with caching static assets, and it will help hiding the real backend IP.

Yeah, that works fine. The end user can connect to the proxy using one protocol, while the proxy can connect to the upstream backend using another one. In some (not all) literature it’s even recommended to avoid using HTTP/2 for communication between the proxy and the backend, to avoid the overhead.

1 Like