Christopher Schultz wrote:
>> Well yeah, it’s not like Envoy is a super niche proxy. We also found
>> the exact same issue in two other proxies in our network by the way.
>> Any proxy that does not consider path parameters when doing
>> path-based access control will have this issue when combined
Christopher Schultz wrote:
> On 9/24/20 07:46, Nils Breunese wrote:
>> Mark Thomas wrote:
>>
>>> On 24/09/2020 11:02, Nils Breunese wrote:
>>>
>>>
>>>
>>>> - Envoy allows the request based on the /v1/* rule, because it
>
Mark Thomas wrote:
> On 24/09/2020 11:02, Nils Breunese wrote:
>
>
>
>> - Envoy allows the request based on the /v1/* rule, because it does not
>> support path parameters, because they are not part of any recent standard
>> (RFC 2396 dropped them in 1998 [1]
Martin Grigorov wrote:
> Someone else had the same/similar problem and the conclusion was that
> according to the Servlet specification this is the proper way to process
> the request - the request url should be normalized. If you need to protect
> some paths then you should do whatever is necess
Julian Reschke wrote:
> Am 24.09.2020 um 12:02 schrieb Nils Breunese:
>> Hello,
>>
>> I recently learned that when a server that supports path parameters [0] —
>> like Tomcat (I found Jetty also does) — is run behind a reverse proxy that
>> does path-based a
Hello,
I recently learned that when a server that supports path parameters [0] — like
Tomcat (I found Jetty also does) — is run behind a reverse proxy that does
path-based access control checks and does not support path parameters, your
combined setup could be vulnerable.
Consider this setup:
