Working with the latest tech is fun. It’s fresh and exciting. As developers we feel invigorated by being on the bleeding edge. Consider us thrill seekers. Thrills, however, shouldn’t come from 2am alerts resulting in the binge triaging of production security bugs found in that latest tech stack. Perhaps it’s the reason you’re here. Perhaps you believe, like we do, that bugs are best squashed before deploying to prod. StackHawk was built to help developers ship secure applications. Existing security testing tools do not work well with modern development paradigms. We’ve built functionality to ensure that modern developers can run security tests simply, including CI integrations, scanning REST API backed applications, and more. As we work to cover the modern application stack, we were well aware of the black hole for GraphQL security testing.We just released GraphQL scanning support to ensure that you can ship secure GraphQL APIs. But before we jump into the specifics of the solution and follow up with a demo, let’s do a quick overview of the GraphQL specification. This is a unique space with an interesting set of challenges. If you’re already well versed in GraphQL and the potential challenges posed by its current state of scan-ability, please feel free to skip ahead to How it Works for a demo and walkthrough. If you enjoy a little flavor and some additional back story then I welcome you to join me on a brief detour. Do you even Graph(QL)? Now unless your tech stack has been in a quarantine with the rest of us, you’ve probably seen GraphQL implementations in the wild. If your business is inline with, or already one of the reported in the , then you’re probably already building and deploying a in production today. 3,026 star adopters GraphQL Landscape GraphQL API Again, being at the forefront of change is always an exciting adventure, but have you taken time to ask yourself… How secure is my GraphQL API? If we take a look at some of the numbers, such as the report for Drupal customers or this survey on the , we get a sense of how this new specification continues gaining traction. GraphQL statistics most exciting API technologies A rising popularity of any new technology typically results in a rise in broken implementations. Considering most of these apps are likely to lack proper testing we suddenly have some serious concerns. While our craft remains the same despite new paradigms, the way in which we express ourselves through our systems will naturally have to be adjusted. This change presents a potential breeding ground for unchecked vulnerabilities on new and existing web apps. At StackHawk, we believe it is important to simplify and automate security testing for your applications. So… it’s like, graphs and stuff, right? Indeed. The specification on the surface defines an outline for representing and interfacing with your data… as a graph and stuff. At its core GraphQL works on the principle that data is interconnected and can be effectively represented as vertices on a graph. Most of us will be aware that this means two or more pairs of connected vertices, having one or more edges which may or may not come together to form forests, trees and leaves in a directed, acyclical or cyclical fashion, etc, ad infinitum… recursively, and on and on. This is all just to say that the designers of GraphQL have brilliantly outlined the capacity for engineers to represent data in pretty much any complex structure desired (or maybe not desired). Anything goes as long as the implementation is within the confines of the specification and meets a few key criteria. It’s the Wild West of the web! In fact, if you live in a quiet part of the city on dark summer evenings and draw the blinds, turn down the lights, and listen very carefully, you may just catch the sound of the faint grumblings emitted by backend engineers all over as they beg for mercy from the agony of rearchitecting their RESTful service into the promised land The Graph. Now, this is dangerously close to falling into some wretched and poorly written essay about graph theory and the GraphQL API, but that would never be nearly as informative as what’s already available at so let’s fast forward to what this all means for the security bottom-line. GraphQL Interest in Introspection One key feature of GraphQL that we at StackHawk, and your potential attacker no doubt, will employ in our endeavors to discover and audit routes is one of . introspection An introspection query allows a client to request a fully inclusive description of the API in a single query, which can contain all the definitions of types, fields, custom types, primitives, directives, subscriptions and other operations which we can query. HawkScan gathers this introspection data and quickly begins to determine available routes throughout the app. It then proceeds to generate queries which include fields and dependencies, expected input values, and available parameters to use as variable arguments. We provide the required input types, unwrapped custom types, scalars, enums, lists and so on and insert test values wherever possible. Along with this automatic discovery and generation of both query and mutation requests, we further provide the ability to tune the scanner with options such as making GET vs POST requests, setting recursion depth on introspection, and setting control over the method of how queries are generated. The latter being configurable for either batch form compost of all fields and types, or individual requests with each field and required type sent one-by-one. The Faces May Change, but Security Bugs Remain the Same is SQL Injection whether the route exists in a REST endpoint, an input form with sanitization missing, or a field query that takes an input parameter in GraphQL. Remote code injections are possible here, as they have been from the beginning of web applications, and they aren’t going away any time soon. SQL Injection Security through obscurity is not a viable practice. If you have GraphQL running in your ecosystem, we’ll help you ensure that you ship secure applications. Let’s see it in action! How it Works: Walk through with a Sample App Adding security testing to your GraphQL application is easy with StackHawk. Below are details of how to test it with our sample . This will also serve as an example of how you can set up StackHawk to scan your own app. vulnerable GraphQL application We begin by pulling down StackHawk’s vulnerable GraphQL project from Github. git ://github.com/stackhawk/vuln-graphql-api.git clone https Choose a listening port for the app and build the project with docker-compose: SERVER_PORT=3000
docker-compose up Once done, you’ll have a vulnerable GraphQL instance to attack. Now, let’s run theHawkScan, StackHawk’s security scanner . Log in to your (or sign up if you don’t have an account) and create a new application. StackHawk Account Make sure to provide the http://localhost and the selected port that reflects your setup: If you’ve run through StackHawk’s initial setup during account creation, you should already have a hawk.rc file saved in an accessible location. This contains the that links to your account. If this is missing, simply generate a new key in the Account UI and populate that file. HAWK_API_KEY After creating the new application, download the generated base file and place it in the source’s path. Then, go ahead and edit with your favorite editor (I’m not biased but ). stackhawk.yml Inside we’ll add two new lines under the app portion of the yaml: app: graphQL: true graphQLConf: # Optional schemaPath: /graphql With that, we’re ready to scan. Initiate the scan with the following: source ~/.hawk/hawk.rc docker run -e API_KEY=${HAWK_API_KEY} --rm -v $(pwd):/hawk:rw -it stackhawk/hawkscan:latest HawkScan updates the status and progress on the terminal while it runs. GraphQL focused scans will typically find a lot more routes, so expect some longer runtimes. Upon completion you’ll see the output of all discovered routes and alerts. We can see in the output of our scan that we’ve found two high severity bugs in this vulnerable GraphQL app. One for and another for SQL Injection Remote Code Execution. These are two nasty bugs that you hopefully will never see in your app. If you have StackHawk running tests on every PR, then you know these bugs will never see the light of prod. Back in the UI, our results are now available under the Applications view: Browse the findings and we can now grab the original request query and response and proceed to take action, accordingly. Let’s have a quick look at the alert. Remote OS Command Injection We find our GraphQL query present in the view: Request {"query":"mutation
 superSecretPrivateMutation($command:String ) { 
superSecretPrivateMutation(command:$command) { stdout stderr } 
}","variables":{"command":"KaaaKaww!&cat /etc/passwd&"}} And the response in the view: Response { :{ :{ : roo : : :roo /roo /bin/bash\nbin: : : :bin:/bin:/sbin/n
roo : : :roo /roo /bin/bash\nbin: : : :bin:/bin:/sbin/nologin\ndaemon: : : :daemon:/sbin:/sbin/nologin\nadm: : : :adm:/var/adm:/sbin/nologin\nlp: : : : :/var/spool/lpd:/sbin/nologin\nsync: : : : :/sbin:/bin/ \nshutdown: : : :shutdown:/sbin:/sbin/shutdown\nhal : : :hal /sbin:/sbin/halt\nmai : : :mai /var/spool/mai /sbin/nologin\noperator: : : :operator:/roo /sbin/nologin\ngame : : :game /usr/game /sbin/nologin\nftp: : : :FTP
 User:/var/ftp:/sbin/nologin\nnobody: : : :Kernel Overflow 
User:/:/sbin/nologin\ndbu : : :System message 
bu /:/sbin/nologin\nsystemd-coredump: : : :systemd Core 
Dumper:/:/sbin/nologin\nsystemd- : : : :systemd 
Resolver:/:/sbin/nologin\napp: : : ::/home/app:/bin/bash\n stderr /bin/ :
 KaaaKaww!: not found\n "data" "superSecretPrivateMutation" "stdout" " t:x 0 0 t: t: x 1 1 t:x 0 0 t: t: x 1 1 x 2 2 x 3 4 x 4 7 lp x 5 0 sync sync x 6 0 t:x 7 0 t: l:x 8 12 l: l: x 11 0 t: s:x 12 100 s: s: x 14 50 x 65534 65534 s:x 81 81 s: x 999 997 resolve x 193 193 x 1000 1000 "," ":" sh command "}}} This would be a frightening sight, indeed, if this had been a production bug! That concludes this week’s HawkTastic adventure, folks. And remember, make sure to always run StackHawk to help keep your web services fortified, healthy, happy, and most importantly, free of security bugs. Until next time, be sure to scan early and scan often! KAAKAWW! Previously published at https://www.stackhawk.com/blog/automated-graphql-security-testing/

Automate GraphQL Backed Applications' Security Testing

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Best Practices for Securing Your API

The Noonification: How AI/ChatGPT Dreams in 2022 (12/7/2022)

21 API Monitoring Tools That Will Make You a Developer Superhero in 2023!

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

9 Vital API Security Threats Every Team Should Watch For

A Comprehensive Guide to OpenAPI Specification

10 Best Practices for Securing Your API

The Noonification: How AI/ChatGPT Dreams in 2022 (12/7/2022)

21 API Monitoring Tools That Will Make You a Developer Superhero in 2023!

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

9 Vital API Security Threats Every Team Should Watch For

A Comprehensive Guide to OpenAPI Specification

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps