Test often and test completely. This is a mantra that developers have adopted throughout the history of code development. For some reason, however, this testing almost always occurs in isolated development and testing environments. The reality is that the real world is different, and you can’t always depend on the system to be trusted or well-constructed in production.

To resolve this, developers must fully understand what these vulnerabilities often look like and how they can be fixed, especially when working within newer paradigms like GraphQL.

Today, we’re going to look at a tool that helps deliver exactly that. Let’s take a look at DVGA!

What is DVGA?

The Damn Vulnerable GraphQL Application, or DVGA, is an intentionally broken version of GraphQL designed for users to attack a GraphQL application to find potential flaws and vulnerabilities. Many code failures occur in practical application, even when the underlying system seems just fine in testing.

Production is the proving ground for so many systems, but exposure at the production level is a huge problem. Discovering an issue or vulnerability before it goes live is the name of the game. DVGA is designed to help developers build an understanding of these common security issues with GraphQL so that they can develop a toolset outside of production.

DVGA supports Queries, Mutations, and Subscriptions and has a set of specific flaws that it documents in its GitHub repository. The full list of vulnerabilities is noted as follows:

• Reconnaissance
  • Discovering GraphQL
  • Fingerprinting GraphQL
• Denial of Service
  • Batch Query Attack
  • Deep Recursion Query Attack
  • Resource Intensive Query Attack
  • Field Duplication Attack
  • Aliases based Attack
• Information Disclosure
  • GraphQL Introspection
  • GraphiQL Interface
  • GraphQL Field Suggestions
  • Server Side Request Forgery
  • Stack Trace Errors
• Code Execution
  • OS Command Injection #1
  • OS Command Injection #2
• Injection
  • Stored Cross Site Scripting
  • Log spoofing / Log Injection
  • HTML Injection
  • SQL Injection
• Authorization Bypass
  • GraphQL JWT Token Forge
  • GraphQL Interface Protection Bypass
  • GraphQL Query Deny List Bypass
• Miscellaneous
  • GraphQL Query Weak Password Protection
  • Arbitrary File Write // Path Traversal

Broadly speaking, the Scenarios as collected by DVGA are sorted into five general categories: Denial of Service, Information Disclosure, Authorization Bypass, Code Execution, and Injection. Many of these flaws map directly to the OWASP API Security Top 10.

One of the most interesting parts of the DVGA approach is the gamification of these vulnerabilities. DVGA specifically implements a “Beginner” and “Expert” level of difficulty for vulnerability exploitation, allowing users to change the difficulty in execution and mirror more real-world applications.

Setting Up and Using Damn Vulnerable GraphQL Application

Before you can start using DVGA, you need to install a few libraries. Utilizing your install method, the following dependencies need to be in place:

• Python3 (3.6 – 3.9) (3.10 is not supported)
• Flask
• Flask-SQLAlchemy
• Flask-Sockets
• Gevent
• Graphene
• Graphene-SQLAlchemy
• Rx

From here, there are a few ways you can start using DVGA. The easiest way is to follow the steps in the DVGA readme by cloning the DVGA repository. From here, you can use a Docker file to build the image and run it locally.

To do this, you must first clone the repository:

git clone https://github.com/dolevf/Damn-Vulnerable-GraphQL-Application.git && cd Damn-Vulnerable-GraphQL-Application

Once the repository has been cloned, you must build the actual Docker image. To do this, simply issue a build command through the CLI:

docker build -t dvga .

Finally, create the container:

docker run -d -t -p 5013:5013 -e WEB_HOST=0.0.0.0 --name dvga dvga

With all of this in place, you can navigate to http://localhost:5013 to begin using DVGA. When you first use the service, you’ll be greeted with a sort of landing page:

From this landing page, you have a few different options for how to use DVGA. One of the most interesting immediate use cases is the Pastes sections. In DVGA, two kinds of Pastes can be worked with: Public and Private. This system is pretty close to something like PasteBin, allowing users to save pieces of code for public or private transformation and consumption.

From here, users can begin to use the tools at their disposal to attack the GraphQL instance. The first target will obviously be http://localhost:5013, the location of the DVGA instance — from here, additional targets can be discovered through introspection, tracing, fingerprinting, etc. How you actually attack this service will depend highly on your chosen stack: CLIs, GUIs, and even cloud applications can be used to test this service (assuming you make the instance publicly listenable).

Why Attack Locally?

The main benefit of this approach is to show what real-world threats actually look like. Again, the largest issue with developers handling GraphQL issues is that those issues often provide learning experiences only when the exposure is already significant. It’s a catch-22 in the sense that developers must experience failures to prevent failures, but without real-life examples of failures, they can’t prevent anything.

DVGA is a great, vulnerable system. It creates a threat vector that can be predicted, repeated, and tested. This work gives a sense of the process that can be used to find potential faults in production services.

The Value of DVGA and Challenge Systems

DVGA represents a particular kind of solution. It’s not necessarily a system for vulnerability detection but instead acts like an educational game. At its core, it’s a system that is a playground for adverse interactions with an API. This approach is an interesting one and is slowly becoming more common. It’s a practical example of theoretical threats.

It’s easy to downplay or even ignore potential vulnerabilities. This is a huge problem and a common cause of API exposures and breaches. The simple fact is that any system, no matter how well-developed, has the potential for extreme vulnerability. In many cases, this well-developed nature is a compounding problem! An API that has gone through 20 iterations may have more vulnerabilities than one that is brand new, but there may be an undercurrent of thought that the API has proven itself secure. This is literally a disaster scenario.

Solutions such as DVGA are key to breaking that mindset, as they expose how attacks are formed, executed, and iterated. Developers should assume from day one that their environment and code are rife with vulnerabilities and potential exposures. Testing in a secure environment only exacerbates the problem of trust, so adopting something like DVGA, where the system is already exposed and already broken, can help expose poor security assumptions on the developer side.

Conclusion

While the system is “fun” and gamified, it should be stated that it fulfills a literal dream scenario for many developers. In this environment, an API is put through the wringer in a place where nobody will take advantage of it. Why wouldn’t you want to battle-test your approach’s armor in a low-stakes scenario?

What do you think of DGA and this specific kind of tool? Do you see any use cases where DVGA might fall short? What other tools in this category do you think are notable? Let us know in the comments below, and we’ll take a look at it!