Different introspection queries can be used to query the API, these would return the desired outcome. Often, introspection is left enabled within environments, both in live and pre-production and queries can be executed without authentication.
Impact
The impact of introspection ranges from a low risk all the way to a critical vulnerability depending on other factors, such as the presence of other vulnerabilities or misconfigurations.
Examples include allowing an unauthenticated attacker to query the schema through introspection, identifying a query which would allow them to view application user information, this could include sensitive information such as Personally Identifiable Information (PII) or possibly financial or medical data.
Another example could include the use of information exposed to identify mutations which would allow the attacker to modify, delete or create new data within the application.
This could easily have been mitigated by disabling introspection which would make it difficult for opportunistic attackers to exploit.
In some instances, graphical interfaces, such as GraphiQL can be found enabled on the server. Introspection does not necessarily rely on these graphical interfaces. While it provides an intuitive interface for an attacker to utilise, the output from an introspection query can be used with external tools which would provide additional features and functionality to allow the user to easily understand the structure of the application’s schema.
Mitigation
To protect against this vulnerability, it is recommended that Introspection and accompanying graphical interfaces are disabled in all externally accessible environments.
Securing only the live environment is not sufficient, this should also be done on pre-production environments that are accessible. Dedicated attackers may choose to target the pre-production environments as they are generally less secure compared to a production environment and may contain newer updates and features which may have vulnerabilities.
While some GraphQL implementations now offer disabling Introspection by default (such as Apollo and fastify-gql), it is recommended that clients confirm this or modify the configuration if required in their own implementation.
3. Verbose Error Messages
Verbose error messages can be a very useful tool when targeting applications. Their presence could direct the attacker to which technologies, frameworks and versions are in use.
Impact
This would allow them to narrow down the potential targets as well as help focus their efforts on specific things.
For example, if through introspection, an attacker identifies an unauthenticated query or mutation, a verbose error message containing SQL information could disclose the database technology used as well as information about the tables and fields. Such information could allow the attacker to create the necessary queries to exfiltrate data.
Mitigation
To mitigate against this, the application must use generic error messages as opposed to detailed error messages containing the exact cause of the error or stack trace information. If detailed information is necessary for debug or support purposes, consider using unique identifiers and their corresponding values in internal log files. Also ensure debug more is disabled.
This would allow the developers to track the error messages without exposing the specific details to external users.
4. Injection Attacks
Generally, in web applications, lack of input sanitisation allows attackers to inject malicious payloads which would execute when processed or displayed in the web page. It is vital that all user input is considered untrusted and treated as such by ensuring the necessary sanitisation is carried out depending on the context before processing on the server to minimise these vulnerabilities. Client-side sanitisation is not sufficient as there are usually ways to circumvent them.
GraphQL applications are not immune to these types of vulnerabilities and remediation should be carried out to ensure that they are not left vulnerable.
Impact
A graphQL endpoint could be vulnerable to SQL Injection or Cross-Site Scripting. Just to name a few. This is based on how the application was built to handle user input. If no or insufficient user input sanitisation and other defensive coding strategies are used, an application could be vulnerable. Depending on the vulnerability present, an attacker may be able to read or modify data from the database or execute malicious JavaScript payloads.
Mitigation
Mitigating against this requires consistent input validation, sanitisation and encoding to ensure all user input is considered untrusted and is dealt with according to the context.
5. Access Control
Modern dynamic applications allow users to input and store user data. This is done through GraphQL using mutations. Mutations are queries that modify the data and carry out CRUD operations. (adding new, modifying or deleting existing objects)
This is where introspection is very useful to an attacker as it will provide them with information about the possible mutations and the fields required as well as any properties/fields which can be modified without being intended to. (An attacker could create their own mutations which would bypass the intended actions.)
Impact
This manifests in a number of ways, the first being the API does not adequately check the user authorisation before allowing them to access or modify data. This would compromise the confidentiality and integrity and availability of the data. This depends on the endpoint in question and the data it exposes.
Another example of this is when authorisation checks are not implemented and allow a lower privileged user to access functionality which should only be accessible to users with a higher role/privilege or administrators. This would allow users to potentially compromise the data and, in some cases, compromise the entire application and beyond.
Mitigation
These vulnerabilities could easily be mitigated using secure development practices as well as regular penetration testing to ensure that the mechanisms in place are sufficient and working as expected. Additional testing is recommended when new functionality is implemented or when major code changes are undertaken.
6. DoS & Batching Attacks
Denial of Service
DoS attacks may be possible within the API if the application does not protect against them. This is usually done when the application allows users to create queries which result in generating large responses (content of through intensive server-side processes/actions). This could result in the server resource exhaustion and denial of service.
Such an attack would impact the availability of the application and may also result in financial repercussions.
Impact
Denial of Service vulnerabilities can have a significant impact on the availability of an application. This could translate to negative financial or user experience to the organisation.
Mitigation
The impact of this vulnerability could be mitigated by following general security best practices such as implementing rate limiting and a limit on the query size. And in the specific case of GraphQL best practice, limiting the query depth to prevent Denial of Service.
Batching Attacks
Batching refers to executing multiple queries with a single request. In GraphQL this can be done by sending multiple queries in the same request as shown below:
