diff --git a/cheatsheets/Abuse_Case_Cheat_Sheet.md b/cheatsheets/Abuse_Case_Cheat_Sheet.md index 28197dc98d..83fbad23df 100644 --- a/cheatsheets/Abuse_Case_Cheat_Sheet.md +++ b/cheatsheets/Abuse_Case_Cheat_Sheet.md @@ -406,7 +406,7 @@ As an attacker, I perform stored XSS where the application or API stores unsanit As an attacker, I perform DOM XSS where JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page is vulnerable to DOM XSS. -### A8:2017-Insecure Deserialization +#### A8:2017-Insecure Deserialization *Epic:* @@ -416,7 +416,7 @@ Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits As an attacker, I find areas of the application and APIs where deserialization of hostile or tampered objects can be supplied. As a result, I can focus on an object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization. Or I focus on data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed. -### A9:2017-Using Components with Known Vulnerabilities +#### A9:2017-Using Components with Known Vulnerabilities *Epic:* @@ -426,7 +426,7 @@ While it is easy to find already-written exploits for many known vulnerabilities As an attacker, I find common open source or closed source packages with weaknesses and perform attacks against vulnerabilities and exploits which are disclosed -### A10:2017-Insufficient Logging & Monitoring +#### A10:2017-Insufficient Logging & Monitoring *Epic:* diff --git a/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md b/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md index c5568fff82..057b5df28e 100644 --- a/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md +++ b/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md @@ -81,7 +81,7 @@ To generate HMAC CSRF tokens (with a session-dependent user value), the system m - **A session-dependent value that changes with each login session**. This value should only be valid for the entirety of the users authenticated session. Avoid using static values like the user's email or ID, as they are not secure ([1](https://stackoverflow.com/a/8656417) | [2](https://stackoverflow.com/a/30539335) | [3](https://security.stackexchange.com/a/22936)). It's worth noting that updating the CSRF token too frequently, such as for each request, is a misconception that assumes it adds substantial security while actually harming the user experience ([1](https://security.stackexchange.com/a/22936)). For example, you could choose one of the following session-dependent values: - The server-side session ID (e.g. [PHP](https://www.php.net/manual/en/function.session-start.php) or [ASP.NET]()). - A random value (e.g. UUID) within a JWT that changes every time a JWT is created. -- **A secret cryptographic key** Not to confuse with the random value from the naive implementation. This value is used to generate the HMAC hash. Ideally, store this key as an environment variable. +- **A secret cryptographic key** Not to be confused with the random value from the naive implementation. This value is used to generate the HMAC hash. Ideally, store this key as discussed in the [Cryptographic Storage page](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#key-storage). - **A random value for anti-collision purposes**. Generate a random value (preferably cryptographically random) to ensure that consecutive calls within the same second do not produce the same hash ([1](https://github.com/data-govt-nz/ckanext-security/issues/23#issuecomment-479752531)). **Should Timestamps be Included in CSRF Tokens for Expiration?** diff --git a/cheatsheets/Microservices_Security_Cheat_Sheet.md b/cheatsheets/Microservices_Security_Cheat_Sheet.md index 7a6a2e209f..a45fdcf332 100644 --- a/cheatsheets/Microservices_Security_Cheat_Sheet.md +++ b/cheatsheets/Microservices_Security_Cheat_Sheet.md @@ -2,7 +2,7 @@ ## Introduction -The microservice architecture is being increasingly used for designing and implementing application systems in both cloud-based and on-premise infrastructures, high-scale applications and services. There are many security challenges need to be addressed in the application design and implementation phases. The fundamental security requirements that have to be addressed during design phase are authentication and authorization. Therefore, it is vital for applications security architects to understand and properly use existing architecture patterns to implement authentication and authorization in microservices-based systems. The goal of this cheat sheet is to identify such patterns and to do recommendations for applications security architect on possible way to use it. +The microservice architecture is being increasingly used for designing and implementing application systems in both cloud-based and on-premise infrastructures, high-scale applications and services. There are many security challenges that need to be addressed in the application design and implementation phases. The fundamental security requirements that have to be addressed during design phase are authentication and authorization. Therefore, it is vital for applications security architects to understand and properly use existing architecture patterns to implement authentication and authorization in microservices-based systems. The goal of this cheat sheet is to identify such patterns and to do recommendations for applications security architects on possible ways to use them. ## Edge-level authorization @@ -90,7 +90,7 @@ To make fine-grained authorization decisions at the microservice level, a micros In this approach, the microservice extracts the external entity identity from the incoming request (e.g., by parsing the incoming access token), creates a data structure (e.g., JSON or self-signed JWT) with that context, and passes it on to an internal microservice. In this scenario, the recipient microservice has to trust the calling microservice. If the calling microservice wants to violate access control rules, it can do so by setting any user/client ID or user roles it wants in the HTTP header. This approach is suitable only in highly trusted environments where every microservice is developed by a trusted development team that applies secure software development practices. -#### Using a data structures signed by a trusted issuer +#### Using a data structure signed by a trusted issuer In this pattern, after the external request is authenticated by the authentication service at the edge layer, a data structure representing the external entity identity (e.g., containing user ID, user roles/groups, or permissions) is generated, signed, or encrypted by the trusted issuer and propagated to internal microservices. ![Signed ID propagation](../assets/Signed_ID_propogation.png) @@ -150,18 +150,19 @@ Logging services in microservice-based systems aim to meet the principles of acc High-level recommendations to logging subsystem architecture with its rationales are listed below. 1. Microservice shall not send log messages directly to the central logging subsystem using network communication. Microservice shall write its log message to a local log file: - - this allows to mitigate the threat of data loss due to logging service failure due to attack or in case of its flooding by legitimate microservice: in case of logging service outage, microservice will still write log messages to the local file (without data loss), after logging service recovery logs will be available to shipping; + - this allows to mitigate the threat of data loss due to logging service failure due to attack or in case of its flooding by legitimate microservice + - in case of logging service outage, microservice will still write log messages to the local file (without data loss), and after logging service recovery, logs will be available to shipping; 2. There shall be a dedicated component (logging agent) decoupled from the microservice. The logging agent shall collect log data on the microservice (read local log file) and send it to the central logging subsystem. Due to possible network latency issues, the logging agent shall be deployed on the same host (virtual or physical machine) with the microservice: - this allows mitigating the threat of data loss due to logging service failure due to attack or in case of its flooding by legitimate microservice - in case of logging agent failure, microservice still writes information to the log file, logging agent after recovery will read the file and send information to message broker; 3. A possible DoS attack on the central logging subsystem logging agent shall not use an asynchronous request/response pattern to send log messages. There shall be a message broker to implement the asynchronous connection between the logging agent and central logging service: - this allows to mitigate the threat of data loss due to logging service failure in case of its flooding by legitimate microservice - - in case of logging service outage, microservice will still write log messages to the local file (without data loss) after logging service recovery logs will be available to shipping; + - in case of logging service outage, microservice will still write log messages to the local file (without data loss), and after logging service recovery, logs will be available to shipping; 4. Logging agent and message broker shall use mutual authentication (e.g., based on TLS) to encrypt all transmitted data (log messages) and authenticate themselves: - - this allows mitigating threat: microservice spoofing, logging/transport system spoofing, network traffic injection, sniffing network traffic + - this allows mitigating threats such as: microservice spoofing, logging/transport system spoofing, network traffic injection, sniffing network traffic 5. Message broker shall enforce access control policy to mitigate unauthorized access and implement the principle of least privileges: - this allows mitigating the threat of microservice elevation of privileges -6. Logging agent shall filter/sanitize output log messages to sensitive data (e.g., PII, passwords, API keys) will never send to the central logging subsystem (data minimization principle). For a comprehensive overview of items that should be excluded from logging, please see the [OWASP Logging Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Logging_Cheat_Sheet.md#data-to-exclude). +6. Logging agent shall filter/sanitize output log messages to make sure that sensitive data (e.g., PII, passwords, API keys) is never sent to the central logging subsystem (data minimization principle). For a comprehensive overview of items that should be excluded from logging, please see the [OWASP Logging Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Logging_Cheat_Sheet.md#data-to-exclude). 7. Microservices shall generate a correlation ID that uniquely identifies every call chain and helps group log messages to investigate them. The logging agent shall include a correlation ID in every log message. 8. The logging agent shall periodically provide health and status data to indicate its availability or non-availability. 9. The logging agent shall publish log messages in a structured logs format (e.g., JSON, CSV). diff --git a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md index 29e9d0de29..b316334aad 100644 --- a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md +++ b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md @@ -255,7 +255,7 @@ Smartcards are credit-card size cards with a chip containing a digital certifica ### SMS Messages and Phone Calls -SMS messages or phone calls can be used to provide users with a single-use code that they must submit as an additional factor. +SMS messages or phone calls can be used to provide users with a single-use code that they must submit as an additional factor. Due to the risks posed by these methods, they should not be used to protect applications that hold Personally Identifiable Information (PII) or where there is financial risk. e.g. healthcare and banking. [NIST SP 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html) does not allow these factors for applications containing PII. #### Pros @@ -270,6 +270,8 @@ SMS messages or phone calls can be used to provide users with a single-use code - Susceptible to SIM swapping attacks. - SMS messages may be received on the same device the user is authenticating from. - Susceptible to phishing. +- SMS may be previewed when the device is locked. +- SMS may be read by malicious or insecure applications. ### Email diff --git a/cheatsheets/Transport_Layer_Security_Cheat_Sheet.md b/cheatsheets/Transport_Layer_Security_Cheat_Sheet.md index 4c03731847..19df4f4e2c 100644 --- a/cheatsheets/Transport_Layer_Security_Cheat_Sheet.md +++ b/cheatsheets/Transport_Layer_Security_Cheat_Sheet.md @@ -68,6 +68,7 @@ There are a number of online tools that can be used to quickly validate the conf - [ImmuniWeb](https://www.immuniweb.com/ssl/) - [Observatory by Mozilla](https://observatory.mozilla.org) - [Scanigma](https://scanigma.com) +- [Stellastra](https://stellastra.com/tls-cipher-suite-check) - [OWASP PurpleTeam](https://purpleteam-labs.com/) `cloud` Additionally, there are a number of offline tools that can be used: