4 ms·

When they have a GraphQL API with introspection enabled, it feels like discovering a pot of gold. This happens more often than you would expect, even without a

by kall 5y ago

When they have a GraphQL API with introspection enabled, it feels like discovering a pot of gold. This happens more often than you would expect, even without any auth sometimes. At that point you're basically developing with the same DX as internal developers. My theory is people just turn off the GraphiQL endpoint on their GraphQL server and think they have hidden the schema, not realizing any external tool can do the introspection. Either that or it's developers slipping a little something under the radar for other developers (same thing with source maps). Another tip: If the service in question has a mobile app, sniffing the traffic on that with a MITM proxy can yield more interesting results than a web app.

brazzledazzle 5y ago
Just be ready for mitm proxying on some mobile apps to be a bust if they use certificate pinning. I’m not aware of anything that can get you past that besides patching the app itself.
- jonatron 5y ago
  There's plenty of Frida scripts that can disable app certificate pinning
  - brazzledazzle 5y ago
    To be fair I’m sure that uses patching but I didn’t know about that tool and how easy it is to use. Thanks for another thing to put in the ol’ bag o’ tricks.
- buildfocus 5y ago
  https://httptoolkit.tech/blog/frida-certificate-pinning/ https://httptoolkit.tech/blog/frida-certificate-pinning/ has a good guide and Frida script that will disable certificate pinning automatically in most cases.
tshaddox 5y ago
I've always thought it's a bit silly have a publicly accessible GraphQL API but then turn off introspection. If the only thing you're relying on to prevent someone from knowing about a certain field is that none of your web client code currently requests that field, you're already in a pretty flimsy predicament. And even then, people could trivially check for common or expected field names, or even brute force a lot of short field names. If you really intend for your GraphQL API to be used only internally and from your official web client, and you consider any fields not currently requested in your web client to be highly sensitive, you should really turn off public access to the full GraphQL API and use something like GraphQL's persisted queries where your web client requests queries by an opaque unique identifier rather than the fully text of the query.
- slaymaker1907 5y ago
  So it's not only security through obscurity, it's very weak obscurity.
  - monocasa 5y ago
    Security through the obscurity of a wedding veil. Not only is it translucent, but your audience tends to have a better idea than they can directly see at the moment as to what it's hiding.
- kall 5y ago
  Well, the gist of the op article is kind of "they can't prevent you from using their internal API", so most services shouldn't try. I think there's still a difference between making people scan your entire frontend code/traffic to find all the edge cases and making them reverse engineer your auth/headers/cookies (hours of work) vs handing them database access after 2 minutes of work. But I appreciate it, and it might be engineers that know this (that preventing access is futile) leaving it on intentionally. I certainly have done that.
throwthere 5y ago
You may not even need introspection-- https://github.com/nikitastupin/clairvoyance https://github.com/nikitastupin/clairvoyance https://github.com/swisskyrepo/GraphQLmap https://github.com/swisskyrepo/GraphQLmap
trever123 5y ago
Some GraphQL APIs do this on purpose if the API is meant to be completely public and if they want to allow self discovery and documentation of things through introspection. Allows anyone to point their own instance of GraphiQL or GraphQL playground and the endpoint and find things out. We even include comments in the schema to help with this as another form of documentation.
pantsforbirds 5y ago
I saw a website that exposed the results of a very expensive paid Linkedin API + the enrichment they did to those results in their GraphQL endpoint. Seemed like an expensive oversite
- robk 5y ago
  Which site was that??
oyebenny 5y ago
I love you.

by kall 5y ago

brazzledazzle 5y ago

Just be ready for mitm proxying on some mobile apps to be a bust if they use certificate pinning. I’m not aware of anything that can get you past that besides patching the app itself.

jonatron 5y ago
There's plenty of Frida scripts that can disable app certificate pinning
- brazzledazzle 5y ago
  To be fair I’m sure that uses patching but I didn’t know about that tool and how easy it is to use. Thanks for another thing to put in the ol’ bag o’ tricks.
buildfocus 5y ago
https://httptoolkit.tech/blog/frida-certificate-pinning/ https://httptoolkit.tech/blog/frida-certificate-pinning/ has a good guide and Frida script that will disable certificate pinning automatically in most cases.

tshaddox 5y ago

I've always thought it's a bit silly have a publicly accessible GraphQL API but then turn off introspection. If the only thing you're relying on to prevent someone from knowing about a certain field is that none of your web client code currently requests that field, you're already in a pretty flimsy predicament. And even then, people could trivially check for common or expected field names, or even brute force a lot of short field names. If you really intend for your GraphQL API to be used only internally and from your official web client, and you consider any fields not currently requested in your web client to be highly sensitive, you should really turn off public access to the full GraphQL API and use something like GraphQL's persisted queries where your web client requests queries by an opaque unique identifier rather than the fully text of the query.

slaymaker1907 5y ago
So it's not only security through obscurity, it's very weak obscurity.
- monocasa 5y ago
  Security through the obscurity of a wedding veil. Not only is it translucent, but your audience tends to have a better idea than they can directly see at the moment as to what it's hiding.
kall 5y ago
Well, the gist of the op article is kind of "they can't prevent you from using their internal API", so most services shouldn't try. I think there's still a difference between making people scan your entire frontend code/traffic to find all the edge cases and making them reverse engineer your auth/headers/cookies (hours of work) vs handing them database access after 2 minutes of work. But I appreciate it, and it might be engineers that know this (that preventing access is futile) leaving it on intentionally. I certainly have done that.

throwthere 5y ago

You may not even need introspection-- https://github.com/nikitastupin/clairvoyance https://github.com/nikitastupin/clairvoyance https://github.com/swisskyrepo/GraphQLmap https://github.com/swisskyrepo/GraphQLmap

trever123 5y ago

Some GraphQL APIs do this on purpose if the API is meant to be completely public and if they want to allow self discovery and documentation of things through introspection. Allows anyone to point their own instance of GraphiQL or GraphQL playground and the endpoint and find things out. We even include comments in the schema to help with this as another form of documentation.

pantsforbirds 5y ago

I saw a website that exposed the results of a very expensive paid Linkedin API + the enrichment they did to those results in their GraphQL endpoint. Seemed like an expensive oversite

robk 5y ago
Which site was that??

oyebenny 5y ago

I love you.