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
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…
