docs: update from A06 to A10

Author: kenjis

user_guide_src/source/concepts/security.rst

@@ -327,87 +327,254 @@ CodeIgniter provisions
 A06:2021 Vulnerable and Outdated Components
 *******************************************
 
-Many applications have known vulnerabilities and known attack strategies that
-can be exploited in order to gain remote control or to exploit data.
+You are likely vulnerable:
+
+- If you do not know the versions of all components you use (both client-side
+  and server-side). This includes components you directly use as well as nested
+  dependencies.
+- If the software is vulnerable, unsupported, or out of date. This includes the OS,
+  web/application server, database management system (DBMS), applications, APIs
+  and all components, runtime environments, and libraries.
+- If you do not scan for vulnerabilities regularly and subscribe to security
+  bulletins related to the components you use.
+- If you do not fix or upgrade the underlying platform, frameworks, and dependencies
+  in a risk-based, timely fashion. This commonly happens in environments when
+  patching is a monthly or quarterly task under change control, leaving organizations
+  open to days or months of unnecessary exposure to fixed vulnerabilities.
+- If software developers do not test the compatibility of updated, upgraded, or
+  patched libraries.
+- If you do not secure the components’ configurations (see A05:2021-Security
+  Misconfiguration).
 
 OWASP recommendations
 =====================
 
-- Don't use any of these
+There should be a patch management process in place to:
+
+- Remove unused dependencies, unnecessary features, components, files, and
+  documentation.
+- Continuously inventory the versions of both client-side and server-side components
+  (e.g., frameworks, libraries) and their dependencies using tools like versions,
+  OWASP Dependency Check, retire.js, etc. Continuously monitor sources like Common
+  Vulnerability and Exposures (CVE) and National Vulnerability Database (NVD) for
+  vulnerabilities in the components. Use software composition analysis tools to
+  automate the process. Subscribe to email alerts for security vulnerabilities
+  related to components you use.
+- Only obtain components from official sources over secure links. Prefer signed
+  packages to reduce the chance of including a modified, malicious component
+  (See A08:2021-Software and Data Integrity Failures).
+- Monitor for libraries and components that are unmaintained or do not create
+  security patches for older versions. If patching is not possible, consider
+  deploying a virtual patch to monitor, detect, or protect against the discovered
+  issue.
+
+Every organization must ensure an ongoing plan for monitoring, triaging, and
+applying updates or configuration changes for the lifetime of the application or
+portfolio.
 
 CodeIgniter provisions
 ======================
 
-- Third party libraries incorporated must be vetted
+- Easy :ref:`app-starter-upgrading` by Composer
 
 ***************************************************
 A07:2021 Identification and Authentication Failures
 ***************************************************
 
-Inadequate authentication or improper session management can lead to a user
-getting more privileges than they are entitled to.
+Confirmation of the user's identity, authentication, and session management is
+critical to protect against authentication-related attacks. There may be
+authentication weaknesses if the application:
+
+- Permits automated attacks such as credential stuffing, where the attacker has
+  a list of valid usernames and passwords.
+- Permits brute force or other automated attacks.
+- Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin".
+- Uses weak or ineffective credential recovery and forgot-password processes,
+  such as "knowledge-based answers," which cannot be made safe.
+- Uses plain text, encrypted, or weakly hashed passwords data stores
+  (see A02:2021-Cryptographic Failures).
+- Has missing or ineffective multi-factor authentication.
+- Exposes session identifier in the URL.
+- Reuse session identifier after successful login.
+- Does not correctly invalidate Session IDs. User sessions or authentication tokens
+  (mainly single sign-on (SSO) tokens) aren't properly invalidated during logout
+  or a period of inactivity.
 
 OWASP recommendations
 =====================
 
-- Presentation: validate authentication & role; send CSRF token with forms
-- Design: only use built-in session management
-- Controller: validate user, role, CSRF token
-- Model: validate role
-- Tip: consider the use of a request governor
+- Where possible, implement multi-factor authentication to prevent automated
+  credential stuffing, brute force, and stolen credential reuse attacks.
+- Do not ship or deploy with any default credentials, particularly for admin users.
+- Implement weak password checks, such as testing new or changed passwords against
+  the top 10,000 worst passwords list.
+- Align password length, complexity, and rotation policies with National Institute
+  of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1 for
+  Memorized Secrets or other modern, evidence-based password policies.
+- Ensure registration, credential recovery, and API pathways are hardened against
+  account enumeration attacks by using the same messages for all outcomes.
+- Limit or increasingly delay failed login attempts, but be careful not to create
+  a denial of service scenario. Log all failures and alert administrators when
+  credential stuffing, brute force, or other attacks are detected.
+- Use a server-side, secure, built-in session manager that generates a new random
+  session ID with high entropy after login. Session identifier should not be in
+  the URL, be securely stored, and invalidated after logout, idle, and absolute
+  timeouts.
 
 CodeIgniter provisions
 ======================
 
 - :doc:`Session <../libraries/sessions>` library
-- :doc:`Security </libraries/security>` library provides for CSRF validation
-- An official authentication and authorization framework :ref:`CodeIgniter Shield <shield>`
-- Easy to add third party authentication
+- An official authentication and authorization framework
+  :ref:`CodeIgniter Shield <shield>`
 
 *********************************************
 A08:2021 Software and Data Integrity Failures
 *********************************************
 
-@TODO
+Software and data integrity failures relate to code and infrastructure that does
+not protect against integrity violations. An example of this is where an application
+relies upon plugins, libraries, or modules from untrusted sources, repositories,
+and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce
+the potential for unauthorized access, malicious code, or system compromise.
+
+Lastly, many applications now include auto-update functionality, where updates
+are downloaded without sufficient integrity verification and applied to the previously
+trusted application. Attackers could potentially upload their own updates to be
+distributed and run on all installations.
+
+Another example is where objects or data are encoded or serialized into a structure
+that an attacker can see and modify is vulnerable to insecure deserialization.
 
 OWASP recommendations
 =====================
 
-- @TODO
+- Use digital signatures or similar mechanisms to verify the software or data is
+  from the expected source and has not been altered.
+- Ensure libraries and dependencies, such as npm or Maven, are consuming trusted
+  repositories. If you have a higher risk profile, consider hosting an internal
+  known-good repository that's vetted.
+- Ensure that a software supply chain security tool, such as OWASP Dependency
+  Check or OWASP CycloneDX, is used to verify that components do not contain
+  known vulnerabilities
+- Ensure that there is a review process for code and configuration changes to
+  minimize the chance that malicious code or configuration could be introduced
+  into your software pipeline.
+- Ensure that your CI/CD pipeline has proper segregation, configuration, and
+  access control to ensure the integrity of the code flowing through the build
+  and deploy processes.
+- Ensure that unsigned or unencrypted serialized data is not sent to untrusted
+  clients without some form of integrity check or digital signature to detect
+  tampering or replay of the serialized data
 
 CodeIgniter provisions
 ======================
 
-- @TODO
+- n/a
 
 *************************************************
 A09:2021 Security Logging and Monitoring Failures
 *************************************************
 
-@TODO
+This category is to help detect, escalate, and respond to active breaches. Without
+logging and monitoring, breaches cannot be detected. Insufficient logging, detection,
+monitoring, and active response occurs any time:
+
+- Auditable events, such as logins, failed logins, and high-value transactions,
+  are not logged.
+- Warnings and errors generate no, inadequate, or unclear log messages.
+- Logs of applications and APIs are not monitored for suspicious activity.
+- Logs are only stored locally.
+- Appropriate alerting thresholds and response escalation processes are not in
+  place or effective.
+- Penetration testing and scans by dynamic application security testing (DAST)
+  tools (such as OWASP ZAP) do not trigger alerts.
+- The application cannot detect, escalate, or alert for active attacks in real-time
+  or near real-time.
+
+You are vulnerable to information leakage by making logging and alerting events
+visible to a user or an attacker (see A01:2021-Broken Access Control).
 
 OWASP recommendations
 =====================
 
-- @TODO
+Developers should implement some or all the following controls, depending on the risk of the application:
+
+- Ensure all login, access control, and server-side input validation failures can
+  be logged with sufficient user context to identify suspicious or malicious
+  accounts and held for enough time to allow delayed forensic analysis.
+- Ensure that logs are generated in a format that log management solutions can
+  easily consume.
+- Ensure log data is encoded correctly to prevent injections or attacks on the
+  logging or monitoring systems.
+- Ensure high-value transactions have an audit trail with integrity controls to
+  prevent tampering or deletion, such as append-only database tables or similar.
+- DevSecOps teams should establish effective monitoring and alerting such that
+  suspicious activities are detected and responded to quickly.
+- Establish or adopt an incident response and recovery plan, such as National
+  Institute of Standards and Technology (NIST) 800-61r2 or later.
+
+There are commercial and open-source application protection frameworks such as
+the OWASP ModSecurity Core Rule Set, and open-source log correlation software,
+such as the Elasticsearch, Logstash, Kibana (ELK) stack, that feature custom
+dashboards and alerting.
 
 CodeIgniter provisions
 ======================
 
-- @TODO
+- :doc:`Logging <../general/logging>` library
+- An official authentication and authorization framework
+  :ref:`CodeIgniter Shield <shield>`
 
 *******************************************
 A10:2021 Server-Side Request Forgery (SSRF)
 *******************************************
 
-@TODO
+SSRF flaws occur whenever a web application is fetching a remote resource without
+validating the user-supplied URL. It allows an attacker to coerce the application
+to send a crafted request to an unexpected destination, even when protected by a
+firewall, VPN, or another type of network access control list (ACL).
+
+As modern web applications provide end-users with convenient features, fetching
+a URL becomes a common scenario. As a result, the incidence of SSRF is increasing.
+Also, the severity of SSRF is becoming higher due to cloud services and the
+complexity of architectures.
 
 OWASP recommendations
 =====================
 
-- @TODO
+Developers can prevent SSRF by implementing some or all the following defense in
+depth controls:
+
+From Network layer:
+
+- Segment remote resource access functionality in separate networks to reduce the
+  impact of SSRF
+- Enforce “deny by default” firewall policies or network access control rules to
+  block all but essential intranet traffic.
+
+   - Hints:
+
+      * Establish an ownership and a lifecycle for firewall rules based on
+        applications.
+      * Log all accepted and blocked network flows on firewalls
+        (see A09:2021-Security Logging and Monitoring Failures).
+
+From Application layer:
+
+- Sanitize and validate all client-supplied input data
+- Enforce the URL schema, port, and destination with a positive allow list
+- Do not send raw responses to clients
+- Disable HTTP redirections
+- Be aware of the URL consistency to avoid attacks such as DNS rebinding and
+  “time of check, time of use” (TOCTOU) race conditions
+
+Do not mitigate SSRF via the use of a deny list or regular expression. Attackers
+have payload lists, tools, and skills to bypass deny lists.
 
 CodeIgniter provisions
 ======================
 
-- @TODO
+- :doc:`../libraries/validation` library
+- :doc:`HTTP library <../incoming/incomingrequest>` provides for
+  :ref:`input field filtering <incomingrequest-filtering-input-data>`