Restrict image transformations in GraphQL

[mihob]

Hey,

is it somehow possible to restrict image transformations in GraphQL queries? For example to predefined transformation?
I know i can disable the transform directive, but it is still possible to use the url property on assets to generate an image of any given size.

I find this a bit concerning since the GraphQL api is, after all, publicly available and so anyone can generate countless variants of the image.

Or am I missing something?

[andris-sevcenko]

It's a bit tricky. There are two approaches to take.

Limit by complexity
Use the maxGraphqlComplexiy config setting to limit the maximum allowed complexity for any GraphQL query.

The complexity values can be found here: https://github.com/craftcms/cms/blob/develop/src/services/Gql.php#L305-L326

This would leverage the fact that using the transform or handle arguments results in a significantly lower complexity value than using anything else.

Just remove transforms altogether
If you want to get rid of them altogether, you can listen to the defineGqlTypeField event and just remove all the arguments from width, height, url and any other fields that I'm forgetting that allow transforming assets.

Here's the documentation: https://github.com/craftcms/cms/blob/develop/src/gql/TypeManager.php#L32-L47

[andris-sevcenko]

Also, to clarify - the reason you can disable the transform directive but not regular transforms is that directives cannot be limited by complexity. By nature of GraphQL directives are applied after the query has been executed and complexity values in GraphQL can only be applied to the query.

[mihob]

Thank you for your reply.

Reducing the complixity would also potentially affect many other queries though, right?

Isn't the transform/url feature without constraint generally quite an attack vector? I mean, that would be an easy way to clog up the whole server with images.

[andris-sevcenko]

It is quite a viable vector, agreed, if the API is open.

Reducing the complexity would also potentially affect many other queries though, right?

That's why transforms that don't use a transform handle (and, therefore, could be randomized for an attack) yield such a high complexity value, compared to fields that are easier to resolve. For example, a query listing entries, three fields on each and also displaying the author's username would yield a complexity value of 39. Adding a single transform to that that uses the width parameter would bump it to 239.

I don't mean to say that the chosen values are perfect and I'm open to re-visiting them. I'm also not against having a setting that disables transforms in GraphQL API. However, it can currently be mitigated by either setting a complexity limit or pulling this off via events.

[mihob]

Okay, thank you!

[andris-sevcenko]

FTR, we'll think this through internally and I'm not dismissing the notion that we should tighten this one up a bit.

[mihob]

Hey,

I have a few more questions about calculating complexity.

I have a query on entries of a section that have different types. Each type has a few extra fields and a matrix field.

fragment blockA on matrix_blockA_BlockType {
  typeHandle
  title
}

fragment blockB on matrix_blockB_BlockType {
  typeHandle
  title
}

fragment matrixFragments on MatrixBlockInterface {
    ...blockA
    ...blockB
}    

{
    entries(section: "a"){
        ... on section_a_Entry{
            fieldA
            fieldB
            matrix{
                ...matrixFragments
            }
        }        
        ... on section_b_Entry{
            fieldC
            fieldD
            matrix{
                ...matrixFragments
            }
        } 
        ... on section_c_Entry{
            fieldE
            fieldF
            matrix{
                ...matrixFragments
            }
        }         
    }
}

This is a simplified example, in reality we have a few more fragments for the matrix. This results in a complexity well over 1000.

Somehow it looks like each fragment increases the complexity drastically.
Is that correct? The query doesn't actually get more complex than the most complex fragment, does it?

I noticed another problem. If __typename occurs in the query, the query is considered introsprection, which disables the complexity check. I think this results from this check in the GQL service:

$isIntrospectionQuery = StringHelper::containsAny($event->query, ['__schema', '__type']);

[andris-sevcenko]

@mihob I expect to circle back to the issue this week. Here's what I expect to do:

1. Improve the introspection check
2. Add some events that would expose the transforms that are expected to run. You'll be able then to check the list and prevent the query from running.

After digging a bit more into the entire complexity thing, it's possible that it still is a bit flawed (in the underlying framework) - I'll have to verify that.