# HTTP/2 Rapid Reset Vulnerability

**URL:** <https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623>\
**Category:** Web\
**Created:** [October 11, 2023, 4:23pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623 "2023-10-11T16:23:48Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Joyce](https://forum.xojo.com/user_avatar/forum.xojo.com/john_joyce/32/15449_2.png) [@John\_Joyce](https://forum.xojo.com/u/John_Joyce)\
**Post date:** [October 11, 2023, 4:23pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/1 "2023-10-11T16:23:48Z")

</div>

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/](https://www.securityweek.com/rapid-reset-zero-day-exploited-to-launch-largest-ddos-attacks-in-history/)

---

<div class="post-metadata">

**Author:** ![Christian\_Schmitz](https://forum.xojo.com/user_avatar/forum.xojo.com/christian_schmitz/32/158_2.png) [@Christian\_Schmitz](https://forum.xojo.com/u/Christian_Schmitz)\
**Post date:** [October 11, 2023, 4:37pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/2 "2023-10-11T16:37:00Z")

</div>

Yes, of course.

---

<div class="post-metadata">

**Author:** ![AlbertoD](https://forum.xojo.com/letter_avatar_proxy/v4/letter/a/dbc845/32.png) [@AlbertoD](https://forum.xojo.com/u/AlbertoD)\
**Post date:** [October 11, 2023, 4:56pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/3 "2023-10-11T16:56:52Z")

</div>

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

> **[HTTP/2 Rapid Reset Attack Impacting NGINX Products - NGINX](https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/)**
>
> Update your NGINX configuration to mitigate a possible denial-of-service attack implemented on the server-side portion of the HTTP/2 specification.

---

<div class="post-metadata">

**Author:** ![Tim\_Parnell](https://forum.xojo.com/user_avatar/forum.xojo.com/tim_parnell/32/161_2.png) [@Tim\_Parnell](https://forum.xojo.com/u/Tim_Parnell)\
**Post date:** [October 11, 2023, 5:06pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/4 "2023-10-11T17:06:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![AlbertoD](https://forum.xojo.com/letter_avatar_proxy/v4/letter/a/dbc845/32.png) [@AlbertoD](https://forum.xojo.com/u/AlbertoD)\
**Post date:** [October 11, 2023, 5:13pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/6 "2023-10-11T17:13:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Tim\_Parnell](https://forum.xojo.com/user_avatar/forum.xojo.com/tim_parnell/32/161_2.png) [@Tim\_Parnell](https://forum.xojo.com/u/Tim_Parnell)\
**Post date:** [October 11, 2023, 7:19pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/7 "2023-10-11T19:19:43Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Greg\_O](https://forum.xojo.com/user_avatar/forum.xojo.com/greg_o/32/22785_2.png) [@Greg\_O](https://forum.xojo.com/u/Greg_O)\
**Post date:** [October 11, 2023, 7:41pm UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/8 "2023-10-11T19:41:32Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Ricardo\_Cruz](https://forum.xojo.com/user_avatar/forum.xojo.com/ricardo_cruz/32/7852_2.png) [@Ricardo\_Cruz](https://forum.xojo.com/u/Ricardo_Cruz)\
**Post date:** [October 12, 2023, 8:39am UTC](https://forum.xojo.com/t/http-2-rapid-reset-vulnerability/77623/9 "2023-10-12T08:39:01Z")

</div>

> [@Tim\_Parnell](#):
>
> @Ricardo_Cruz do you think these limits could interfere with normal Xojo Web operation?

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.

> [@Greg\_O](#):
>
> serve http/2.0 connections for an app that can only handle http/1.1

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.
