GraphQL Module

modules/4-graphql.livemd

@@ -2,89 +2,160 @@
 
 ## Introduction
 
-> ### 🛠 <span style="color:goldenrod;">MODULE UNDER CONSTRUCTION - Please move to next module</span>
+GraphQL is a query language used to interact with and retrieve data from an application's data sources. Its structure is designed for flexible and precise queries that efficiently interact with complex, highly nested data sets.  Using GraphQL, information is retrieved by stepping through data as if it were arranged as a group of connected nodes instead of a strictly hierarchical set up. Think more of a labyrinth than a tree.  
 
-*TODO: Write Introduction*
+Since GraphQL can be implemented as a component of an application's API, there are security issues common to all APIs present, as well as concerns related to characteristics of the query language itself.  This module will highlight several security issues associated with GraphQL and recommendations for how to address them.
 
 ## Table of Contents
 
 * [Disabling Introspection](#disabling-introspection)
 * [Error Disclosure](#error-disclosure)
-* [Resource Exhaustion](#resource-disclosure)
-  * [Cost Theory](#cost-theory)
+* [Resource Exhaustion](#resource-exhaustion)
+* [Cost Theory](#cost-theory)
 
 ## Disabling Introspection
 
 ### Description
 
-*TODO: Write Description*
+Introspection queries are a way of enumerating a particular GraphQL implementation to discover details about the queries supported, data types available, and other information. This includes mutation names, fields specific to an organization or dataset, query parameters, and types of objects in the data source.  Obtaining this information can help a user, including a malicious one, deduce and discover specifics about the data being stored. 
+
+If you are familiar with databases, this is similar to gathering info on the [database schema]( https://en.wikipedia.org/wiki/Database_schema) that includes information about table names, fields, database, structure etc.
+
+Malicious actors in their information gathering/reconnaissnce efforts can leverage this information as they look for ways to attack your application and construct malicious queries and requests to compromise data.
+
+Excessive Data Exposure is number 3 on OWASP's API Security Top 2019 and APIs with this issue return too much and/or sensitive information in response to incoming requests and queries.  Although it provides a useful function for GraphQL developers, the information returned by introspection can help facilitate attack. 
 
 ### Prevention
 
-*TODO: Write Prevention*
+Best practice per OWASP is to limit access, including following least privilege, to introspection queries if it is not possible to completely disable it. Please see references for more details.
 
-### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
+### References
+https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL
+
+https://cybervelia.com/?p=736
+
+### <span style="color:red;">Quiz</span>
+
+**Which of the OWASP API Security Top 10 2019 issues does disabling introspection queries address?**
 
-*TODO: Make Example or Quiz Question*
+*Uncomment the line with your answer.*
 
-```elixir
+```
+# answer = :API6_2019_Mass_Assignment
+# answer = :API10_2019_Insufficient_Logging_Monitoring
+# answer = :API3_2019_Excessive_Data_Exposure
+# answer = :API4_2019_Lack_of_Resources_Rate_Limiting
 
+IO.puts(answer)
 ```
 
 ## Error Disclosure
 
 ### Description
 
-*TODO: Write Description*
+Another one of OWASP’s top 10 security risks for API’s is API7:2019 Security Misconfiguration.  This issue includes api's that issue overly verbose error messages that can unintentionally provide information to help a malicious actor seeking to craft an attack on an application or otherwise exploit the api.  It is a best practice to limit the amount of meaningful information that gets sent back to any user in the event there is an issue with a service, or other application component, including APIs.
+
+Within the context of a GraphQL implementation, when errors occur, the server could send error messages that reveal internal details, application configurations, or data which could be used to further an attack on the application.   
 
 ### Prevention
 
-*TODO: Write Prevention*
+OWASP recommends explicitly defining and enforcing all API response payload schemas including error messages.
+Any errors disclosed from the server and displayed to the user should be limited.  Boring is good when it comes to error messages displayed to users.
 
 ### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
 
-*TODO: Make Example or Quiz Question*
+Select the best example of a “good” error message, from the perspective of developer who is writing code that is intended to inform a user (who may or may not be a malicious actor) that the action they have attempted was unsuccessful:
 
-```elixir
+1 - 
+```
+HTTP/2 401 Unauthorized
+Date: Tues, 16 Aug 2022 21:06:42 GMT
+…
+{
+	“error”:”token expired”
+{
+```
 
+2-
+```
+HTTP/2 200 OK
+Date: Tues, 16 Aug 2021 22:06:42 GMT
+…
+{
+	“errors”:[
+		{
+			“locations”:[
+			{
+				“column”:2,
+				:line”:2
+			}
+			],
+			“message”: “Parsing failed at 
+		}
+	]
+}
+```
+3-
+```
+HTTP/2 200 OK
+Date: Tues, 16 Aug 2022 21:06:42 GMT
+…
+{
+	“error”:”ID token for user 55e4cb07 at org 1234 expired”
+{
 ```
+4- 
+```
+HTTP/2 404 File Not Found
+Date: Tues, 16 Aug 2022 21:06:42 GMT
+…
+{
+	“error”:”/www/home/file.txt not found ”
+{
+```
+### References
+1. https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa7-security-misconfiguration.md
+2. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL
+
 
 ## Resource Exhaustion
 
 ### Description
 
-*TODO: Write Description*
-
-### Prevention
-
-*TODO: Write Prevention*
-
-### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
+When building an application, it is necessary to manage the access and use of all relevant internal and external resources involved in the context of the application.  This will help ensure the continued availablilty of the application and its functionality for all legitimate users and entities.
 
-*TODO: Make Example or Quiz Question*
+Resource exhaustion occurs when memory, processes handling application requests, network traffic transmissions, server capacity, storage, and other host operating system or device limitations are exceeded while an application is running.  When resource allocation is not well managed, applications become vulnerable to negative impacts in performance, unintentional service failures, and denial of service attacks, in which a malicious actor takes advantage of resource limitations to intentionally overwhelm and crash a system.  
 
-```elixir
+Resource exhaustion can occur inadvertently through legitimate use or could be triggered intentionally in a dos attack by a malicious actor who sends a large number or resource intensive requests to overload the application.  
 
-```
+The structure of GraphQL queries make it particularly succeptible to this type of attack as they can be crafted to perform long running and extensive operations, depending on the data being queried.
 
-<!-- livebook:{"branch_parent_index":4} -->
+In addition to strategies like implementing some form of rate limiting to protect APIs in general (see the section about rate limiting in the previous module), another approach to protect GraphQL from resource exhaustion involves anticipating the cost of a query and allocating resources based on known available capacity.  The next section introduces this approach.
 
 ## Cost Theory
 
 ### Description
 
-*TODO: Write Description*
+Resource intensive queries, like those where a Graphql query tries to traverse and then return a significant amount of highly nest data can cause a server/service to expend a significant amount of it's processing power and other resources.  These high cost queries can render a server and therefore the application useless.
 
-### Prevention
+One approach for implementing validation on incoming queries to determine their "cost" in terms of the resources the use.  Queries are defined by how much load they place on the server/service processing the request, allowing developers to plan for how best to manage resources.  This is a little like making a budget. 
 
-*TODO: Write Prevention*
+This approach also helps implement Rate limiting by establishing a query cost based on the type, operation, and expected performance of each unique GraphQL request for data, and by anticipating the load on the server.  
 
-### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
+More details of this approach are described in the reference below.
 
-*TODO: Make Example or Quiz Question*
+### References
+https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity
 
-```elixir
+### GraphQl References
+https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
+https://owasp.org/www-project-api-security/
+https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL
+https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
+https://owasp.org/www-project-api-security/  
+https://www.howtographql.com/advanced/4-security/
+(https://hexdocs.pm/hammer/tutorial.html)
+<!-- livebook:{"branch_parent_index":4} -->
 
-```
 
 [**<- Previous Module: Secure SDLC Concepts**](./3-ssdlc.livemd) || [**Next Module: Elixir Security ->**](./5-elixir.livemd)