Fixes #131 Top 10 proactivecontrols

.wordlist-en.txt

@@ -115,7 +115,9 @@ InlineHilite
 Istio
 JA
 JDK
+JEA
 JIRA
+JIT
 JSON
 JSONP
 JSP

docs/en/04-design/02-web-app-checklist/01-secure-by-default.md

@@ -0,0 +1,60 @@
+“Secure-by-Default” means products are resilient against prevalent exploitation techniques out of the box
+without additional charge. Software should start in a secure state without requiring extensive user configuration,
+ensuring the default settings are always the most secure option.
+
+Refer to proactive control [C5: Secure By Default Configurations][control5] and the
+[Infrastructure as Code Security Cheatsheet][csproactive-c5]
+for more context from the OWASP Top 10 Proactive Controls project,
+and use the lists below as suggestions for a checklist that has been tailored for the individual project.
+
+#### 1. System configuration
+
+1. Restrict applications, processes and service accounts to the least privileges possible
+2. Code which defines the infrastructure should follow the principle of least privilege.
+3. Remove all unnecessary functionality such as files, accounts, software, and demo capabilities
+4. Remove test code or any functionality not intended for production, prior to deployment
+5. The security configuration store for the application should be available in human readable form to support auditing
+6. Isolate development environments from production and provide access only to authorized development and test groups
+7. Implement a software change control system to manage and record changes to the code both in development and production
+8. Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file,
+the
+    X-Robots-Tag response header or a robots html meta tag
+9. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is
+    required, utilize a well-vetted authentication mechanism
+10. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application
+    frameworks unless implemented to confuse an attacker
+11. Ensure the .git, .svn folders or any source control metadata aren't deployed together alongside the application in
+    away that makes these directly accessible externally or indirectly through the application
+12. Do not store passwords, secrets, connection strings, key material, secret management integrations or other
+    sensitive information in clear text or in any non-cryptographically secure manner on the client, in source code, or build
+    artifacts
+13. Remove or restrict access to internal application and system documentation (such as for internal APIs) as this can
+    reveal backend system or other useful information to attackers
+
+#### 2. File Management
+
+1. Turn off directory listings
+2. Do not save files in the same web context as the application
+3. Turn off execution privileges on file upload directories
+4. Ensure application files and resources are read-only
+5. Restrict access to files or other resources, including those outside the application's direct control using an allow list
+    or the equivalent thereof.
+
+#### 3. Cloud security
+
+1. Enforce JIT (Just-In-Time) access management
+2. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private
+    container registry
+3. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on-
+    premises infrastructure
+4. Utilize Policy-as-Code to enforce policies including privilege assignments
+
+----
+
+The OWASP Developer Guide is a community effort; if there is something that needs changing
+then [submit an issue][issue060201] or [edit on GitHub][edit060201].
+
+[control5]: https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/
+[csproactive-c5]: https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html
+[edit060201]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md
+[issue060201]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/01-secure-by-default

docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md

@@ -1,7 +1,7 @@
 Secure coding libraries and software frameworks with embedded security help software developers guard against
 security-related design and implementation flaws.
 
-Refer to proactive control [C4: Address Security from the Start][control4]
+Refer to proactive control [C6: Keep your Components Secure][control6]
 and its [cheatsheets][csproactive-c2] for more context from the OWASP Top 10 Proactive Controls project.
 
 For technology specific checklists refer to the appropriate OWASP Cheat Sheets:
@@ -39,16 +39,18 @@ In addition consider the following extra checks for frameworks and libraries.
 2. Use libraries and frameworks from trusted sources that are actively maintained and widely used
 3. Review all secondary applications and third party libraries to determine business necessity
 4. Validate safe functionality for all secondary applications and third party libraries
-5. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA)
+5. Create and maintain an inventory catalog of all third party libraries. It is recommended to automatically create
+    SBOMs (Software-Bill-Of-Materials) from within the build pipeline.
 6. Proactively keep all third party libraries and components up to date
 7. Reduce the attack surface by encapsulating the library and expose only the required behavior into your software
 8. Use tested and approved managed code rather than creating new unmanaged code for common tasks
 9. Utilize task specific built-in APIs to conduct operating system tasks
-10. Do not allow the application to issue commands directly to the Operating System
-11. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
-12. Restrict users from generating new code or altering existing code
-13. Implement safe updates using encrypted channels
-14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures
+10. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
+11. Restrict users from generating new code or altering existing code
+12. Implement safe updates using encrypted channels
+13. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures
+14. Use your SBOMs together with periodic or SCA tools to automatically detect well-known publicly disclosed vulnerabilities.
+15. integrate SCA tools in early stages of software development
 
 #### References
 
@@ -84,7 +86,7 @@ then [submit an issue][issue060202] or [edit on GitHub][edit060202].
 [cswebservice]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet
 [csxml]: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet
 [csproactive-c2]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c2-leverage-security-frameworks-and-libraries
-[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/
+[control6]: https://top10proactive.owasp.org/the-top-10/c6-use-secure-dependencies/
 [dependency]: https://owasp.org/www-project-dependency-check/
 [edit060202]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md
 [issue060202]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/02-frameworks-libraries

docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md

@@ -5,7 +5,9 @@ The target system may be another software component or it may be reflected back
 such as operating system commands,
 so encoding and escaping output data helps to provide defense in depth for the system as a whole.
 
-Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c4]
+Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c4] and
+[C10: Stop Server Side Request Forgery][control10] together with
+[Server-Side Request Forgery Prevention Cheat Sheet][csproactive-c10]
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the list below as suggestions for a checklist that has been tailored for the individual project.
 
@@ -15,7 +17,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 2. Conduct all output encoding on a trusted system
 3. Utilize a standard, tested routine for each type of outbound encoding
 4. Specify character sets, such as UTF-8, for all outputs
-5. Apply canonicalization to convert unicode data into a standard form
+5. Apply canonicalization to convert unicode data into a standard form and address obfuscation attacks
 6. Ensure the output encoding is safe for all target systems
 7. In particular sanitize all output used for operating system commands
 8. Sanitize potentially dangerous characters before using the data to call another service
@@ -40,7 +42,9 @@ The OWASP Developer Guide is a community effort; if there is something that need
 then [submit an issue][issue060204] or [edit on GitHub][edit060204].
 
 [csproactive-c4]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c4-encode-and-escape-data
+[csproactive-c10]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
 [control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/
+[control10]: https://top10proactive.owasp.org/the-top-10/c10-stop-server-side-request-forgery/
 [edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md
 [encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
 [ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet

docs/en/04-design/02-web-app-checklist/05-validate-inputs.md

@@ -18,9 +18,8 @@ and use the list below as suggestions for a checklist that has been tailored for
 6. Verify that protocol header values in both requests and responses contain only ASCII characters
 7. Validate data from redirects
 8. Validate data range and also data length
-9. Utilize canonicalization to address obfuscation attacks
-10. All validation failures should result in input rejection
-11. Validate all input against an allowlist of characters, whenever possible
+9. All validation failures should result in input rejection
+10. Validate all input against an allowlist of characters, whenever possible
 
 #### 2. Libraries and frameworks
 
@@ -29,6 +28,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 3. If the standard validation routine cannot address some inputs then use extra discrete checks
 4. If any potentially hazardous input _must_ be allowed then implement additional controls
 5. Validate for expected data types using an allow-list rather than a deny-list
+6. Do not allow the application to issue commands directly to the Operating System
 
 #### 3. Validate serialized data
 
@@ -41,6 +41,18 @@ and use the list below as suggestions for a checklist that has been tailored for
 5. Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize
 6. Monitor deserialization, for example alerting if a user agent constantly deserializes
 
+#### 4. File validation
+
+1. Do not pass user supplied data directly to any dynamic include function
+2. Limit the type of files that can be uploaded to only those types that are needed for business purposes
+3. Validate uploaded files are the expected type by checking file headers rather than by file extension
+4. Prevent or restrict the uploading of any file that may be interpreted by the web server.
+5. When referencing existing files, use an allow-list of allowed file names and types
+6. Do not pass user supplied data into a dynamic redirect
+7. Do not pass directory or file paths, use index values mapped to pre-defined list of paths
+8. Never send the absolute file path to the client
+9. Scan user uploaded files for viruses and malware
+
 #### References
 
 * OWASP [Cheat Sheet: Input Validation][ivcs]