Add ignoreUriCase to AuthorizationPolicy

[dozer75]

Describe the feature request

The VirtualService has the ignoreUriCase that can be used to allow uri with any casing to be routed. However the AuthorizationPolicy uses the inbound uri to match against the rules which causes problems (and even security issues if AuthorizationPolicy is configured wrong). My main issue is that since we're having ignoreUriCase set in the VirtualService those requests are rejected since the AuthorizationPolicy has the URI rules case sensitive.

So, the request is that the AuthorizationPolicy should do the same. Having ignoreUriCase allowing the configuration to indicate if the Uri casing should be ignored or not when matching the rules.

Describe alternatives you've considered

After searching a bit there is a security advisory around DNS that suggests to add a Lua filter to the ISTIO config handling DNS casings, but this will then apply normalization globally to the ISTIO ingress level which isn't always something you want when it comes to the Uri.

Affected product area (please put an X in all that apply)

[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane

Additional context

Example:

Having a VirtualService with the following URI will route like these https://host/Api/v1/Customer, https://host/API/v1/customer, https://host/API/V1/CUSTOMER

  - name: "Route API requests"
    match:
    - uri:
        prefix: /api/v1/*
      ignoreUriCase: true
    rewrite:
      uri: /api/v1
    route:
    - destination:
        host: customer-service
        port:
          number: 80

But, they will be rejected since there is an AuthorizationPolicy match rule like

  - to:
       paths: ["/api/v1/customer"]

on ALLOW and the Authorization policy have a strict Uri casing, to support all various there would need to be 144 variations of to path for that path.

[louiscryan]

@liminw
@aryan16

[aryan16]

By adding case-insensitive option, we can make the authorization policies less secure. Attackers can easily bypass the policies if you set this option. We have faced this previously (GHSA-7774-7vr3-cc8j). And generally URLs are case sensitive (https://www.w3.org/TR/WD-html40-970708/htmlweb.html)

[briansonnenberg]

It really depends on the use-case. In its current form, a VS using ignoreUriCase matching is essentially incapable of using path matching in the authz policy.

[dozer75]

By adding case-insensitive option, we can make the authorization policies less secure. Attackers can easily bypass the policies if you set this option.

Partially true, it all depends on how the users defines the authorization policy e.g. if you have a authorization policy that has action: DENY in combination with case insensitive virtual services wrong cased authorization policy rule will allow actions unexpected so it all depends on how you're viewing it.

IMO having case insensitive option gives the user of ISTIO the opportunity to make the usage more flexible without ugly hacks that can cause other security issues out of the box. It should (as with virtual service) be defaulted to false, but it should exist.

And generally URLs are case sensitive (https://www.w3.org/TR/WD-html40-970708/htmlweb.html)

True, but as said; ISTIO supports case insensitive urls on virtual service level (which again "breaks" that w3 recommendation)...

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2022-10-10. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

[dozer75]

/reopen

[dozer75]

Well, that didn't work.. It's still an issue so it should not be closed...