diff --git a/cheatsheets/5.2 - Authentication_Cheat_Sheet.md b/cheatsheets/Authentication_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.2 - Authentication_Cheat_Sheet.md rename to cheatsheets/Authentication_Cheat_Sheet.md diff --git a/cheatsheets/5.1 - Authorization_Cheat_Sheet.md b/cheatsheets/Authorization_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.1 - Authorization_Cheat_Sheet.md rename to cheatsheets/Authorization_Cheat_Sheet.md index b833f4be93..95336c6bfd 100644 --- a/cheatsheets/5.1 - Authorization_Cheat_Sheet.md +++ b/cheatsheets/Authorization_Cheat_Sheet.md @@ -1,6 +1,6 @@ # Authorization Cheat Sheet -## Introduction 5.3.3, 5.12.2 +## Introduction Authorization may be defined as "the process of verifying that a requested action or service is approved for a specific entity" ([NIST](https://csrc.nist.gov/glossary/term/authorization)). Authorization is distinct from authentication which is the process of verifying an entity's identity. When designing and developing a software solution, it is important to keep these distinctions in mind. A user who has been authenticated (perhaps by providing a username and password) is often not authorized to access every resource and perform every action that is technically possible through a system. For example, a web app may have both regular users and admins, with the admins being able to perform actions the average user is not privileged to do so, even though they have been authenticated. Additionally, authentication is not always required for accessing resources; an unauthenticated user may be authorized to access certain public resources, such as an image or login page, or even an entire web app. @@ -14,7 +14,7 @@ Both entirely unauthenticated outsiders and authenticated (but not necessarily a ## Recommendations -### Enforce Least Privileges - 5.3.6 +### Enforce Least Privileges As a security concept, Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job. Although perhaps most commonly applied in system administration, this principle has relevance to the software developer as well. Least Privileges must be applied both horizontally and vertically. For example, even though both an accountant and sales representative may occupy the same level in an organization's hierarchy, both require access to different resources to perform their jobs. The accountant should likely not be granted access to a customer database and the sales representative should not be able to access payroll data. Similarly, the head of the sales department is likely to need more privileged access than their subordinates. @@ -27,7 +27,7 @@ Consider the following points and best practices: - After the app has been deployed, periodically review permissions in the system for "privilege creep"; that is, ensure the privileges of users in the current environment do not exceed those defined during the design phase (plus or minus any formally approved changes). - Remember, it is easier to grant users additional permissions rather than to take away some they previously enjoyed. Careful planning and implementation of Least Privileges early in the SDLC can help reduce the risk of needing to revoke permissions that are later deemed overly broad. -### Deny by Default - 5.1.8 +### Deny by Default Even when no access control rules are explicitly matched, the application cannot remain neutral when an entity is requesting access to a particular resource. The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access. Logic errors and other mistakes relating to access control may happen, especially when access requirements are complex; consequently, one should not rely entirely on explicitly defined rules for matching all possible requests. For security purposes an application should be configured to deny access by default. @@ -62,7 +62,7 @@ Misconfiguration (or complete lack of configuration) is another major area in wh - Do not rely on default configurations. - Test configuration. Do not just assume any configuration performed on a third-party component will work exactly as intended in your particular environment. Documentation can be misunderstood, vague, outdated, or simply inaccurate. -### Prefer Attribute and Relationship Based Access Control over RBAC - 5.1.9 +### Prefer Attribute and Relationship Based Access Control over RBAC In software engineering, two basic forms of access control are widely utilized: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). There is a third, more recent, model which has gained popularity: Relationship-Based Access Control (ReBAC). The decision between the models has significant implications for the entire SDLC and should be made as early as possible. @@ -106,11 +106,11 @@ The importance of securing static resources is often overlooked or at least over - Ensure any cloud based services used to store static resources are secured using the configuration options and tools provided by the vendor. Review the cloud provider's documentation (see guidance from [AWS](https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/), [Google Cloud](https://cloud.google.com/storage/docs/best-practices#security) and [Azure](https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations) for specific implementations details). - When possible, protect static resources using the same access control logic and mechanisms that are used to secure other application resources and functionality. -### Verify that Authorization Checks are Performed in the Right Location - 5.3.1 +### Verify that Authorization Checks are Performed in the Right Location Developers must never rely on client-side access control checks. While such checks may be permissible for improving the user experience, they should never be the decisive factor in granting or denying access to a resource; client-side logic is often easy to bypass. Access control checks must be performed server-side, at the gateway, or using serverless function (see [OWASP ASVS 4.0.3, V1.4.1 and V4.1.1](https://raw.githubusercontent.com/OWASP/ASVS/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf)) -### Exit Safely when Authorization Checks Fail 5.3.2 +### Exit Safely when Authorization Checks Fail Failed access control checks are a normal occurrence in a secured application; consequently, developers must plan for such failures and handle them securely. Improper handling of such failures can lead to the application being left in an unpredictable state ([CWE-280: Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html)). Specific recommendations include the following: @@ -118,7 +118,7 @@ Failed access control checks are a normal occurrence in a secured application; c - Centralize the logic for handling failed access control checks. - Verify the handling of exception and authorization failures. Ensure that such failures, no matter how unlikely, do not put the software into an unstable state that could lead to authorization bypass. -### Implement Appropriate Logging - 5.1.7 +### Implement Appropriate Logging Logging is one of the most important detective controls in application security; insufficient logging and monitoring is recognized as among the most critical security risks in [OWASP's Top Ten 2017](https://raw.githubusercontent.com/OWASP/Top10/master/2017/OWASP%20Top%2010-2017%20(en).pdf). Appropriate logs can not only detect malicious activity, but are also invaluable resources in post-incident investigations, can be used to troubleshoot access control and other security related problems, and are useful in security auditing. Though easy to overlook during the initial design and requirements phase, logging is an important component of wholistic application security and must be incorporated into all phases of the SDLC. Recommendations for logging include the following: diff --git a/cheatsheets/5.14 - C-Based_Toolchain_Hardening_Cheat_Sheet.md b/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.14 - C-Based_Toolchain_Hardening_Cheat_Sheet.md rename to cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.md diff --git a/cheatsheets/5.4.4 - Cross_Site_Scripting_Prevention_Cheat_Sheet.md b/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.4.4 - Cross_Site_Scripting_Prevention_Cheat_Sheet.md rename to cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md diff --git a/cheatsheets/5.10 - Database_Security_Cheat_Sheet.md b/cheatsheets/Database_Security_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.10 - Database_Security_Cheat_Sheet.md rename to cheatsheets/Database_Security_Cheat_Sheet.md index e02592dbc8..8eee773552 100644 --- a/cheatsheets/5.10 - Database_Security_Cheat_Sheet.md +++ b/cheatsheets/Database_Security_Cheat_Sheet.md @@ -28,7 +28,7 @@ Most databases will allow unencrypted network connections in their default confi The [Transport Layer Protection](Transport_Layer_Protection_Cheat_Sheet.md) and [TLS Cipher String](TLS_Cipher_String_Cheat_Sheet.md) Cheat Sheets contain further guidance on securely configuring TLS. -## Authentication - 5.10.5 +## Authentication The database should be configured to always require authentication, including connections from the local server. Database accounts should be: @@ -55,7 +55,7 @@ Database credentials should never be stored in the application source code, espe Where possible, these credentials should also be encrypted or otherwise protected using built-in functionality, such as the `web.config` encryption available in [ASP.NET](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connection-strings-and-configuration-files#encrypting-configuration-file-sections-using-protected-configuration). -## Permissions - 5.10.3 +## Permissions The permissions assigned to database user accounts should be based on the principle of least privilege (i.e, the accounts should only have the minimal permissions required for the application to function). This can be applied at a number of increasingly granular levels depending on the functionality available in the database. The following steps should be applicable to all environments: diff --git a/cheatsheets/5.5.2 - Deserialization_Cheat_Sheet.md b/cheatsheets/Deserialization_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.5.2 - Deserialization_Cheat_Sheet.md rename to cheatsheets/Deserialization_Cheat_Sheet.md diff --git a/cheatsheets/5.7 - Error_Handling_Cheat_Sheet.md b/cheatsheets/Error_Handling_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.7 - Error_Handling_Cheat_Sheet.md rename to cheatsheets/Error_Handling_Cheat_Sheet.md index fdf8fc65c3..47f53806a3 100644 --- a/cheatsheets/5.7 - Error_Handling_Cheat_Sheet.md +++ b/cheatsheets/Error_Handling_Cheat_Sheet.md @@ -52,7 +52,7 @@ in D:\app\index_new.php on line 188 The [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/) provides different techniques to obtain technical information from an application. -## Objective - 5.7.1 +## Objective The article shows how to configure a global error handler as part of your application's runtime configuration. In some cases, it may be more efficient to define this error handler as part of your code. The outcome being that when an unexpected error occurs then a generic response is returned by the application but the error details are logged server side for investigation, and not returned to the user. diff --git a/cheatsheets/5.11 - File_Upload_Cheat_Sheet.md b/cheatsheets/File_Upload_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.11 - File_Upload_Cheat_Sheet.md rename to cheatsheets/File_Upload_Cheat_Sheet.md index 78d0be03ca..c858f37e42 100644 --- a/cheatsheets/5.11 - File_Upload_Cheat_Sheet.md +++ b/cheatsheets/File_Upload_Cheat_Sheet.md @@ -23,7 +23,7 @@ In short, the following principles should be followed to reach a secure file upl In order to assess and know exactly what controls to implement, knowing what you're facing is essential to protect your assets. The following sections will hopefully showcase the risks accompanying the file upload functionality. -### Malicious Files - 5.11.1, 5.11.3 +### Malicious Files The attacker delivers a file for malicious intent, such as: @@ -95,7 +95,7 @@ In order to avoid the above mentioned threat, creating a **random string** as a - Restrict characters to an allowed subset specifically, such as alphanumeric characters, hyphen, spaces, and periods - If this is not possible, block-list dangerous characters that could endanger the framework and system that is storing and using the files. -### File Content Validation - 5.11.5 +### File Content Validation As mentioned in the [Public File Retrieval](#public-file-retrieval) section, file content can contain malicious, inappropriate, or illegal data. @@ -111,7 +111,7 @@ If there are enough resources, manual file review should be conducted in a sandb Adding some automation to the review could be helpful, which is a harsh process and should be well studied before its usage. Some services (_e.g._ Virus Total) provide APIs to scan files against well known malicious file hashes. Some frameworks can check and validate the raw content type and validating it against predefined file types, such as in [ASP.NET Drawing Library](https://docs.microsoft.com/en-us/dotnet/api/system.drawing.imaging.imageformat). Beware of data leakage threats and information gathering by public services. -### File Storage Location - 5.11.4 +### File Storage Location The location where the files should be stored must be chosen based on security and business requirements. The following points are set by security priority, and are inclusive: diff --git a/cheatsheets/5.9.1, 5.9.4, 5.9.5 - HTTP_Strict_Transport_Security_Cheat_Sheet.md b/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.9.1, 5.9.4, 5.9.5 - HTTP_Strict_Transport_Security_Cheat_Sheet.md rename to cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.md diff --git a/cheatsheets/5.13 - Infrastructure_as_Code_Security_Cheat_Sheet.md b/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.13 - Infrastructure_as_Code_Security_Cheat_Sheet.md rename to cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.md diff --git a/cheatsheets/5.10.1, 5.10.2 - Injection_Prevention_Cheat_Sheet.md b/cheatsheets/Injection_Prevention_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.10.1, 5.10.2 - Injection_Prevention_Cheat_Sheet.md rename to cheatsheets/Injection_Prevention_Cheat_Sheet.md diff --git a/cheatsheets/Input_Validation_Cheat_Sheet.md b/cheatsheets/Input_Validation_Cheat_Sheet.md index 75f7fd0757..5ca08d64bc 100644 --- a/cheatsheets/Input_Validation_Cheat_Sheet.md +++ b/cheatsheets/Input_Validation_Cheat_Sheet.md @@ -22,7 +22,7 @@ Input validation should be applied on both **syntactical** and **Semantic** leve It is always recommended to prevent attacks as early as possible in the processing of the user's (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. -## Implementing input validation - 5.5.1 +## Implementing input validation Input validation can be implemented using any programming technique that allows effective enforcement of syntactic and semantic correctness, for example: @@ -116,7 +116,7 @@ Some Allow list validators have also been predefined in various open source pack - [Apache Commons Validator](http://commons.apache.org/proper/commons-validator/) -## Client Side vs Server Side Validation - 5.1.2, 5.3.5, 5.5.3 +## Client Side vs Server Side Validation Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure that any input validation performed on the client is also performed on the server. diff --git a/cheatsheets/Kubernetes_Security_Cheat_Sheet.md b/cheatsheets/Kubernetes_Security_Cheat_Sheet.md index ea1709361f..bef687ed29 100644 --- a/cheatsheets/Kubernetes_Security_Cheat_Sheet.md +++ b/cheatsheets/Kubernetes_Security_Cheat_Sheet.md @@ -215,7 +215,7 @@ For more information, refer to Ensure your images (and any third-party tools you include) are up to date and utilizing the latest versions of their components. -## Kubernetes Security Best Practices: Deploy Phase - 5.13 +## Kubernetes Security Best Practices: Deploy Phase Kubernetes infrastructure should be configured securely prior to workloads being deployed. From a security perspective, you first need visibility into what you’re deploying – and how. Then you can identify and respond to security policy violations. At a minimum, you need to know: diff --git a/cheatsheets/Laravel_Cheat_Sheet.md b/cheatsheets/Laravel_Cheat_Sheet.md index 4e4821aa95..c2a85f5c93 100644 --- a/cheatsheets/Laravel_Cheat_Sheet.md +++ b/cheatsheets/Laravel_Cheat_Sheet.md @@ -277,7 +277,7 @@ For other information on XSS prevention that is not specific to Laravel, you may Unrestricted file upload attacks entail attackers uploading malicious files to compromise web applications. This section describes how to protect against such attacks while building Laravel applications. You may also refer the [File Upload Cheatsheet](File_Upload_Cheat_Sheet.md) to learn more. -### Always Validate File Type and Size - 5.11.2 +### Always Validate File Type and Size Always validate the file type (extension or MIME type) and file size to avoid storage DOS attacks and remote code execution: diff --git a/cheatsheets/Nodejs_Security_Cheat_Sheet.md b/cheatsheets/Nodejs_Security_Cheat_Sheet.md index 6e86a72bb4..59113c2386 100644 --- a/cheatsheets/Nodejs_Security_Cheat_Sheet.md +++ b/cheatsheets/Nodejs_Security_Cheat_Sheet.md @@ -265,7 +265,7 @@ app.use(function(req, res, next) { }); ``` -#### Take precautions against brute-forcing - 5.3.4 +#### Take precautions against brute-forcing [Brute-forcing](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#protect-against-automated-attacks ) is a common threat to all web applications. Attackers can use brute-forcing as a password guessing attack to obtain account passwords. Therefore, application developers should take precautions against brute-force attacks especially in login pages. Node.js has several modules available for this purpose. [Express-bouncer](https://libraries.io/npm/express-bouncer), [express-brute](https://libraries.io/npm/express-brute) and [rate-limiter](https://libraries.io/npm/rate-limiter) are just some examples. Based on your needs and requirements, you should choose one or more of these modules and use accordingly. [Express-bouncer](https://libraries.io/npm/express-bouncer) and [express-brute](https://libraries.io/npm/express-brute) modules work very similar and they both increase the delay with each failed request. They can both be arranged for a specific route. These modules can be used as follows: diff --git a/cheatsheets/5.12 - REST_Security_Cheat_Sheet.md b/cheatsheets/REST_Security_Cheat_Sheet.md similarity index 98% rename from cheatsheets/5.12 - REST_Security_Cheat_Sheet.md rename to cheatsheets/REST_Security_Cheat_Sheet.md index 032809b270..44923a45a8 100644 --- a/cheatsheets/5.12 - REST_Security_Cheat_Sheet.md +++ b/cheatsheets/REST_Security_Cheat_Sheet.md @@ -69,7 +69,7 @@ API keys can reduce the impact of denial-of-service attacks. However, when they - Revoke the API key if the client violates the usage agreement. - Do not rely exclusively on API keys to protect sensitive, critical or high-value resources. -## Restrict HTTP methods - 5.12.4 +## Restrict HTTP methods - Apply an allow list of permitted HTTP Methods e.g. `GET`, `POST`, `PUT`. - Reject all requests not matching the allow list with HTTP response code `405 Method not allowed`. @@ -77,7 +77,7 @@ API keys can reduce the impact of denial-of-service attacks. However, when they In Java EE in particular, this can be difficult to implement properly. See [Bypassing Web Authentication and Authorization with HTTP Verb Tampering](../assets/REST_Security_Cheat_Sheet_Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf) for an explanation of this common misconfiguration. -## Input validation - 5.12.4 +## Input validation - Do not trust input parameters/objects. - Validate input: length / range / format and type. @@ -96,13 +96,13 @@ A REST request or response body should match the intended content type in the he - Document all supported content types in your API. -### Validate request content types - 5.12.4 +### Validate request content types - Reject requests containing unexpected or missing content type headers with HTTP response status `406 Unacceptable` or `415 Unsupported Media Type`. - For XML content types ensure appropriate XML parser hardening, see the [XXE cheat sheet](XML_External_Entity_Prevention_Cheat_Sheet.md). - Avoid accidentally exposing unintended content types by explicitly defining content types e.g. [Jersey](https://jersey.github.io/) (Java) `@consumes("application/json"); @produces("application/json")`. This avoids [XXE-attack](https://owasp.org/www-community/vulnerabilities/XML_External_Entity_%28XXE%29_Processing) vectors for example. -### Send safe response content types - 5.12.4 +### Send safe response content types It is common for REST services to allow multiple response types (e.g. `application/xml` or `application/json`, and the client specifies the preferred order of response types by the Accept header in the request. @@ -161,7 +161,7 @@ Cross-Origin Resource Sharing (CORS) is a W3C standard to flexibly specify what - Disable CORS headers if cross-domain calls are not supported/expected. - Be as specific as possible and as general as necessary when setting the origins of cross-domain calls. -## Sensitive information in HTTP requests - 5.12.3 +## Sensitive information in HTTP requests RESTful web services should be careful to prevent leaking credentials. Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable. @@ -178,7 +178,7 @@ RESTful web services should be careful to prevent leaking credentials. Passwords `https://example.com/controller/123/action?apiKey=a53f435643de32` because API Key is into the URL. -## HTTP Return Code - 5.12.4 +## HTTP Return Code HTTP defines [status code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes). When designing REST API, don't just use `200` for success or `404` for error. Always use the semantically appropriate status code for the response. diff --git a/cheatsheets/5.6 - Secrets_Management_CheatSheet.md b/cheatsheets/Secrets_Management_CheatSheet.md similarity index 100% rename from cheatsheets/5.6 - Secrets_Management_CheatSheet.md rename to cheatsheets/Secrets_Management_CheatSheet.md diff --git a/cheatsheets/5.12.1 - Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md b/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md similarity index 100% rename from cheatsheets/5.12.1 - Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md rename to cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md diff --git a/cheatsheets/5.4 - Session_Management_Cheat_Sheet.md b/cheatsheets/Session_Management_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.4 - Session_Management_Cheat_Sheet.md rename to cheatsheets/Session_Management_Cheat_Sheet.md index afabcda843..3ee7d8cc0b 100644 --- a/cheatsheets/5.4 - Session_Management_Cheat_Sheet.md +++ b/cheatsheets/Session_Management_Cheat_Sheet.md @@ -126,7 +126,7 @@ Forcing the web application to only use HTTPS for its communication (even when p See also: [SecureFlag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies) -### HttpOnly Attribute - 5.4.2, 5.4.3 +### HttpOnly Attribute The `HttpOnly` cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. However, if an XSS attack is combined with a CSRF attack, the requests sent to the web application will include the session cookie, as the browser always includes the cookies when sending requests. The `HttpOnly` cookie only protects the confidentiality of the cookie; the attacker cannot use it offline, outside of the context of an XSS attack. diff --git a/cheatsheets/Threat_Modeling_Cheat_Sheet.md b/cheatsheets/Threat_Modeling_Cheat_Sheet.md index 23a81d5b43..a456411268 100644 --- a/cheatsheets/Threat_Modeling_Cheat_Sheet.md +++ b/cheatsheets/Threat_Modeling_Cheat_Sheet.md @@ -43,7 +43,7 @@ In addition to the above terminologies, it is important to be familiar with the Before starting the threat modeling process it is important to identify business objectives of the applications you are assessing, and to identify security and compliance requirements that may be necessary due to business or government regulation. Having these objectives and requirements in mind before the threat assessment begins will help you to evaluate the impact of any threat you find during the risk analysis process. -### Identify application design - 5.8.1 +### Identify application design Early in the threat modeling process, you will need to draw a data flow diagram of the entire system that is being assessed, including its trust boundaries. Thus, understanding the design of the application is key to performing threat modeling. Even if you are very familiar with the application design, you may identify additional data flows and trust boundaries throughout the threat modeling process. @@ -171,7 +171,7 @@ Define Data Flows over the organization Data Flow Diagram. Define any distinct boundaries (External boundaries and Internal boundaries) within which a system trusts all sub-systems (including data). -### Define applications user roles and trust levels - 5.8.3 +### Define applications user roles and trust levels Define access rights that the application will grant to external entities and internal entities. diff --git a/cheatsheets/5.9 - Transport_Layer_Protection_Cheat_Sheet.md b/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md similarity index 99% rename from cheatsheets/5.9 - Transport_Layer_Protection_Cheat_Sheet.md rename to cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md index aeba449ee2..cea65615fe 100644 --- a/cheatsheets/5.9 - Transport_Layer_Protection_Cheat_Sheet.md +++ b/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md @@ -21,7 +21,7 @@ The terms "SSL", "SSL/TLS" and "TLS" are frequently used interchangeably, and in ## Server Configuration -### Only Support Strong Protocols - 5.9.6 +### Only Support Strong Protocols The SSL protocols have a large number of weaknesses, and should not be used in any circumstances. General purpose web applications should default to TLS 1.3 (support TLS 1.2 if necessary) with all other protocols disabled. Where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. @@ -99,7 +99,7 @@ The private key should also be protected from unauthorized access using filesyst Certificates should use SHA-256 for the hashing algorithm, rather than the older MD5 and SHA-1 algorithms. These have a number of cryptographic weaknesses, and are not trusted by modern browsers. -### Use Correct Domain Names - 5.9.2 +### Use Correct Domain Names The domain name (or subject) of the certificate must match the fully qualified name of the server that presents the certificate. Historically this was stored in the `commonName` (CN) attribute of the certificate. However, modern versions of Chrome ignore the CN attribute, and require that the FQDN is in the `subjectAlternativeName` (SAN) attribute. For compatibility reasons, certificates should have the primary FQDN in the CN, and the full list of FQDNs in the SAN. diff --git a/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md b/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md index fd55beb082..f18adda299 100644 --- a/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md +++ b/cheatsheets/User_Privacy_Protection_Cheat_Sheet.md @@ -6,7 +6,7 @@ This OWASP Cheat Sheet introduces mitigation methods that web developers may uti ## Guidelines -### Strong Cryptography - 5.8.2 +### Strong Cryptography Any online platform that handles user identities, private information or communications must be secured with the use of strong cryptography. User communications must be encrypted in transit and storage. User secrets such as passwords must also be protected using strong, collision-resistant hashing algorithms with increasing work factors, in order to greatly mitigate the risks of exposed credentials as well as proper integrity control.