[Dailydave] Re: GraphQL

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