For many years GraphQL implementations have had massive issues with
access control/authorization and denial of service. This is a common
problem when you are essentially give a database prompt to the client.
GraphQL is better off on the back end only, IMO.
At OWASP we have an older cheatsheet on this topic that gets a lot of hits.
https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
If you have suggestions to make this better let me know!
Regards,
jim(a)manicode.com
>
>> On Mar 5, 2022, at 10:14 AM, Dave Aitel via Dailydave
>> <dailydave(a)lists.aitelfoundation.org> wrote:
>> One of the best ways to get more performance out of your networked
>> system is to trust the client more. This is always a bad idea from a
>> security perspective, as everyone on this list knows, but it's fun to
>> see it reincarnated a thousand times in different bodies.
>>
>> So for example if your web application has endless structured data
>> always changing and you're sick of writing REST APIs and middleware
>> you start thinking - what if instead, I had a flexible Javascript API
>> in the client that just grabbed data right from the database, and
>> that database did the user-authorization?
>>
>> Anyways, GraphQL is interesting and makes the hacker in me, and
>> probably all of you, hungry. In general, from a security perspective,
>> "Let the user talk directly to the database, but we FILTER it a bit"
>> is always a hilarious losing perspective, like trying to outswim a
>> shark, or having just one more drink of Goldschlager.
>>
>> Any filter or translation layer starts introducing protocol
>> desynchronization vulnerabilities, of course, but also you have to
>> worry about timing oracles, denial of service via resource
>> exhaustion, authorization mistakes, and a whole host of nightmares
>> that hackers at this point can pull out of endless old Bugtraq posts
>> whenever they feel like they need a conference talk at your expense.
>>
>> People often make the mistake of correlating "No plugin exists in
>> BURP for this attack surface" with "this new technology is more
>> secure than the last one!"
>>
>> What confuses me is when people deploy huge web applications based on
>> this sort of thing you would think they would at least ask the giant,
>> VC funded companies, "Which security team looked at and gave you a
>> review of this tech? What if the whole thing is a bad idea?" Like in
>> five years are we going to realize that you can't give users the
>> ability to run arbitrary regular expressions on your extremely
>> complicated database without so many checks and balances that it
>> ruins the whole point of having them connect to the database in the
>> first place? Yes, yes we are.
>>
>> On one hand, this is a sad state of affairs. On the other hand, who
>> are we without it? This failure is the upwelling current that brings
>> nutrients from the ocean floor to our arctic habitat. This is the
>> solar wind of quantum bits we float from planet to planet on. This is
>> the brief touch of a child's hand on the belly of the Buddha. This is
>> truth in the way that we know it.
>>
>> -dave
>> ----
>> Resources:
>>
https://blog.forcesunseen.com/a-primer-for-testing-the-security-of-graphql-…
>>
https://medium.com/csg-govtech/closing-the-loop-practical-attacks-and-defen…
>> _______________________________________________
>> Dailydave mailing list -- dailydave(a)lists.aitelfoundation.org
>> To unsubscribe send an email to dailydave-leave(a)lists.aitelfoundation.org