Don't fetch populate private data

[arsenx]

Informations

• Node.js version:
• npm version:
• Strapi version:
• Database:
• Operating system:

What is the current behavior?
When querying a private table that has a relationship to a public table we are able to get access to unauthorized data.

Steps to reproduce the problem
GraphQL query a private table though a public table
Here is a link to a video I made to show the behavior. https://www.useloom.com/share/f3998defd8ad4c0a8600c8f66dce81c0

What is the expected behavior?
Return unauthorized message

Suggested solutions
Many ways to go about this depending on the source code which I haven't gone through.

[dmythro]

Well, that is big. Good news it is still in alpha :)

[lauriejim]

@arsenx I think there is a miss understand about permissions and data access.
You will have the same with API routes.

Permissions not block relations data access but it block controller actions.

[derrickmehaffy]

@lauriejim I think what he is saying is that via the REST route that data wouldn't show up (could be wrong, haven't tried setting up a relation to users model)

But that GraphQL is doing something that REST blocks

[derrickmehaffy]

@arsenx were you able to get password hashes?

[arsenx]

Password hashes are not returned due to a parameter on the field in strapi which I will check later today. This parameter option is not shown on the GUI. I know that GraphQL is not supposed to handle this but there should be some more light shed on this situation since this does not occur in standard REST calls. It may be confusing at first because we do set access control for the field but this does not apply in the even of a relationship call. Let me know if you would like me to write in more detail.

…

On Aug 22, 2018, at 12:10 PM, DMehaffy ***@***.***> wrote: @arsenx <https://github.com/arsenx> were you able to get password hashes? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1678 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFdDX2kRpQjGcjQgSv7vvUrPc23poisdks5uTYJ-gaJpZM4VpTuV>.

[avallete]

I don't well understand the issue here.

You got the exact same result using the REST API than using the GraphQL.

I've tried to reproduce it with this basic schema:

Private:

{
  "connection": "default",
  "collectionName": "",
  "info": {
    "name": "private",
    "description": "Some private content"
  },
  "options": {
    "timestamps": true
  },
  "attributes": {
    "secret": {
      "type": "string"
    }
  }
}

Public:

{
  "connection": "default",
  "collectionName": "",
  "info": {
    "name": "public",
    "description": "Some public content"
  },
  "options": {
    "timestamps": true
  },
  "attributes": {
    "name": {
      "type": "string"
    },
    "private": {
      "model": "private"
    }
}

So, creating a 'private' object, and a 'public' object linked to it. Allowing permission for unauthenticated users to perform 'GET' only on '/public' endpoint.

Here is the result I get using the REST API:

url: http://192.168.99.100:1337/public
body: [
    {
        "_id": "5b801078f2160004e83b9bc4",
        "name": "Im a public created by someone",
        "createdAt": "2018-08-24T14:04:40.825Z",
        "updatedAt": "2018-08-24T14:04:41.884Z",
        "__v": 0,
        "id": "5b801078f2160004e83b9bc4",
        "private": {
            "_id": "5b801060f2160004e83b9bc3",
            "secret": "You should not see me",
            "createdAt": "2018-08-24T14:04:16.172Z",
            "updatedAt": "2018-08-24T14:04:17.241Z",
            "__v": 0,
            "id": "5b801060f2160004e83b9bc3"
        }
    }
]

And using GraphQL:

query {
  publics {
    _id
    name
    private {
      secret
    }
  }
}

======
{
  "data": {
    "publics": [
      {
        "_id": "5b801078f2160004e83b9bc4",
        "name": "Im a public created by someone",
        "private": {
          "secret": "You should not see me"
        }
      }
    ]
  }
}

So, the problem does not seem to come from the GraphQL plugin, since the behavior are the same.
By default, the '.find' resolver seem to make a deeply fetch of all associations without taking account of the policies for the subrelational documents.

However, it is true that it would be great to have 'fine' permissions system.
Maybe adding a new .findNarrow controller who only retrieve first level for a given object. And another .findDeep who will perform as actual .find by making a deep fetch but also checking the policies for each associated object could do the trick (and could be implemented into a plugin without breaking change).

[Aurelsicoko]

See #2161

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/privacy-issue-with-graphql-users-permissions-plugin/3212/1

[JuanGrauGGG]

I guess this issue should be reopened
Dynamic zone's components private attributes are leaked.
#9804 (comment)