[Question] Plans for access control?

[nisbet-hubbard]

Dear Kurihara-san, I was wondering if it’s going to be possible to write regex rules in rpxy’s configuration file to deny access (eg for bots) based on the value of various request headers?

We’d like to see the ability to do this at the stage of reverse proxy as most of such rules apply across our applis.

[Gamerboy59]

I understand that you want to drop bot traffic as early as possible. However, imo this kind of configuration is application level, which is done on the application server (in this case webserver) and not part of network architecture where rust-rpxy is operating.

[junkurihara]

Hi, sorry for my delayed reply.

Yes, as @Gamerboy59 mentioned, I think such access control policies should be handled by the backend app since the rpxy is designed to focus on routing traffic. (Thanks @Gamerboy59!)

I also think that designing such a request-header-based filtering function is tough since it requires very generalized pattern matching for header keys and values (Maybe regexp-based rule is needed). It might become a vulnerability against DoS attacks consuming the computational resources (c.f. ReDoS)

(Simple filtering based on network information, i.e., IP addresses, would be nice for me. not planned yet though)

[nisbet-hubbard]

It might become a vulnerability against DoS attacks consuming the computational resources (c.f. ReDoS)

Interesting angle. We removed all backreferences from our regex rules through (?:, which should help, but we were thinking of speed rather than security. You've made me inspect them again for NFA patterns.

I think the two of you have made a good case for leaving this to the app layer. That said, I suppose you're aware that the Rust regex crate uses DFA by default and can handle untrusted input?

[junkurihara]

That said, I suppose you're aware that the Rust regex crate uses DFA by default and can handle untrusted input?

I didn't know that. Thanks for that information

[hsnoil]

I think having it as an option for a reverse proxy. Here are some example use cases:

1. You use a common software, by setting the login path behind a header or cookie, you can pretty much eliminate 99.9999% of automated bot hacking your login path if there is an exploit.
2. You use a closed source software where you have minimum control over the backend app
3. You use an open source software, but it constantly reloads its entire settings every time it is upgraded forcing you to delay updates until you manually change it every time (mostly an inconvenience but still)
4. The backend app is managed by a 3rd party and you don't have direct access
5. When a user logs in, you store their login cached locally then add a cookie or header that indicates what server they are logged into. With a reverse proxy you can then forward them to the proper server instead of it being random. Forcing it into the app forces a lot of extra logic and servers must be aware of each other instead of just having the proxy route it

In all these cases it forces one into using something like nginx as a reverse proxy.

If that is still out of scope, then maybe consider dynamic loadable modules or wasm extensions?

[nisbet-hubbard]

1 comes under my original question, but fronting closed-source/3rd-party apps, carrying local patch for backend, and session persistence are scenarios I didn’t really consider.

I guess rpxy would have to decide whether to support these fairly common use cases.

[nisbet-hubbard]

Isn’t session persistence (number 5) already supported as part of load balancing?

[hsnoil]

there is an option of having a sticky cookie, but the problem is it is generic. If you have a logged off site, the site would generally be cached pages. But if someone is logged in, you want it to start load balancing as you are now going into processes that use up resources.