From a0e40e1653d9bdc7dce2966dca2c4252ea8d706b Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 1 Feb 2023 14:03:27 -0700 Subject: [PATCH 01/28] Update 4-graphql.livemd Added GraphQL security content --- modules/4-graphql.livemd | 139 +++++++++++++++++++++++++++++---------- 1 file changed, 105 insertions(+), 34 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index f7cb599..a7f67f2 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -2,89 +2,160 @@ ## Introduction -> ### 🛠 MODULE UNDER CONSTRUCTION - Please move to next module +GraphQL is a query language used to interact with and retrieve data from an application's data sources. It's structure is desinged for flexible and precise queries that efficiently interact with complex, highly nested data sets. Using GraphQL, information is retreived 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. GraphQL can be implemented as a component of an application's API and has two main security considerations: -*TODO: Write Introduction* +* Security concerns common to all APIs +* Security related to characteristics of the query language itself + +This module will highlight several security issues associated with GraphQL and recommendations for how to address. ## Table of Contents * [Disabling Introspection](#disabling-introspection) * [Error Disclosure](#error-disclosure) -* [Resource Exhaustion](#resource-disclosure) - * [Cost Theory](#cost-theory) +* [Resource Exhaustion](#resource-exhaustion) ## 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/dataset, query parameters, and types of objects in the data source, all of which 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 that includes information about table names, fields, database, structure etc. https://en.wikipedia.org/wiki/Database_schema + +This information can help a malicious actor in their information gathering/reconnaissnce efforts as they look for ways to attack your application and construct malicious queries and requests to compromise data. ### Prevention -*TODO: Write Prevention* +Best practice per OWASP is to limit access, including following least privilege, to introspection queries if it is not possible completely disable it. Please see references for more details. -### Example / Quiz +### References +https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL -*TODO: Make Example or Quiz Question* +https://cybervelia.com/?p=736 -```elixir +### Example / Quiz +``` +Which of the OWASP API Security Top 10 2019 issues does disabling introspection queries address? +a) API6:2019 Mass Assignment +b) API10:2019 Insufficient Logging & Monitoring +c) API3:2019 Excessive Data Exposure +d) API4:2019 Lack of Resources & Rate Limiting ``` ## Error Disclosure ### Description -*TODO: Write Description* +One of OWASP’s top 10 security risksfor API’s is API7:2019 Security Misconfiguration includes verbose error messages that can unintentionally provide information to help a malicious actor craft an attack on an application or otherwise exploit the api. It is a best practice to limit the amount of valuable/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 if triggered by a malicious actor, 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 and boring. ### Example / Quiz -*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 +https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa7-security-misconfiguration.md + +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* +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 it's functionality for all legitimate users and entities. + +Resource exhaustion occurs when memory, processes handling application requests, network traffic being generated, server capacity, and other host operating system, network, 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. + +Resource exhaustion can occur inadvertently through legitimate use or could be triggered intentionally in a ddos attacks by a maliciou acctor who send a large number or heavy requests to overload the application. ### Prevention -*TODO: Write Prevention* +Refer to the Rate Limiting Lesson in Part 3 - Secure SDLC Concepts ### Example / Quiz -*TODO: Make Example or Quiz Question* +The Elixir language has a built-in rate-limiter called Hammer (https://hexdocs.pm/hammer/frontpage.html). Some organizations chose to apply limits based on userId as in the example below. + +The check_rate function below takes 3 arguments: -```elixir +1. The first is what we've decided apply the limit to, in this case, the userID +2. The second, 60_000, represents the number of milliseconds in 1 minute (1000 milliseconds per 1 second, 60 seconds in 1 minute) +3. The last, 10, represents the number of times the userID can appear to have done a particular action before we stop them. In this case, 10 times. +``` +# limit file uploads to x per minute per user +userId = getUserId() +case Hammer.check_rate("action:#{userId}", 60_000, 10) do + {:allow, _count} -> + # let them do it + {:deny, _limit} -> + # nope +end ``` +### 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) -## Cost Theory - -### Description - -*TODO: Write Description* - -### Prevention - -*TODO: Write Prevention* - -### Example / Quiz - -*TODO: Make Example or Quiz Question* - -```elixir - -``` [**<- Previous Module: Secure SDLC Concepts**](./3-ssdlc.livemd) || [**Next Module: Elixir Security ->**](./5-elixir.livemd) From 5a65b9d9c2625a95c793bcbbc3fdef5c1c44d8f1 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 1 Feb 2023 14:09:58 -0700 Subject: [PATCH 02/28] Update 4-graphql.livemd fixed spelling errors --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index a7f67f2..9d64e15 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -2,7 +2,7 @@ ## Introduction -GraphQL is a query language used to interact with and retrieve data from an application's data sources. It's structure is desinged for flexible and precise queries that efficiently interact with complex, highly nested data sets. Using GraphQL, information is retreived 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. GraphQL can be implemented as a component of an application's API and has two main security considerations: +GraphQL is a query language used to interact with and retrieve data from an application's data sources. It's 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. GraphQL can be implemented as a component of an application's API and has two main security considerations: * Security concerns common to all APIs * Security related to characteristics of the query language itself From 68def492553f1994a2b3dce838acb5e70a6faa4c Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Fri, 3 Feb 2023 15:05:19 -0700 Subject: [PATCH 03/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 9d64e15..ba0c190 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -107,9 +107,8 @@ Date: Tues, 16 Aug 2022 21:06:42 GMT { ``` ### References -https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa7-security-misconfiguration.md - -https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL +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 From 16acc00b764478b509329ae24a09130618cf7a53 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Fri, 3 Feb 2023 15:06:14 -0700 Subject: [PATCH 04/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index ba0c190..dfcd47e 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -19,7 +19,9 @@ This module will highlight several security issues associated with GraphQL and r ### 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/dataset, query parameters, and types of objects in the data source, all of which 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 that includes information about table names, fields, database, structure etc. https://en.wikipedia.org/wiki/Database_schema +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 / dataset, query parameters, and types of objects in the data source, all of which 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. This information can help a malicious actor in their information gathering/reconnaissnce efforts as they look for ways to attack your application and construct malicious queries and requests to compromise data. From d56610d01afc9391675f3b273d05bf464a2a2c94 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 9 Feb 2023 09:29:36 -0700 Subject: [PATCH 05/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index dfcd47e..57d5e61 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -123,10 +123,23 @@ Resource exhaustion occurs when memory, processes handling application requests, Resource exhaustion can occur inadvertently through legitimate use or could be triggered intentionally in a ddos attacks by a maliciou acctor who send a large number or heavy requests to overload the application. +The structure of GraphQL queries make it particularly succeptible to this type of attack. Servers that handle GraphQL requests originate from untrusted input; from client requests. Client requests are user/attacker controlled input (context unvalidated/unsanitized input) +Queries that take a long time to process/traverse data/retrieve data consume +Long operations + + ### Prevention Refer to the Rate Limiting Lesson in Part 3 - Secure SDLC Concepts +Input Validation and Sanitization. +Attack vector is a query that is not checked for size, depth, (OWASP issues -> ) Secure coding practice of validation all input. Parameterizing queries. +Implementing checks in your code for queries / operations that that perform resource exhaustive actions or calls. + +Example of code where input is validated and where it isn't: + + + ### Example / Quiz The Elixir language has a built-in rate-limiter called Hammer (https://hexdocs.pm/hammer/frontpage.html). Some organizations chose to apply limits based on userId as in the example below. From 3d1bff7ebabdd3de76ec5dcbd8d16a2941bd762b Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 9 Feb 2023 12:44:31 -0700 Subject: [PATCH 06/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 57d5e61..6d89899 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -14,6 +14,7 @@ This module will highlight several security issues associated with GraphQL and r * [Disabling Introspection](#disabling-introspection) * [Error Disclosure](#error-disclosure) * [Resource Exhaustion](#resource-exhaustion) +* [Cost Theory](#cost-theory) ## Disabling Introspection @@ -126,6 +127,7 @@ Resource exhaustion can occur inadvertently through legitimate use or could be t The structure of GraphQL queries make it particularly succeptible to this type of attack. Servers that handle GraphQL requests originate from untrusted input; from client requests. Client requests are user/attacker controlled input (context unvalidated/unsanitized input) Queries that take a long time to process/traverse data/retrieve data consume Long operations +In addition to sanizatizing input - consider ways to measure the cost of a query. Next section covers one approach. ### Prevention @@ -136,30 +138,27 @@ Input Validation and Sanitization. Attack vector is a query that is not checked for size, depth, (OWASP issues -> ) Secure coding practice of validation all input. Parameterizing queries. Implementing checks in your code for queries / operations that that perform resource exhaustive actions or calls. -Example of code where input is validated and where it isn't: ### Example / Quiz +Example of code where input is validated and where it isn't: -The Elixir language has a built-in rate-limiter called Hammer (https://hexdocs.pm/hammer/frontpage.html). Some organizations chose to apply limits based on userId as in the example below. -The check_rate function below takes 3 arguments: + -1. The first is what we've decided apply the limit to, in this case, the userID -2. The second, 60_000, represents the number of milliseconds in 1 minute (1000 milliseconds per 1 second, 60 seconds in 1 minute) -3. The last, 10, represents the number of times the userID can appear to have done a particular action before we stop them. In this case, 10 times. +## Cost Theory -``` -# limit file uploads to x per minute per user -userId = getUserId() -case Hammer.check_rate("action:#{userId}", 60_000, 10) do - {:allow, _count} -> - # let them do it - {:deny, _limit} -> - # nope -end -``` +### Description + +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 + +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. + +More details of this approach are described in the reference below. + +### References +https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity ### GraphQl References https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html From f32178721064866c6ac35db1e98d49769f695940 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 9 Feb 2023 15:04:04 -0700 Subject: [PATCH 07/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 6d89899..76aec0e 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -127,7 +127,7 @@ Resource exhaustion can occur inadvertently through legitimate use or could be t The structure of GraphQL queries make it particularly succeptible to this type of attack. Servers that handle GraphQL requests originate from untrusted input; from client requests. Client requests are user/attacker controlled input (context unvalidated/unsanitized input) Queries that take a long time to process/traverse data/retrieve data consume Long operations -In addition to sanizatizing input - consider ways to measure the cost of a query. Next section covers one approach. +In addition to sanizatizing input - consider ways to measure the cost of a query and based on known available resources, reduce the risk of resource exhaustion due to expensive queries. Next section covers one approach. ### Prevention @@ -151,9 +151,10 @@ Example of code where input is validated and where it isn't: ### 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 useless. 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 -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. +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. Budgeting / allowance. More details of this approach are described in the reference below. From f9387d86193bdb34cb99eb9a84d6e37177882e7a Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Fri, 10 Feb 2023 11:14:09 -0700 Subject: [PATCH 08/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 76aec0e..3b71d94 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -26,6 +26,9 @@ If you are familiar with databases, this is similar to gathering info on the [da This information can help a malicious actor in their information gathering/reconnaissnce efforts 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 API Security Top 2019 and API's with this issue return too much and/or sensitive information in response to incoming requests. Since introspection provides this option for GraphQL as a feature, and that is dual use, has a useful purpose for developers, etc. but can be leveraged by malicious users, introspection can serve as an attack vector. + + ### Prevention Best practice per OWASP is to limit access, including following least privilege, to introspection queries if it is not possible completely disable it. Please see references for more details. @@ -35,14 +38,19 @@ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Applicatio https://cybervelia.com/?p=736 -### Example / Quiz +### Quiz + +**Which of the OWASP API Security Top 10 2019 issues does disabling introspection queries address?** + +*Uncomment the line with your answer.* ``` -Which of the OWASP API Security Top 10 2019 issues does disabling introspection queries address? -a) API6:2019 Mass Assignment -b) API10:2019 Insufficient Logging & Monitoring -c) API3:2019 Excessive Data Exposure -d) API4:2019 Lack of Resources & Rate Limiting +# 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 From 8433a92aab24727d224dea2b1103474e3b60a085 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Fri, 10 Feb 2023 15:16:25 -0700 Subject: [PATCH 09/28] Update 4-graphql.livemd Section is complete and ready for review. --- modules/4-graphql.livemd | 58 +++++++++++++--------------------------- 1 file changed, 18 insertions(+), 40 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 3b71d94..4061d65 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -2,12 +2,9 @@ ## Introduction -GraphQL is a query language used to interact with and retrieve data from an application's data sources. It's 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. GraphQL can be implemented as a component of an application's API and has two main security considerations: +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. -* Security concerns common to all APIs -* Security related to characteristics of the query language itself - -This module will highlight several security issues associated with GraphQL and recommendations for how to address. +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 @@ -20,18 +17,17 @@ This module will highlight several security issues associated with GraphQL and r ### 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 / dataset, query parameters, and types of objects in the data source, all of which can help a user, including a malicious one, deduce and discover specifics about the data being stored. +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. -This information can help a malicious actor in their information gathering/reconnaissnce efforts 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 API Security Top 2019 and API's with this issue return too much and/or sensitive information in response to incoming requests. Since introspection provides this option for GraphQL as a feature, and that is dual use, has a useful purpose for developers, etc. but can be leveraged by malicious users, introspection can serve as an attack vector. +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 -Best practice per OWASP is to limit access, including following least privilege, to introspection queries if it is not possible completely disable it. Please see references for more details. +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. ### References https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL @@ -57,14 +53,14 @@ IO.puts(answer) ### Description -One of OWASP’s top 10 security risksfor API’s is API7:2019 Security Misconfiguration includes verbose error messages that can unintentionally provide information to help a malicious actor craft an attack on an application or otherwise exploit the api. It is a best practice to limit the amount of valuable/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. +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 if triggered by a malicious actor, could be used to further an attack on the application. +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 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 and boring. +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. ### Example / Quiz @@ -126,43 +122,25 @@ Date: Tues, 16 Aug 2022 21:06:42 GMT ### Description -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 it's functionality for all legitimate users and entities. - -Resource exhaustion occurs when memory, processes handling application requests, network traffic being generated, server capacity, and other host operating system, network, 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. - -Resource exhaustion can occur inadvertently through legitimate use or could be triggered intentionally in a ddos attacks by a maliciou acctor who send a large number or heavy requests to overload the application. - -The structure of GraphQL queries make it particularly succeptible to this type of attack. Servers that handle GraphQL requests originate from untrusted input; from client requests. Client requests are user/attacker controlled input (context unvalidated/unsanitized input) -Queries that take a long time to process/traverse data/retrieve data consume -Long operations -In addition to sanizatizing input - consider ways to measure the cost of a query and based on known available resources, reduce the risk of resource exhaustion due to expensive queries. Next section covers one approach. - - -### Prevention +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. -Refer to the Rate Limiting Lesson in Part 3 - Secure SDLC Concepts +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. -Input Validation and Sanitization. -Attack vector is a query that is not checked for size, depth, (OWASP issues -> ) Secure coding practice of validation all input. Parameterizing queries. -Implementing checks in your code for queries / operations that that perform resource exhaustive actions or calls. +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. - - -### Example / Quiz -Example of code where input is validated and where it isn't: - - - +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 -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 useless. -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 +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. + +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. -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. Budgeting / allowance. +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. More details of this approach are described in the reference below. From e8bc4f94bd827d384a1f1ddd7c01db346b57dacf Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:21:37 -0700 Subject: [PATCH 10/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 4061d65..7834185 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -30,9 +30,8 @@ Excessive Data Exposure is number 3 on OWASP's API Security Top 2019 and APIs wi 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. ### 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 +1. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL +2. https://cybervelia.com/?p=736 ### Quiz From 4eada39c8f3f01ed70471eb89a828a4d3656d06a Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:21:55 -0700 Subject: [PATCH 11/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 7834185..781bd37 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -29,7 +29,7 @@ Excessive Data Exposure is number 3 on OWASP's API Security Top 2019 and APIs wi 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. -### References +### Resources 1. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL 2. https://cybervelia.com/?p=736 From 3efe07918d1973e3e7ceef33a91aca126e352c63 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:25:38 -0700 Subject: [PATCH 12/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 781bd37..2450798 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -52,7 +52,7 @@ IO.puts(answer) ### 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. +When an application responds with overly verbose error messages, it runs the risk of providing vital information to an attacker seeking to exploit the service. 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. From c8a6913e0f45fbed14c36d3bf18abf859135de5f Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:26:15 -0700 Subject: [PATCH 13/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 2450798..31351c9 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -58,8 +58,9 @@ Within the context of a GraphQL implementation, when errors occur, the server co ### 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. +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! + +OWASP recommends explicitly defining and enforcing all API response payload schemas including error messages; one might be able to accomplish this in an Elixir GraphQL context through the use of [Absinthe.Middleware](https://hexdocs.pm/absinthe/Absinthe.Middleware.html). ### Example / Quiz From 8d63f661aeaecb47b398e89431091e87e72fdefb Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:27:57 -0700 Subject: [PATCH 14/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 31351c9..2efab59 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -130,7 +130,7 @@ Resource exhaustion can occur inadvertently through legitimate use or could be t 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. -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. +In addition to strategies like rate limiting to protect APIs in general, another approach to protecting 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 From 600ef1ae53ded41f7f45a9df089bd40399b7396b Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:28:33 -0700 Subject: [PATCH 15/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 2efab59..86b6abe 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -126,7 +126,7 @@ When building an application, it is necessary to manage the access and use of al 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. -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. +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. From 13698ffca09381f003bacf4fc4a2bf14f2a9718f Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:30:13 -0700 Subject: [PATCH 16/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 86b6abe..37a4a69 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -136,7 +136,7 @@ In addition to strategies like rate limiting to protect APIs in general, another ### 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. +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. 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. From 0f0f5178c0c1f7f57dad8e7947a30bd0871dd494 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:31:04 -0700 Subject: [PATCH 17/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 37a4a69..98d24df 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -140,7 +140,7 @@ Resource intensive queries, like those where a GraphQL query tries to traverse a 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. -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. +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. More details of this approach are described in the reference below. From 2e9ce51dd812f47d03fa977fb39f517f5f31468c Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:31:17 -0700 Subject: [PATCH 18/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 1 - 1 file changed, 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 98d24df..6f11c02 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -142,7 +142,6 @@ One approach for implementing validation on incoming queries to determine their 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. -More details of this approach are described in the reference below. ### References https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity From f516d7c81b863c9768dd4913066ec8941c38b590 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:31:30 -0700 Subject: [PATCH 19/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 6f11c02..c2f66f1 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -143,8 +143,8 @@ One approach for implementing validation on incoming queries to determine their 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. -### References -https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity +### Resources +1. https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity ### GraphQl References https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html From e32dfd8017f331b624edc7f5a8f19589b6643b6b Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Wed, 15 Feb 2023 07:32:02 -0700 Subject: [PATCH 20/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index c2f66f1..d311bf5 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -113,7 +113,7 @@ Date: Tues, 16 Aug 2022 21:06:42 GMT “error”:”/www/home/file.txt not found ” { ``` -### References +### Resources 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 From db651e5d65af184e53266ee40bcf1ac2b1deec77 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 08:59:20 -0700 Subject: [PATCH 21/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index d311bf5..ebeb7c4 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -27,11 +27,27 @@ Excessive Data Exposure is number 3 on OWASP's API Security Top 2019 and APIs wi ### 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. +The less an attacker can learn about your system or application, the more difficult (though not impossible given time and resources) it will be to identify vulnerablilities and craft exploits that could result in a successful compromise. + +Making a malicious actor work as hard as possible to achieve their objectives is a worthy effort and any opportunity to add a layer of difficulty (i.e. see defense in depth section in Module 3), where possible and appropriate is ideal. + +Imagine trying to gain entry into a + +building without having a map, floorplans, or a website or flashlight. That's good for building security, but makes for a more difficult time for an intruder to plan their entry/exit without getting seen or caught. + +One of the ways to do this for applications that use GraphQL is to limit access to , including following least privilege, to introspection queries if it is not possible to completely disable it. Please see references for more details. + +### Example + +Vigil is an elixir package [Vigil](https://github.com/podium/vigil)that when added to your application's dependencies, can intercept incoming GraphQL introspection requests and return an error/forbidden message to the client, instead of information about the schema. + +It can also intercept responses to ensure no schema data is being leaked in any error messages. + ### Resources 1. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL 2. https://cybervelia.com/?p=736 +3. https://github.com/podium/vigil ### Quiz From d5e8bbecc92688b5c22d7e74cff1459f42a1875f Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 09:48:25 -0700 Subject: [PATCH 22/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index ebeb7c4..6f353d9 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -29,13 +29,11 @@ Excessive Data Exposure is number 3 on OWASP's API Security Top 2019 and APIs wi The less an attacker can learn about your system or application, the more difficult (though not impossible given time and resources) it will be to identify vulnerablilities and craft exploits that could result in a successful compromise. -Making a malicious actor work as hard as possible to achieve their objectives is a worthy effort and any opportunity to add a layer of difficulty (i.e. see defense in depth section in Module 3), where possible and appropriate is ideal. +Taking every opportunity to add a layer of difficulty (see defense in depth section in Module 3) for malicious actors is one aspect of securing data and applications. -Imagine trying to gain entry into a +Imagine trying to surprise a friend who lives in another part of the country with a complete home makeover. You've never been to their place but imagine trying to make arrangements, in secret, without having a map to their city, a website with a street view, or floorplans. What if they live on the 30th floor of an apartment building, there's no street parking, and they have 4 large pets? -building without having a map, floorplans, or a website or flashlight. That's good for building security, but makes for a more difficult time for an intruder to plan their entry/exit without getting seen or caught. - -One of the ways to do this for applications that use GraphQL is to limit access to , including following least privilege, to introspection queries if it is not possible to completely disable it. Please see references for more details. +Since introspection queries provide the floorplans to your data, one step in making an attacker's job more difficult is to, if an evaluation of your application development processes determines it is not needed, disable introspection. If it is not possible to completely disable it, where possible, the next best defense is to limit access, by following least privilege. Please see references for more details. ### Example @@ -43,7 +41,6 @@ Vigil is an elixir package [Vigil](https://github.com/podium/vigil)that when add It can also intercept responses to ensure no schema data is being leaked in any error messages. - ### Resources 1. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL 2. https://cybervelia.com/?p=736 From e62580bdb7c9e7a07270405d540ae76372567047 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 09:59:07 -0700 Subject: [PATCH 23/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 6f353d9..be0a3af 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -37,7 +37,7 @@ Since introspection queries provide the floorplans to your data, one step in mak ### Example -Vigil is an elixir package [Vigil](https://github.com/podium/vigil)that when added to your application's dependencies, can intercept incoming GraphQL introspection requests and return an error/forbidden message to the client, instead of information about the schema. +[Vigil](https://github.com/podium/vigil) is an elixir package that when added to your application's dependencies, can intercept incoming GraphQL introspection requests and return an error/forbidden message to the client, instead of information about the schema. It can also intercept responses to ensure no schema data is being leaked in any error messages. From 3d4364db51f65025a177d1b10e6625e274bc265a Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 10:40:09 -0700 Subject: [PATCH 24/28] Update 4-graphql.livemd Updated disabling introspection section and added reference to Vigil --- modules/4-graphql.livemd | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index be0a3af..c7f325b 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -21,25 +21,25 @@ Introspection queries are a way of enumerating a particular GraphQL implementati 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. +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 expose and 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 -The less an attacker can learn about your system or application, the more difficult (though not impossible given time and resources) it will be to identify vulnerablilities and craft exploits that could result in a successful compromise. +The less an attacker can learn about your system or application, the more difficult (though, of course, not impossible given time and resources) it will be to identify vulnerablilities and craft exploits that could result in a successful compromise. Taking every opportunity to add a layer of difficulty (see defense in depth section in Module 3) for malicious actors is one aspect of securing data and applications. -Imagine trying to surprise a friend who lives in another part of the country with a complete home makeover. You've never been to their place but imagine trying to make arrangements, in secret, without having a map to their city, a website with a street view, or floorplans. What if they live on the 30th floor of an apartment building, there's no street parking, and they have 4 large pets? +Imagine trying to surprise a friend who lives in another part of the country with a complete home makeover. You've never been to their place but imagine trying to make arrangements, in secret, without having a map to their city, knowing their address, having access to a website with a street view, or having the floorplans. What if they live on the 30th floor of an apartment building, there's no street parking, and they have 4 large pet dragons? -Since introspection queries provide the floorplans to your data, one step in making an attacker's job more difficult is to, if an evaluation of your application development processes determines it is not needed, disable introspection. If it is not possible to completely disable it, where possible, the next best defense is to limit access, by following least privilege. Please see references for more details. +Since introspection queries provide the floorplans to your data, one step in making an attacker's job more difficult is to, if an evaluation of your application development processes determines it is not needed, disable introspection. If it is not possible to completely disable introspection, the next best defense is to limit access, by following least privilege, or implement other contols to limit exposure. Please see references for more details. ### Example [Vigil](https://github.com/podium/vigil) is an elixir package that when added to your application's dependencies, can intercept incoming GraphQL introspection requests and return an error/forbidden message to the client, instead of information about the schema. -It can also intercept responses to ensure no schema data is being leaked in any error messages. +It can also intercept responses to ensure no schema data is being leaked in any error messages shown to the client. ### Resources 1. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL From 10fa0ed5d33a4d6bba64b6c556a3f23b0f6d9cb9 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 10:41:57 -0700 Subject: [PATCH 25/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index c7f325b..f748f7e 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -33,7 +33,7 @@ Taking every opportunity to add a layer of difficulty (see defense in depth sect Imagine trying to surprise a friend who lives in another part of the country with a complete home makeover. You've never been to their place but imagine trying to make arrangements, in secret, without having a map to their city, knowing their address, having access to a website with a street view, or having the floorplans. What if they live on the 30th floor of an apartment building, there's no street parking, and they have 4 large pet dragons? -Since introspection queries provide the floorplans to your data, one step in making an attacker's job more difficult is to, if an evaluation of your application development processes determines it is not needed, disable introspection. If it is not possible to completely disable introspection, the next best defense is to limit access, by following least privilege, or implement other contols to limit exposure. Please see references for more details. +Since introspection queries provide the floorplans to your data, one step in making an attacker's job more difficult is to, if an evaluation of your application development processes determines it is not needed, disable introspection. If it is not possible to completely disable introspection, the next best defense is to limit access, by following least privilege, or implement other controls to limit exposure. Please see references for more details. ### Example From 797daac10a02e12aa626c7e35b5578a4181a9293 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 10:55:43 -0700 Subject: [PATCH 26/28] Update modules/4-graphql.livemd Co-authored-by: Holden Oullette <6202965+houllette@users.noreply.github.com> --- modules/4-graphql.livemd | 8 -------- 1 file changed, 8 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index f748f7e..d0e11be 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -159,14 +159,6 @@ This approach also helps implement rate limiting by establishing a query cost ba ### Resources 1. https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity -### 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) From 962435124eff38f93d97f7f4394b045695c9f901 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 10:57:09 -0700 Subject: [PATCH 27/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index d0e11be..3b8c4f8 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -129,7 +129,7 @@ Date: Tues, 16 Aug 2022 21:06:42 GMT ### Resources 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 - +3. https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html ## Resource Exhaustion From 36be0d178db73ab15e30d8d4c0b7c611e0bb3811 Mon Sep 17 00:00:00 2001 From: hvalkerie19 <61711715+hvalkerie19@users.noreply.github.com> Date: Thu, 16 Feb 2023 11:32:30 -0700 Subject: [PATCH 28/28] Update 4-graphql.livemd --- modules/4-graphql.livemd | 97 +++++++++++++++++++++------------------- 1 file changed, 51 insertions(+), 46 deletions(-) diff --git a/modules/4-graphql.livemd b/modules/4-graphql.livemd index 3b8c4f8..0c6742a 100644 --- a/modules/4-graphql.livemd +++ b/modules/4-graphql.livemd @@ -75,56 +75,61 @@ Any errors disclosed from the server and displayed to the user should be limited OWASP recommends explicitly defining and enforcing all API response payload schemas including error messages; one might be able to accomplish this in an Elixir GraphQL context through the use of [Absinthe.Middleware](https://hexdocs.pm/absinthe/Absinthe.Middleware.html). -### Example / Quiz +### Quiz -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: +**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:** -1 - -``` -HTTP/2 401 Unauthorized -Date: Tues, 16 Aug 2022 21:06:42 GMT -… -{ - “error”:”token expired” -{ +*Uncomment the item number (1-4) with your answer* ``` +# ------------------------------------------------------------- +# answer = :1 +# +#HTTP/2 401 Unauthorized +#Date: Tues, 16 Aug 2022 21:06:42 GMT +#… +#{ +# “error”:”token expired” +#{ +# ------------------------------------------------------------- +# answer = :2 +# +#HTTP/2 200 OK +#Date: Tues, 16 Aug 2021 22:06:42 GMT +#… +#{ +# “errors”:[ +# { +# “locations”:[ +# { +# “column”:2, +# :line”:2 +# } +# ], +# “message”: “Parsing failed at +# } +# ] +#} +# -------------------------------------------------------------- +# answer = :3 +# +#HTTP/2 200 OK +#Date: Tues, 16 Aug 2022 21:06:42 GMT +#… +#{ +# “error”:”ID token for user 55e4cb07 at org 1234 expired” +#{ +# --------------------------------------------------------------- +# answer = :4 +# +#HTTP/2 404 File Not Found +#Date: Tues, 16 Aug 2022 21:06:42 GMT +#… +#{ +# “error”:”/www/home/file.txt not found ” +#{ +# --------------------------------------------------------------- -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 ” -{ +IO.puts(answer) ``` ### Resources 1. https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa7-security-misconfiguration.md