graphql icon indicating copy to clipboard operation
graphql copied to clipboard

`@authentication` filter operation

Open jroith opened this issue 1 year ago • 5 comments

I created a bug a few months ago for the @auth directive and hoped the issue would be resolved with the new directive, but this is not the case. Basically, authorization can be bypassed to read any protected type or field by checking fields using filters on related types.

Here is an example:


type Foo
  @authorization(
    validate: [{ where: { jwt: { roles_INCLUDES: "READ_FOO" } } }]
  )
 {
  name: String!
}

type Bar {
  test: String
  foo: Foo @relationship(type: "OF_FOO", direction: OUT)
}

So a direct query like { foos { name }} would fail as expected. But it is possible to run: { bars(where: { foo: { name_STARTS_WITH: "a" }}) { test }} This query should be rejected - it should not be possible to read name indirectly this way. I would expect an error to be thrown whenever "foo" appears in this filter and it does not meet the requirements. If this is not technically possible then the query should still be unconditionally rejected if "foo" occurs in the filter at all, rather than leaking protected data.

The query would also fails with a "filter" authorization on Foo. It does not work both for related objects and related lists.

jroith avatar Aug 14 '23 13:08 jroith