Closed nisbet-hubbard closed 6 days ago
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.
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)
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?
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.