diff --git a/.wordlist.txt b/.wordlist.txt index 351c6d9..068bf23 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -11,13 +11,17 @@ APIs AppSec Aref ASVS +authenticator autobinding backend Baillon +bcrypt Braiterman BSIMM caniuse Caniuse +canonicalization +Canonicalization Capellan Cassio cd @@ -26,23 +30,28 @@ cheatsheetseries Checkov Chih Chorzevski +CIS CLI clickjacking Clickjacking Cloudmapper Coiro +ColdFusion config CORS Coursera crypto cryptographic +cryptographically CSP CSRF CSRF CVE CWE +Cx Cybuck Cyrille +DAC danielmiessler Datz de @@ -61,6 +70,7 @@ DevSlop DNS docx DOM +DOMPurify Dracea DSS DTOs @@ -95,6 +105,7 @@ HTTPS IaC ideation IDOR +iframes intransparency io ISC @@ -103,6 +114,7 @@ Ivashchenko Jasmin JavaScript JEA +JEP JIT Joubert JS @@ -111,6 +123,9 @@ JSR JWS JWT JWTs +keychain +keystore +KeyWhiz KICS KMS Koichiro @@ -118,6 +133,8 @@ Kubernetes Kubescape Kuramochi Kyverno +LDAP +Libsodium linkedin localhost Mair @@ -126,6 +143,7 @@ Massimiliano MASVS Microservices Miessler +Misconfiguration misconfigure mkdocs Mohammed @@ -133,12 +151,15 @@ Nagai NCSC NIST nonces +NoSQL NVD OAuth OKADA oneconsult's +OPC OpenSAMM OpenSSF +OQL ORM Osama OTP @@ -156,6 +177,7 @@ programmatically py RBAC RCE +reactively realtime ReDoS Referer @@ -167,11 +189,13 @@ Saft SameSite SAMM sandbopxing +sandboxing Sanitization SAST SBOM SBOMs SCA +scalability SecLists securitypatterns Shaheed @@ -200,6 +224,7 @@ Tfsec ThreeHoolagins ThunderSon Timo +Tink TLS TLSv Transformative @@ -212,6 +237,7 @@ untrusted Validator Vanhilst venv +verifier Vries Watanabe WebAuthn @@ -221,4 +247,5 @@ www XEE XFO XSS +Zend Zudilin diff --git a/docs/archive/2018/c3-secure-database.md b/docs/archive/2018/c3-secure-database.md index 4d73160..48a50db 100644 --- a/docs/archive/2018/c3-secure-database.md +++ b/docs/archive/2018/c3-secure-database.md @@ -13,13 +13,13 @@ This section describes secure access to all data stores, including both relation SQL Injection occurs when untrusted user input is dynamically added to a SQL query in an insecure manner, often via basic string concatenation. SQL Injection is one of the most dangerous application security risks. SQL Injection is easy to exploit and could lead to the entire database being stolen, wiped, or modified. The application can even be used to run dangerous commands against the operating system hosting your database, thereby giving an attacker a foothold on your network. -In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parameterization'. This defense should be applied to SQL, OQL, as well as stored procedure construction. +In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parametrization'. This defense should be applied to SQL, OQL, as well as stored procedure construction. -A good list of query parameterization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at [http://bobby-tables.com](http://bobby-tables.com/) and the [OWASP Cheat Sheet on Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html). +A good list of query parameterization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at [http://bobby-tables.com](http://bobby-tables.com/) and the [OWASP Cheat Sheet on Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html). -#### Caution on Query Parameterization +#### Caution on Query Parametrization -Certain locations in a database query are not parameterizable. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parameterized query. Also, while the use of parameterized queries largely has a positive impact on performance, certain parameterized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities. +Certain locations in a database query can not be used with parametrization. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parameterized query. Also, while the use of parameterized queries largely has a positive impact on performance, certain parameterized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities. ### Secure Configuration @@ -46,7 +46,7 @@ A quick guidance on providing a secure communication mean can be found in the [D ## References -* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) * [OWASP Cheat Sheet: Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) * [Bobby Tables: A guide to preventing SQL injection](http://bobby-tables.com/) * [CIS Database Hardening Standards](https://www.cisecurity.org/cis-benchmarks/) diff --git a/docs/archive/2018/c5-validate-inputs.md b/docs/archive/2018/c5-validate-inputs.md index 1a98cdb..e554532 100644 --- a/docs/archive/2018/c5-validate-inputs.md +++ b/docs/archive/2018/c5-validate-inputs.md @@ -8,7 +8,7 @@ Input validation is a programming technique that ensures only properly formatted An application should check that data is both *syntactically* and *semantically* valid (in that order) before using it in any way (including displaying it back to the user). -**Syntax validity** means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit "account ID" to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization). +**Syntax validity** means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit "account ID" to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parametrization). **Semantic validity** includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges. @@ -46,7 +46,7 @@ Regular expressions are just one way to accomplish validation. Regular expressio ### Limits of Input Validation -**Input validation does not always make data "safe" since certain forms of complex input may be "valid" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack**. Additional defenses besides input validation should always be applied to data such as query parameterization or escaping. +**Input validation does not always make data "safe" since certain forms of complex input may be "valid" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack**. Additional defenses besides input validation should always be applied to data such as query parametrization or escaping. ### Challenges of Validating Serialized Data diff --git a/docs/archive/2018/c6-digital-identity.md b/docs/archive/2018/c6-digital-identity.md index ebfe7de..2d3e2a5 100644 --- a/docs/archive/2018/c6-digital-identity.md +++ b/docs/archive/2018/c6-digital-identity.md @@ -96,7 +96,7 @@ Server-side sessions can be limiting for some forms of authentication. "Stateles JSON Web Token (JWT) is an open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. A JWT token is created during authentication and is verified by the server (or servers) before any processing. -However, JWT's are often not saved by the server after initial creation. JWT's are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation. +However, JWTs are often not saved by the server after initial creation. JWT's are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation. This approach is both stateless and portable in the way that client and server technologies can be different yet still interact. diff --git a/docs/archive/2018/c8-protect-data-everywhere.md b/docs/archive/2018/c8-protect-data-everywhere.md index 0b93d81..d6c4d15 100644 --- a/docs/archive/2018/c8-protect-data-everywhere.md +++ b/docs/archive/2018/c8-protect-data-everywhere.md @@ -8,11 +8,11 @@ Attackers can steal data from web and webservice applications in a number of way ## Data Classification -It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is ok to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit. +It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit. ## Encrypting Data in Transit -When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, webservice, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications. +When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, web service, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications. The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components. @@ -46,7 +46,7 @@ When an immutable datatype such as `string` is used to store secrets, secrets ca Even if you try to nullify the string value, it still remains in the memory. `string` is an immutable type and cannot be changed. When you modify a string (try to overwrite it), a new copy of it is created. This means another copy of the unprotected secret will remain in the memory. -Furthermore, there is no gurantee when garbage collector is going to clean up the secret. +Furthermore, there is no guarantee when garbage collector is going to clean up the secret. This increases exposure of plaintext secrets in the memory. If secrets remain unprotected in the memory, they can get disclosed on the disk or external log aggregators @@ -60,7 +60,7 @@ For an example implementation see [this post](https://discuss.secdim.com/t/do-no Applications contain numerous "secrets" that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following. -* Don't store secrets in code, config files or pass them through environment variables. Use tools like [GitRob](https://github.com/michenriksen/gitrob) or [TruffleHog](https://github.com/dxa4481/truffleHog) to scan code repos for secrets. +* Don't store secrets in code, config files or pass them through environment variables. Use tools like [GitRob](https://github.com/michenriksen/gitrob) or [TruffleHog](https://github.com/dxa4481/truffleHog) to scan code repositories for secrets. * Keep keys and your other application-level secrets in a secrets vault like [KeyWhiz](https://github.com/square/keywhiz) or [Hashicorp's Vault project](https://www.vaultproject.io/) or [Amazon KMS](https://aws.amazon.com/kms/) to provide secure storage and access to application-level secrets at run-time. ## Vulnerabilities Prevented diff --git a/docs/introduction/related-owasp-projects.md b/docs/introduction/related-owasp-projects.md index f97eb56..cd15431 100644 --- a/docs/introduction/related-owasp-projects.md +++ b/docs/introduction/related-owasp-projects.md @@ -12,11 +12,11 @@ The best-known OWASP document is the [OWASP Top 10](https://owasp.org/Top10/). T ## OWASP SAMM -[Software Assurance Maturity Model (SAMM)](https://www.opensamm.org/) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . [SAMM](https://owaspsamm.org/about/) supports the complete software lifecycle and can be used to identify what +[Software Assurance Maturity Model (SAMM)](https://www.opensamm.org/) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . [SAMM](https://owaspsamm.org/about/) supports the complete software life cycle and can be used to identify what ## Threat Modeling in General -Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) can be used to create threat model diagrams as part of a secure development lifecycle. +Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) can be used to create threat model diagrams as part of a secure development life cycle. ## Domain-Specific Documents diff --git a/docs/the-top-10/c1-accesscontrol.md b/docs/the-top-10/c1-accesscontrol.md index 0b7fab7..29b5ace 100644 --- a/docs/the-top-10/c1-accesscontrol.md +++ b/docs/the-top-10/c1-accesscontrol.md @@ -53,7 +53,7 @@ An example of implementing that principle is to create dedicated privileged role To further improve the security, you can implement Just-in-Time (JIT) or Just-enough-Access (JEA): ensure that all users, programs, or processes are only given just enough access to achieve their current mission. This access should be provided just in time, when the subject makes the request, and the access should be granted for a short time. Be wary of systems that do not provide granular access control configuration capabilities. -### 6) Do not Hardcode Roles +### 6) Do not Hard-code Roles Many application frameworks default to access control that is role based. It is common to find application code filled with checks of this nature. diff --git a/docs/the-top-10/c2-crypto.md b/docs/the-top-10/c2-crypto.md index ffb3c47..64597f4 100644 --- a/docs/the-top-10/c2-crypto.md +++ b/docs/the-top-10/c2-crypto.md @@ -2,7 +2,7 @@ ## Description -Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU’s General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. +Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. Attackers can steal data from web and web service applications in a number of ways. For example, if sensitive information is sent over the internet without communications security, then an attacker on a shared wireless connection could capture and steal another user’s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public. @@ -16,7 +16,7 @@ Cryptography is the art or science concerning the principles, means, and methods ### Classify data types in your application -It’s critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is ok to place on the public website. Credit card numbers may be classified as private user data which will need to be encrypted while stored, processed or in transit. +It’s critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which will need to be encrypted while stored, processed or in transit. Data classification can also be mandated by legislation, e.g., GDPR when serving users within the European Union. @@ -53,10 +53,10 @@ Do not store the passwords in plain text anywhere in the database. Always use a #### Special Case: Application Secrets management Applications contain numerous “secrets” that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following: -Don’t store secrets in code, config files or pass them through environment variables. Use tools like GitRob or TruffleHog to scan code repos for secrets. Your code should be written in a way that even if your code would be disclosed, e.g., due to a defective configured github repository, your running applications are still secure. -Keep keys and your other application-level secrets in a secrets vault like KeyWhiz or Hashicorp’s Vault project , Amazon KMS, or AWS Secrets Manager to provide secure storage and access to application-level secrets at run-time. Many web-frameworks such as Ruby on Rails provide integrated ways of dealing with secrets and credentials. +Don’t store secrets in code, config files or pass them through environment variables. Use tools like GitRob or TruffleHog to scan code repositories for secrets. Your code should be written in a way that even if your code would be disclosed, e.g., due to a defective configured github repository, your running applications are still secure. +Keep keys and your other application-level secrets in a secrets vault like KeyWhiz or Hashicorp's Vault project , Amazon KMS, or AWS Secrets Manager to provide secure storage and access to application-level secrets at run-time. Many web-frameworks such as Ruby on Rails provide integrated ways of dealing with secrets and credentials. -#### Key Lifecycle +#### Key Life Cycle Secret keys are used in applications with a number of sensitive functions. For example, secret keys can be used to sign JWTs, protect credit cards, provide various forms of authentication as well as facilitate other sensitive security features. In managing keys, a number of rules should be followed including diff --git a/docs/the-top-10/c3-validate-input-and-handle-exceptions.md b/docs/the-top-10/c3-validate-input-and-handle-exceptions.md index c9e7127..2e96855 100644 --- a/docs/the-top-10/c3-validate-input-and-handle-exceptions.md +++ b/docs/the-top-10/c3-validate-input-and-handle-exceptions.md @@ -84,7 +84,7 @@ More examples are available in the [OWASP Mass Assignment Cheat Sheet](https://w ### Limits of Input Validation -Input validation does not always make data “safe” since certain complex input forms may be “valid” but still dangerous. For example, a valid email address may contain a SQL injection attack, or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data, such as query parameterization or escaping. +Input validation does not always make data “safe” since certain complex input forms may be “valid” but still dangerous. For example, a valid email address may contain a SQL injection attack, or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data, such as query parametrization or escaping. ### Use mechanisms that uphold the separation of data and commands diff --git a/docs/the-top-10/c5-secure-by-default.md b/docs/the-top-10/c5-secure-by-default.md index f226189..6242ed8 100644 --- a/docs/the-top-10/c5-secure-by-default.md +++ b/docs/the-top-10/c5-secure-by-default.md @@ -38,7 +38,7 @@ As part of software development, a developer needs to ensure that software is co ## References -- OWASP Cheat Sheet: [Infrastructure as Code Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +- OWASP Cheat Sheet: [Infrastructure as Code Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) - OWASP ASVS: [Application Security Verification Standard V14 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V14-Config.md) - [Cloud security guidance - NCSC.GOV.UK](https://www.ncsc.gov.uk/collection/cloud-security) diff --git a/docs/the-top-10/c6-use-secure-dependencies.md b/docs/the-top-10/c6-use-secure-dependencies.md index e1804dc..e26acce 100644 --- a/docs/the-top-10/c6-use-secure-dependencies.md +++ b/docs/the-top-10/c6-use-secure-dependencies.md @@ -46,9 +46,9 @@ New security vulnerabilities are disclosed every day and are published in public 2. **Perform continuous checks.** Use your SBOMs together with periodic or continuous monitoring tools such as OWASP dependency-track to automatically detect well-known publicly disclosed vulnerabilities. -3. **Verify for security early and often** - integrate SCA tools in early stages of software development, to gain visibility in the number and criticality of security vulnerabilities of the software and its dependencies from every stage of the software development lifecycle. +3. **Verify for security early and often** - integrate SCA tools in early stages of software development, to gain visibility in the number and criticality of security vulnerabilities of the software and its dependencies from every stage of the software development life cycle. -4. **Proactively** update libraries and components. Updating software must be a recurring task that occurs throughout the lifecycle of the application or product, from ideation to retirement. +4. **Proactively** update libraries and components. Updating software must be a recurring task that occurs throughout the life cycle of the application or product, from ideation to retirement. ## Vulnerabilities Prevented @@ -56,7 +56,7 @@ Secure frameworks and libraries can help to prevent a wide range of web applicat ## References -- OWASP Cheat Sheet: [Third Party Javascript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content) +- OWASP Cheat Sheet: [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content) - [OpenSSF Scorecard - Security health metrics for Open Source](https://github.com/ossf/scorecard) ## Tools diff --git a/docs/the-top-10/c7-implement-digital-identity.md b/docs/the-top-10/c7-implement-digital-identity.md index a00f654..8274ef4 100644 --- a/docs/the-top-10/c7-implement-digital-identity.md +++ b/docs/the-top-10/c7-implement-digital-identity.md @@ -6,7 +6,7 @@ Digital Identity is a unique representation of an individual, organization (or a Session management is the process by which a server maintains the state of the user’s authentication so that the user may continue to use the system without re-authenticating. Digital identity, authentication, and session management are very complex topics. We're scratching the surface of the topic of Digital Identity here. Ensure that your most capable engineering talent is responsible for maintaining the complexity involved with most Identity solutions. -The [NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html) provide solid guidance on implementing digital identity, authentication, and session management controls. Below are some recommendations for secure implementation to ensure strong digital identity controls are implemented in applications. +The [NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Life Cycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html) provide solid guidance on implementing digital identity, authentication, and session management controls. Below are some recommendations for secure implementation to ensure strong digital identity controls are implemented in applications. ### Authentication Assurance Levels diff --git a/docs/the-top-10/c8-help-the-browser-defend-the-user.md b/docs/the-top-10/c8-help-the-browser-defend-the-user.md index f9ef0f5..3b6e006 100644 --- a/docs/the-top-10/c8-help-the-browser-defend-the-user.md +++ b/docs/the-top-10/c8-help-the-browser-defend-the-user.md @@ -24,7 +24,7 @@ A fully compromised browser might not heed security guidance but if an adversary - An attacker could exploit MIME type confusion vulnerabilities in the absence of X-Content-Type-Options headers, potentially executing malicious scripts disguised as benign file types. - An attacker could hijack user sessions by exploiting insecure cookie settings, potentially gaining unauthorized access to user accounts. - An attacker could perform DNS rebinding attacks in the absence of proper DNS pinning, potentially bypassing same-origin policy restrictions. -- An attacker could exploit cross-origin resource sharing (CORS) misconfigurations to gain unauthorized access to resources, potentially compromising data confidentiality and integrity. +- An attacker could exploit a cross-origin resource sharing (CORS) misconfiguration to gain unauthorized access to resources, potentially compromising data confidentiality and integrity. ## Implementation @@ -38,19 +38,19 @@ The following is a non-exhaustive list of potential Hardening mechanisms: Information disclosure occurs if the browser transmits information over unencrypted channels (HTTP instead of HTTPS) or sends our too much information in the first place (e.g., through the Referer-Header). The following mechanisms reduce the possibility of information disclosure: - **HTTP Strict Transport Security (HSTS)**: Ensures that browsers only connect to your website over HTTPS, preventing SSL stripping attacks. -- **Content Security Policy (CSP)**: CSP policies can instruct the browser to automatically upgrade HTTP connections to HTTPS. In addition directives such as the form-src directive can be used to prevent forms from transmitting data to external sites. +- **Content Security Policy (CSP)**: CSP policies can instruct the browser to automatically upgrade HTTP connections to HTTPS. In addition directives such as the 'form-src' directive can be used to prevent forms from transmitting data to external sites. - **Referrer-Policy**: when navigating between pages, the browser’s HTTP request includes the current URL within the outgoing request. This URL can include sensitive information. Using Referrer-Policy, a web-site can unify the browser’s behavior and select which information should be transmitted between web sites. - The cookie’s **secure** flag: while not a HTTP header, this security flag is related to information disclosure. If set, the web browser will not transmit a cookie over unencrypted HTTP transports. ### Reduce the potential Impact of XSS -Javascript based XSS attacks have been very common for decades. To reduce the potential impact of vulnerabilities, browsers offer rich defensive mechanisms that should reduce the potential impact of XSS attacks: +JavaScript based XSS attacks have been very common for decades. To reduce the potential impact of vulnerabilities, browsers offer rich defensive mechanisms that should reduce the potential impact of XSS attacks: - **Content Security Policy (CSP)**: CSP is a powerful tool that helps prevent a wide range of attacks including Cross-Site Scripting (XSS) and data injection. Strict CSP policies can effectively disable inline JavaScript and style, making it much harder for attackers to inject malicious content. **Host Allowlist CSP**: Blocking all third-party JavaScript can significantly reduce the attack surface and prevent the exploitation of vulnerabilities in third-party libraries. **Strict CSP**: A CSP utilizing nonces or hashes in the 'script-src' directive (often referred to as "strict CSP") provides a robust mitigation against XSS vulnerabilities. Optionally, the use of the CSP 'strict-dynamic' keyword can help to streamline the implementation of a strict CSP and to ensure compatibility with third-party JavaScript libraries when required. **Trusted Types**: This is a browser API that helps prevent DOM-based cross-site scripting vulnerabilities by ensuring only secure data types can be inserted into the DOM. -- The cookie’s **httpOnly** flag: while not a HTTP header, setting this flag prevents Javascript from accessing this cookie and should be done esp. For Session cookies. +- The cookie’s **httpOnly** flag: while not a HTTP header, setting this flag prevents JavaScript from accessing this cookie and should be done esp. For Session cookies. ### Prevent Clickjacking diff --git a/docs/the-top-10/introduction.md b/docs/the-top-10/introduction.md index e18633b..b28f1e3 100644 --- a/docs/the-top-10/introduction.md +++ b/docs/the-top-10/introduction.md @@ -18,7 +18,7 @@ This list was originally created by the current project leads with contributions ## Security Controls -The description of each control has the same structure. The control itself has an unique name preceeded by the control number: **Cx: Control Name**, e.g., *C1: Implement Access Control*. +The description of each control has the same structure. The control itself has an unique name preceded by the control number: **Cx: Control Name**, e.g., *C1: Implement Access Control*. Each control has the same sections: