From ae3a60cd8dfad858054fc928b179a8e2baec9a88 Mon Sep 17 00:00:00 2001 From: Dmitry Sotnikov Date: Mon, 23 Sep 2019 11:38:48 -0700 Subject: [PATCH] Add various prevention tips --- 2019/en/src/0xa3-excessive-data-exposure.md | 2 ++ 2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md | 3 +++ 2019/en/src/0xa5-broken-function-level-authorization.md | 2 +- 2019/en/src/0xa6-mass-assignment.md | 1 + 2019/en/src/0xa7-security-misconfiguration.md | 3 ++- 2019/en/src/0xa8-injection.md | 4 +++- 2019/en/src/0xa9-improper-assets-management.md | 3 +++ 2019/en/src/0xb0-next-devs.md | 3 ++- CONTRIBUTING.md | 2 +- 9 files changed, 18 insertions(+), 5 deletions(-) diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md index a41cfec1b..43896d471 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/2019/en/src/0xa3-excessive-data-exposure.md @@ -42,6 +42,8 @@ the site. * Never rely on the client side to perform sensitive data filtering. * Review the responses from the API to make sure they contain only legitimate data. +* Explicitly define and enforce data returned by all API methods including errors: give all JSON objects schemas, all string objects patterns, use clear field names. +* Define all sensitive and personally identifiable information (PII) that your application stores and works with and review all API calls returning such information to see if these responses can be a security issue. ## References diff --git a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md index e500c0247..fc03a2f19 100644 --- a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md @@ -49,11 +49,14 @@ errors. [file descriptors, and processes][4]. * Implement a limit on how often a client can call the API within a defined timeframe. +* For sensitive operations such as login or password reset, consider rate limits by API method (for example, authentication), client (for example, IP address), property (for example, username). * Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset. * Add proper server-side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response. +* Define and enforce maximum size of data on all incoming parameters and payloads such as maximum length for strings and maximum number of elements in arrays. +* If your API accepts zip files check compression ratios before expanding the files to protect yourself against "zip bombs". ## References diff --git a/2019/en/src/0xa5-broken-function-level-authorization.md b/2019/en/src/0xa5-broken-function-level-authorization.md index 2f5f729d0..d4ee7a7c0 100644 --- a/2019/en/src/0xa5-broken-function-level-authorization.md +++ b/2019/en/src/0xa5-broken-function-level-authorization.md @@ -4,7 +4,7 @@ A5:2019 Broken Function Level Authorization | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | | API Specific : Exploitability **3** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific | -| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to "admins"). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. | +| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to "admins", or changing the value of a parameter like "is_admin" from "false" to "true"). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. | ## Is the API Vulnerable? diff --git a/2019/en/src/0xa6-mass-assignment.md b/2019/en/src/0xa6-mass-assignment.md index be67cc502..d446f6e52 100644 --- a/2019/en/src/0xa6-mass-assignment.md +++ b/2019/en/src/0xa6-mass-assignment.md @@ -75,6 +75,7 @@ shell command injection once the attacker downloads the video as MP4. * Whitelist only the properties that should be updated by the client. * Use built-in features to blacklist properties that should not be accessed by clients. +* In API contracts, explicitly define and enforce schemas for all JSON payloads. ## References diff --git a/2019/en/src/0xa7-security-misconfiguration.md b/2019/en/src/0xa7-security-misconfiguration.md index 5e4a5be0c..8dedf8f20 100644 --- a/2019/en/src/0xa7-security-misconfiguration.md +++ b/2019/en/src/0xa7-security-misconfiguration.md @@ -4,7 +4,7 @@ A7:2019 Security Misconfiguration | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | | API Specific : Exploitability **3** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific | -| Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can no only expose sensitive user data, but also system details that may lead to full server compromise. | +| Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise. | ## Is the API Vulnerable? @@ -65,6 +65,7 @@ The API life cycle should include: assets (e.g., images). * An automated process to continuously assess the effectiveness of the configuration and settings in all environments. +* To prevent exception traces and other valuable information from being sent back to attackers, define and enforce all API response payload schemas including error responses. ## References diff --git a/2019/en/src/0xa8-injection.md b/2019/en/src/0xa8-injection.md index faa21f96f..580990b74 100644 --- a/2019/en/src/0xa8-injection.md +++ b/2019/en/src/0xa8-injection.md @@ -33,7 +33,7 @@ The attacker replays the request with a different payload ``` POST /api/account/recovery -{"email": "john@somehost.com';WAITFOR DELAY '0:0:5'--"} +{"username": "john@somehost.com';WAITFOR DELAY '0:0:5'--"} ``` This time, the response took ~5 seconds confirming the API is vulnerable to SQL @@ -103,6 +103,8 @@ Preventing injection requires keeping data separate from commands and queries. of injection. * Validate incoming data using sufficient filters to only allow valid values for each input parameter. +* To prevent data leaks, define and enforce schemas for all API responses. +* Define data types and strict patterns for all string parameters. ## References diff --git a/2019/en/src/0xa9-improper-assets-management.md b/2019/en/src/0xa9-improper-assets-management.md index 1939c464a..c879c2a96 100644 --- a/2019/en/src/0xa9-improper-assets-management.md +++ b/2019/en/src/0xa9-improper-assets-management.md @@ -61,6 +61,9 @@ user by using a simple brute-force to guess the 6 digits token. * Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline. * Make API documentation available to those authorized to use the API. +* Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version. +* Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones. +* When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version. ## References diff --git a/2019/en/src/0xb0-next-devs.md b/2019/en/src/0xb0-next-devs.md index 5f7ec193c..a12c9ebc4 100644 --- a/2019/en/src/0xb0-next-devs.md +++ b/2019/en/src/0xb0-next-devs.md @@ -15,7 +15,7 @@ comprehensive list of available projects. | | | |-|-| -| **Education** | You can start reading [OWASP Education Project materials][2] according to your profession and interest. For hands-on learning, we added **crAPI** - **C**ompletely **R**idiculous **API** on [our roadmap][3]. Meanwhile, you can practice WebAppSec using the [OWASP DevSlop Pixi Module][4], a vulnerable WebApp and API service intent to teach users how to test modern web applications and API's for security issues, and how to write more secure API's in the future. You can also attend [OWASP AppSec Conference][5] training sessions, or [join your local chapter][6]. | +| **Education** | You can start reading [OWASP Education Project materials][2] according to your profession and interest. For hands-on learning, we added **crAPI** - **C**ompletely **R**idiculous **API** on [our roadmap][3]. Meanwhile, you can practice WebAppSec using the [OWASP DevSlop Pixi Module][4], a vulnerable WebApp and API service intent to teach users how to test modern web applications and API's for security issues, and how to write more secure API's in the future. You can also attend [OWASP AppSec Conference][5] training sessions, or [join your local chapter][6]. Read about the latest API vulnerabilities and breaches at [APIsecurity.io][15]| | **Security Requirements** | Security should be part of every project from the beginning. When doing requirements elicitation, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][7] as a guide for setting the security requirements. If you're outsourcing, consider the [OWASP Secure Software Contract Annex][8], which should be adapted according to local law and regulations. | | **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Prevention Cheat Sheets][9] are a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][10] and the [REST Assessment Cheat Sheet][11]. | | **Standard Security Controls** | Adopting Standard Security Controls reduces the risk of introducing security weaknesses while writing your own logic. Despite the fact that many modern frameworks now come with built-in standard effective controls, [OWASP Proactive Controls][12] gives you a good overview of what security controls you should look to include in your project. OWASP also provides some libraries and tools you may find valuable, such as validation controls. | @@ -35,3 +35,4 @@ comprehensive list of available projects. [12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 [13]: https://www.owasp.org/index.php/OWASP_SAMM_Project [14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project +[15]: https://APIsecurity.io \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1394e6b3e..4e4c7c45a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -24,7 +24,7 @@ follow the steps below: 1. Fork this repository to your account 2. Clone your copy of this repository, locally ``` - git clone git@github.com:YOU/API-Security-Top-10.git + git clone https://github.com/YOU/API-Security.git ``` 3. Create a new branch based on `develop` (e.g. `fix/foreword-section`) ```