Revert "[NO-TICKET] Customize the title number based security coding …

…standard (#953)" (#954)

This reverts commit 02f0039.

cheatsheets/5.1 - Authorization_Cheat_Sheet.md → 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,19 +106,19 @@ 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:
 
 - Ensure all exception and failed access control checks are handled no matter how unlikely they seem ([OWASP Top Ten Proactive Controls C10: Handle all errors and exceptions](https://owasp.org/www-project-proactive-controls/v3/en/c10-errors-exceptions.html)). This does not mean that an application should always try to "correct" for a failed check; oftentimes a simple message or HTTP status code is all that is required.
 - 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:
 

cheatsheets/5.10 - Database_Security_Cheat_Sheet.md → 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:
 

cheatsheets/5.7 - Error_Handling_Cheat_Sheet.md → 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.
 

cheatsheets/5.11 - File_Upload_Cheat_Sheet.md → 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:
 

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.
 

cheatsheets/Kubernetes_Security_Cheat_Sheet.md

@@ -215,7 +215,7 @@ For more information, refer to <https://hub.docker.com/_/scratch>
 
 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:
 

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:
 

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:

cheatsheets/5.12 - REST_Security_Cheat_Sheet.md → cheatsheets/REST_Security_Cheat_Sheet.md

@@ -69,15 +69,15 @@ 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`.
 - Make sure the caller is authorised to use the incoming HTTP method on the resource collection, action, and record
 
 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.
 

cheatsheets/5.4 - Session_Management_Cheat_Sheet.md → 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.