test: in and contains are dangerous

[schmichael]

Workaround

This is precisely why products like Consul and Nomad allow for mapping scalar and list claims separately.

In the example below, Consul and Nomad users would map the Role claim with something like:

  "ClaimMappings": {
    "http://example.com/role": "role"
  },
  "ListClaimMappings": {
    "http://nomad.com/role": "role_list"
  }

And then use a selector like the following to differentiate between the scalar and list versions of Role:

(role == admin) or (admin in role_list)

Implementations of bexpr used for authz or other security sensitive operations based on user supplied data must map that data to statically typed fields as above to avoid privilege escalations.

I think it's probably worth merging this test to hopefully make this behavior a tiny bit more obvious.

Original Description

The in and contains operators work on multiple data types: strings (as a substring test) and containers (as a membership test).

Unfortunately it has been observed that some authorization servers will mix types in their responses which are processed by bexpr in auth binding rules.

For example an authorization server may return either:

{"Name": "Alice", "Role": "db_admin"}
{"Name": "Bob",   "Role": ["admin", "foo"]}

A binding rule attempting to match on the admin role would be written as:

admin in Role
Role contains admin

Unfortunately these bexpr expressions will match both Alice and Bob due to substring matching.

[mukeshjc]

LGTM.