Links, typos, uniformity (#1341)

* feat(IndexOPC): Links per control

- Adds links for each control to the OWASP Proactive Controls document (Follows same structure as Index Top10)

Signed-off-by: otkd <7527203+otkd@users.noreply.github.com>

* fix: links, uniformity & typos

- Updates links on Index Top 10
- Changes Multi-factor to Multifactor as per cheat sheet name
- Typos

Signed-off-by: otkd <7527203+otkd@users.noreply.github.com>

---------

Signed-off-by: otkd <7527203+otkd@users.noreply.github.com>

IndexProactiveControls.md

@@ -2,17 +2,19 @@
 
 ## Objective
 
-This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) identify which cheat sheets map to each proactive controls item. This mapping is based the [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) version 3.0 (2018).
+> The OWASP Top Ten Proactive Controls 2018 is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important.
 
-## C1. Define Security Requirements
+This cheat sheet will help users of the [OWASP Top Ten Proactive Controls 2018](https://owasp.org/www-project-proactive-controls/v3/en/0x02-about-project.html) identify which cheat sheets map to each proactive control.
+
+## [C1. Define Security Requirements](https://owasp.org/www-project-proactive-controls/v3/en/c1-security-requirements)
 
 [Abuse Case Cheat Sheet](cheatsheets/Abuse_Case_Cheat_Sheet.md)
 
 [Attack Surface Analysis Cheat Sheet](cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md)
 
 [Threat Modeling Cheat Sheet](cheatsheets/Threat_Modeling_Cheat_Sheet.md)
 
-## C2. Leverage Security Frameworks and Libraries
+## [C2. Leverage Security Frameworks and Libraries](https://owasp.org/www-project-proactive-controls/v3/en/c2-leverage-security-frameworks-libraries)
 
 [Clickjacking Defense Cheat Sheet](cheatsheets/Clickjacking_Defense_Cheat_Sheet.md)
 
@@ -26,7 +28,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [Vulnerable Dependency Management Cheat Sheet](cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.md)
 
-## C3. Secure Database Access
+## [C3. Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database)
 
 [DotNet Security Cheat Sheet (Data Access)](cheatsheets/DotNet_Security_Cheat_Sheet.md#data-access)
 
@@ -38,7 +40,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [SQL Injection Prevention Cheat Sheet](cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md)
 
-## C4. Encode and Escape Data
+## [C4. Encode and Escape Data](https://owasp.org/www-project-proactive-controls/v3/en/c4-encode-escape-data)
 
 [AJAX Security Cheat Sheet (Client Side)](cheatsheets/AJAX_Security_Cheat_Sheet.md#client-side-javascript)
 
@@ -52,7 +54,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [LDAP Injection Prevention Cheat Sheet](cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.md)
 
-## C5. Validate All Inputs
+## [C5. Validate All Inputs](https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs)
 
 [Bean Validation Cheat Sheet](cheatsheets/Bean_Validation_Cheat_Sheet.md)
 
@@ -88,7 +90,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [Server Side Request Forgery Prevention Cheat Sheet](cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md)
 
-## C6. Implement Digital Identity
+## [C6. Implement Digital Identity](https://owasp.org/www-project-proactive-controls/v3/en/c6-digital-identity)
 
 [Authentication Cheat Sheet](cheatsheets/Authentication_Cheat_Sheet.md)
 
@@ -118,7 +120,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [Multi-Factor Authentication Cheat Sheet](cheatsheets/Multifactor_Authentication_Cheat_Sheet.md)
 
-## C7. Enforce Access Controls
+## [C7. Enforce Access Controls](https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls)
 
 [Access Control Cheat Sheet](cheatsheets/Access_Control_Cheat_Sheet.md)
 
@@ -144,7 +146,7 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [Multi-Factor Authentication Cheat Sheet](cheatsheets/Multifactor_Authentication_Cheat_Sheet.md)
 
-## C8. Protect Data Everywhere
+## [C8. Protect Data Everywhere](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere)
 
 [Cryptographic Storage Cheat Sheet](cheatsheets/Cryptographic_Storage_Cheat_Sheet.md)
 
@@ -166,13 +168,13 @@ This cheat sheet will help users of the [OWASP Proactive Controls](https://owasp
 
 [User Privacy Protection Cheat Sheet](cheatsheets/User_Privacy_Protection_Cheat_Sheet.md)
 
-## C9. Implement Security Logging and Monitoring
+## [C9. Implement Security Logging and Monitoring](https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging)
 
 [REST Security Cheat Sheet (Audit Logs)](cheatsheets/REST_Security_Cheat_Sheet.md#audit-logs)
 
 [Logging Cheat Sheet](cheatsheets/Logging_Cheat_Sheet.md)
 
-## C10. Handle All Errors and Exceptions
+## [C10. Handle All Errors and Exceptions](https://owasp.org/www-project-proactive-controls/v3/en/c10-errors-exceptions)
 
 [REST Security Cheat Sheet (Error Handling)](cheatsheets/REST_Security_Cheat_Sheet.md#error-handling)
 

IndexTopTen.md

@@ -2,7 +2,7 @@
 
 The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
 
-This cheat sheet will help users of the [OWASP Top Ten](https://owasp.org/www-project-top-ten/) identify which cheat sheets map to each security category. This mapping is based the [OWASP Top Ten 2021 version](https://owasp.org/www-project-top-ten/).
+This cheat sheet will help users of the [OWASP Top Ten](https://owasp.org/Top10/) identify which cheat sheets map to each security category. This mapping is based the [OWASP Top Ten 2021 version](https://owasp.org/Top10/#welcome-to-the-owasp-top-10-2021).
 
 ## [A01:2021 – Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
 

cheatsheets/Database_Security_Cheat_Sheet.md

@@ -49,7 +49,7 @@ For Microsoft SQL Server, consider the use of [Windows or Integrated-Authenticat
 
 Database credentials should never be stored in the application source code, especially if they are unencrypted. Instead, they should be stored in a configuration file that:
 
-- Is outside of the webroot.
+- Is outside of the web root.
 - Has appropriate permissions so that it can only be read by the required user(s).
 - Is not checked into source code repositories.
 
@@ -102,7 +102,7 @@ The following sections gives some further recommendations for specific database
 - Disable the [FILE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_file) privilege for all users to prevent them reading or writing files.
 - See the [Oracle MySQL](https://dev.mysql.com/doc/refman/8.0/en/security-guidelines.html) and [MariaDB](https://mariadb.com/kb/en/library/securing-mariadb/) hardening guides.
 
-### Hardewning a PostgreSQL Server
+### Hardening a PostgreSQL Server
 
 - See the [PostgreSQL Server Setup and Operation documentation](https://www.postgresql.org/docs/current/runtime.html) and the older [Security documentation](https://www.postgresql.org/docs/7.0/security.htm).
 

cheatsheets/Docker_Security_Cheat_Sheet.md

@@ -233,7 +233,7 @@ References:
 - [View logs for a container or service](https://docs.docker.com/config/containers/logging/)
 - [Dockerfile Security Best Practices](https://cloudberry.engineering/article/dockerfile-security-best-practices/)
 
- Container scanning tools are espescially important as part of a succesful security strategy. They can detect known vulnerabilities, secrets and misconfigurations in container images and provide a report of the findings with recommendations on how to fix them. Some examples of popular container scanning tools are:
+ Container scanning tools are especially important as part of a successful security strategy. They can detect known vulnerabilities, secrets and misconfigurations in container images and provide a report of the findings with recommendations on how to fix them. Some examples of popular container scanning tools are:
 
 - Free
     - [Clair](https://github.com/coreos/clair)

cheatsheets/Multifactor_Authentication_Cheat_Sheet.md

@@ -1,8 +1,8 @@
-# Multi-Factor Authentication Cheat Sheet
+# Multifactor Authentication Cheat Sheet
 
 ## Introduction
 
-Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA) is when a user is required to present more than one type of evidence in order to authenticate on a system. There are five different types of evidence (or factors) and any combination of these can be used, however in practice only the first three are common in web applications. The five types are as follows:
+Multifactor Authentication (MFA) or Two-Factor Authentication (2FA) is when a user is required to present more than one type of evidence in order to authenticate on a system. There are five different types of evidence (or factors) and any combination of these can be used, however in practice only the first three are common in web applications. The five types are as follows:
 
 | Factor | Examples |
 |--------|----------|
@@ -121,7 +121,7 @@ Knowledge-based, the most common type of authentication is based on something th
 
 ### Passwords and PINs
 
-Passwords and PINs are the most common form of authentication due to the simplicity of implementing them. The [Authentication Cheat Sheet](Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls) has guidance on how to implement a strong password policy, and the [Password Storage Cheat Sheet](Password_Storage_Cheat_Sheet.md) has guidance on how to securely store passwords. Most multi-factor authentication systems make use of a password, as well as at least one other factor.
+Passwords and PINs are the most common form of authentication due to the simplicity of implementing them. The [Authentication Cheat Sheet](Authentication_Cheat_Sheet.md#implement-proper-password-strength-controls) has guidance on how to implement a strong password policy, and the [Password Storage Cheat Sheet](Password_Storage_Cheat_Sheet.md) has guidance on how to securely store passwords. Most multifactor authentication systems make use of a password, as well as at least one other factor.
 
 #### Pros
 

cheatsheets/Transport_Layer_Security_Cheat_Sheet.md

@@ -14,7 +14,7 @@ Secure Socket Layer (SSL) was the original protocol that was used to provide enc
 
 For [various reasons](http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html) the next version of the protocol (effectively SSL 3.1) was named Transport Layer Security (TLS) version 1.0. Subsequently TLS versions 1.1, 1.2 and 1.3 have been released.
 
-The terms "SSL", "SSL/TLS" and "TLS" are frequently used interchangeably, and in many cases "SSL" is used when referring to the more modern TLS protocol. This cheatsheet will use the term "TLS" except where referring to the legacy protocols.
+The terms "SSL", "SSL/TLS" and "TLS" are frequently used interchangeably, and in many cases "SSL" is used when referring to the more modern TLS protocol. This cheat sheet will use the term "TLS" except where referring to the legacy protocols.
 
 ## Server Configuration
 
@@ -34,7 +34,7 @@ There are a large number of different ciphers (or cipher suites) that are suppor
 - Anonymous ciphers
 - EXPORT ciphers
 
-The Mozilla Foundation provides an [easy-to-use secure configuration generator](https://ssl-config.mozilla.org/) for web, database and mail servers. This tool allows site administrators to select the software they are using and receive a configuration file that is optimised to balance security and compatibility for a wide variety of browser versions and server software.
+The Mozilla Foundation provides an [easy-to-use secure configuration generator](https://ssl-config.mozilla.org/) for web, database and mail servers. This tool allows site administrators to select the software they are using and receive a configuration file that is optimized to balance security and compatibility for a wide variety of browser versions and server software.
 
 ### Use Strong Diffie-Hellman Parameters
 
@@ -118,8 +118,8 @@ When risk assessing the use of wildcard certificates, the following areas should
 - Never use a wildcard certificates for systems at different trust levels.
     - Two VPN gateways could use a shared wildcard certificate.
     - Multiple instances of a web application could share a certificate.
-    - A VPN gateway and a public webserver **should not** share a wildcard certificate.
-    - A public webserver and an internal server **should not** share a wildcard certificate.
+    - A VPN gateway and a public web server **should not** share a wildcard certificate.
+    - A public web server and an internal server **should not** share a wildcard certificate.
 - Consider the use of a reverse proxy server which performs TLS termination, so that the wildcard private key is only present on one system.
 - A list of all systems sharing a certificate should be maintained to allow them all to be updated if the certificate expires or is compromised.
 - Limit the scope of a wildcard certificate by issuing it for a subdomain (such as `*.foo.example.org`), or a for a separate domain.
@@ -164,7 +164,7 @@ A page that is available over TLS should not include any resources (such as Java
 
 ### Use the "Secure" Cookie Flag
 
-All cookies should be marked with the "[Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies)" attribute, which instructs the browser to only send them over encrypted HTTPS connections, in order to prevent them from being sniffed from an unencrypted HTTP connection. This is important even if the website does not listen on HTTP (port 80), as an attacker performing an active man in the middle attack could present a spoofed webserver on port 80 to the user in order to steal their cookie.
+All cookies should be marked with the "[Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies)" attribute, which instructs the browser to only send them over encrypted HTTPS connections, in order to prevent them from being sniffed from an unencrypted HTTP connection. This is important even if the website does not listen on HTTP (port 80), as an attacker performing an active man in the middle attack could present a spoofed web server on port 80 to the user in order to steal their cookie.
 
 ### Prevent Caching of Sensitive Data
 
@@ -221,4 +221,4 @@ However, public key pinning can still provide security benefits for mobile appli
 - IETF - [RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)](https://tools.ietf.org/html/rfc2246)
 - IETF - [RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)](https://tools.ietf.org/html/rfc4346)
 - IETF - [RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)](https://tools.ietf.org/html/rfc5246)
-- Bettercrypto - [Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services)](https://bettercrypto.org)
+- Bettercrypto - [Applied Crypto Hardening: HOW TO for secure crypto settings of the most common services)](https://bettercrypto.org)