diff --git a/user_guide_src/source/concepts/security.rst b/user_guide_src/source/concepts/security.rst index 69f2221a644f..6d8f5839e8f3 100644 --- a/user_guide_src/source/concepts/security.rst +++ b/user_guide_src/source/concepts/security.rst @@ -10,18 +10,22 @@ We respect the `Open Web Application Security Project (OWASP) `_, -identifying the top vulnerabilities for web applications. +`OWASP Top Ten `_ and +`OWASP API Security Top 10 `_ +identifying the top vulnerabilities for web applications and apis. For each, we provide a brief description, the OWASP recommendations, and then the CodeIgniter provisions to address the problem. .. contents:: :local: - :depth: 1 + :depth: 2 + +***************** +OWASP Top 10 2021 +***************** -****************************** A01:2021 Broken Access Control -****************************** +============================== Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, @@ -49,7 +53,7 @@ Common access control vulnerabilities include: pages as a standard user. OWASP recommendations -===================== +--------------------- Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. @@ -71,7 +75,7 @@ where the attacker cannot modify the access control check or metadata. follow the OAuth standards to revoke access. CodeIgniter provisions -====================== +---------------------- - :ref:`Public ` folder, with application and system outside @@ -83,9 +87,8 @@ CodeIgniter provisions - An official authentication and authorization framework :ref:`CodeIgniter Shield ` - Easy to add third party authentication -******************************* A02:2021 Cryptographic Failures -******************************* +=============================== The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal @@ -123,7 +126,7 @@ or regulations, e.g., financial data protection such as PCI Data Security Standa example in the form of padding oracle attacks? OWASP recommendations -===================== +--------------------- Do the following, at a minimum, and consult the references: @@ -161,7 +164,7 @@ Do the following, at a minimum, and consult the references: - Verify independently the effectiveness of configuration and settings. CodeIgniter provisions -====================== +---------------------- - The config for global secure access (``Config\App::$forceGlobalSecureRequests``) - :php:func:`force_https()` function @@ -170,9 +173,8 @@ CodeIgniter provisions - An official authentication and authorization framework :ref:`CodeIgniter Shield ` -****************** A03:2021 Injection -****************** +================== An application is vulnerable to attack when: @@ -194,7 +196,7 @@ dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment. OWASP recommendations -===================== +--------------------- Preventing injection requires keeping data separate from commands and queries: @@ -218,7 +220,7 @@ Preventing injection requires keeping data separate from commands and queries: records in case of SQL injection. CodeIgniter provisions -====================== +---------------------- - :ref:`urls-uri-security` - :ref:`invalidchars` filter @@ -231,9 +233,8 @@ CodeIgniter provisions - :ref:`Database escape methods ` - :ref:`database-queries-query-bindings` -************************ A04:2021 Insecure Design -************************ +======================== Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for @@ -249,7 +250,7 @@ lack of business risk profiling inherent in the software or system being develop and thus the failure to determine what level of security design is required. OWASP recommendations -===================== +--------------------- - Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls @@ -269,15 +270,14 @@ OWASP recommendations - Limit resource consumption by user or service CodeIgniter provisions -====================== +---------------------- - :doc:`PHPUnit testing <../testing/overview>` - :doc:`../libraries/throttler` for rate limit - An official authentication and authorization framework :ref:`CodeIgniter Shield ` -********************************** A05:2021 Security Misconfiguration -********************************** +================================== The application might be vulnerable if the application is: @@ -301,7 +301,7 @@ Without a concerted, repeatable application security configuration process, systems are at a higher risk. OWASP recommendations -===================== +--------------------- Secure installation processes should be implemented, including: @@ -323,14 +323,13 @@ Secure installation processes should be implemented, including: settings in all environments. CodeIgniter provisions -====================== +---------------------- - :ref:`Production mode ` by default - :ref:`secureheaders` filter -******************************************* A06:2021 Vulnerable and Outdated Components -******************************************* +=========================================== You are likely vulnerable: @@ -352,7 +351,7 @@ You are likely vulnerable: Misconfiguration). OWASP recommendations -===================== +--------------------- There should be a patch management process in place to: @@ -378,13 +377,12 @@ applying updates or configuration changes for the lifetime of the application or portfolio. CodeIgniter provisions -====================== +---------------------- - Easy :ref:`app-starter-upgrading` by Composer -*************************************************** A07:2021 Identification and Authentication Failures -*************************************************** +=================================================== Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. There may be @@ -406,7 +404,7 @@ authentication weaknesses if the application: or a period of inactivity. OWASP recommendations -===================== +--------------------- - Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks. @@ -427,15 +425,14 @@ OWASP recommendations timeouts. CodeIgniter provisions -====================== +---------------------- - :doc:`Session <../libraries/sessions>` library - An official authentication and authorization framework :ref:`CodeIgniter Shield ` -********************************************* A08:2021 Software and Data Integrity Failures -********************************************* +============================================= 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 @@ -452,7 +449,7 @@ Another example is where objects or data are encoded or serialized into a struct that an attacker can see and modify is vulnerable to insecure deserialization. OWASP recommendations -===================== +--------------------- - Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered. @@ -473,13 +470,12 @@ OWASP recommendations tampering or replay of the serialized data CodeIgniter provisions -====================== +---------------------- - n/a -************************************************* A09:2021 Security Logging and Monitoring Failures -************************************************* +================================================= This category is to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, @@ -501,7 +497,7 @@ 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 -===================== +--------------------- Developers should implement some or all the following controls, depending on the risk of the application: @@ -525,15 +521,14 @@ such as the Elasticsearch, Logstash, Kibana (ELK) stack, that feature custom dashboards and alerting. CodeIgniter provisions -====================== +---------------------- - :doc:`Logging <../general/logging>` library - An official authentication and authorization framework :ref:`CodeIgniter Shield ` -******************************************* A10:2021 Server-Side Request Forgery (SSRF) -******************************************* +=========================================== 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 @@ -546,7 +541,7 @@ Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures. OWASP recommendations -===================== +--------------------- Developers can prevent SSRF by implementing some or all the following defense in depth controls: @@ -578,8 +573,361 @@ 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 -====================== +---------------------- + +- :doc:`../libraries/validation` library +- :doc:`HTTP library <../incoming/incomingrequest>` provides for + :ref:`input field filtering ` + +****************************** +OWASP API Security Top 10 2023 +****************************** + +API1:2023 Broken Object Level Authorization +=========================================== + +APIs tend to expose endpoints that handle object identifiers, creating a wide +attack surface of Object Level Access Control issues. Object level authorization +checks should be considered in every function that accesses a data source using +an ID from the user. + +OWASP recommendations +--------------------- + +- Implement a proper authorization mechanism that relies on the user policies and + hierarchy. +- Use the authorization mechanism to check if the logged-in user has access to + perform the requested action on the record in every function that uses an input + from the client to access a record in the database. +- Prefer the use of random and unpredictable values as GUIDs for records' IDs. +- Write tests to evaluate the vulnerability of the authorization mechanism. Do + not deploy changes that make the tests fail. + +CodeIgniter provisions +---------------------- + +- An official authentication and authorization framework + :ref:`CodeIgniter Shield ` + +API2:2023 Broken Authentication +=============================== + +Authentication mechanisms are often implemented incorrectly, allowing attackers +to compromise authentication tokens or to exploit implementation flaws to assume +other user's identities temporarily or permanently. Compromising a system's +ability to identify the client/user, compromises API security overall. + +OWASP recommendations +--------------------- + +- Make sure you know all the possible flows to authenticate to the API (mobile/ + web/deep links that implement one-click authentication/etc.). Ask your engineers + what flows you missed. +- Read about your authentication mechanisms. Make sure you understand what and + how they are used. OAuth is not authentication, and neither are API keys. +- Don't reinvent the wheel in authentication, token generation, or password storage. + Use the standards. +- Credential recovery/forgot password endpoints should be treated as login + endpoints in terms of brute force, rate limiting, and lockout protections. +- Require re-authentication for sensitive operations (e.g. changing the account + owner email address/2FA phone number). +- Use the OWASP Authentication Cheatsheet. +- Where possible, implement multi-factor authentication. +- Implement anti-brute force mechanisms to mitigate credential stuffing, dictionary + attacks, and brute force attacks on your authentication endpoints. This mechanism + should be stricter than the regular rate limiting mechanisms on your APIs. +- Implement account lockout/captcha mechanisms to prevent brute force attacks + against specific users. Implement weak-password checks. +- API keys should not be used for user authentication. They should only be used + for API clients authentication. + +CodeIgniter provisions +---------------------- + +- An official authentication and authorization framework + :ref:`CodeIgniter Shield ` + +API3:2023 Broken Object Property Level Authorization +==================================================== + +This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass +Assignment, focusing on the root cause: the lack of or improper authorization +validation at the object property level. This leads to information exposure or +manipulation by unauthorized parties. + +OWASP recommendations +--------------------- + +- When exposing an object using an API endpoint, always make sure that the user + should have access to the object's properties you expose. +- Avoid using generic methods such as to_json() and to_string(). Instead, + cherry-pick specific object properties you specifically want to return. +- If possible, avoid using functions that automatically bind a client's input + into code variables, internal objects, or object properties ("Mass Assignment"). +- Allow changes only to the object's properties that should be updated by the + client. +- Implement a schema-based response validation mechanism as an extra layer of + security. As part of this mechanism, define and enforce data returned by all + API methods. +- Keep returned data structures to the bare minimum, according to the + business/functional requirements for the endpoint. + +CodeIgniter provisions +---------------------- + +- Model's :ref:`model-allowed-fields` +- An official authentication and authorization framework + :ref:`CodeIgniter Shield ` + +API4:2023 Unrestricted Resource Consumption +=========================================== + +Satisfying API requests requires resources such as network bandwidth, CPU, memory, +and storage. Other resources such as emails/SMS/phone calls or biometrics validation +are made available by service providers via API integrations, and paid for per +request. Successful attacks can lead to Denial of Service or an increase of +operational costs. + +OWASP recommendations +--------------------- + +- Use a solution that makes it easy to limit memory, CPU, number of restarts, + file descriptors, and processes such as Containers / Serverless code (e.g. Lambdas). +- Define and enforce a maximum size of data on all incoming parameters and payloads, + such as maximum length for strings, maximum number of elements in arrays, and + maximum upload file size (regardless of whether it is stored locally or in + cloud storage). +- Implement a limit on how often a client can interact with the API within a + defined timeframe (rate limiting). +- Rate limiting should be fine tuned based on the business needs. Some API Endpoints + might require stricter policies. +- Limit/throttle how many times or how often a single API client/user can execute + a single operation (e.g. validate an OTP, or request password recovery without + visiting the one-time URL). +- Add proper server-side validation for query string and request body parameters, + specifically the one that controls the number of records to be returned in the + response. +- Configure spending limits for all service providers/API integrations. When setting + spending limits is not possible, billing alerts should be configured instead. + +CodeIgniter provisions +---------------------- + +- :doc:`../libraries/validation` library +- :doc:`../libraries/throttler` for rate limit + +API5:2023 Broken Function Level Authorization +============================================= + +Complex access control policies with different hierarchies, groups, and roles, +and an unclear separation between administrative and regular functions, tend to +lead to authorization flaws. By exploiting these issues, attackers can gain +access to other users’ resources and/or administrative functions. + +OWASP recommendations +--------------------- + +Your application should have a consistent and easy-to-analyze authorization module +that is invoked from all your business functions. Frequently, such protection is +provided by one or more components external to the application code. + +- The enforcement mechanism(s) should deny all access by default, requiring explicit + grants to specific roles for access to every function. +- Review your API endpoints against function level authorization flaws, while + keeping in mind the business logic of the application and groups hierarchy. +- Make sure that all of your administrative controllers inherit from an + administrative abstract controller that implements authorization checks based + on the user's group/role. +- Make sure that administrative functions inside a regular controller implement + authorization checks based on the user's group and role. + +CodeIgniter provisions +---------------------- + +- An official authentication and authorization framework + :ref:`CodeIgniter Shield ` + +API6:2023 Unrestricted Access to Sensitive Business Flows +========================================================= + +APIs vulnerable to this risk expose a business flow - such as buying a ticket, +or posting a comment - without compensating for how the functionality could harm +the business if used excessively in an automated manner. This doesn't necessarily +come from implementation bugs. + +OWASP recommendations +--------------------- + +The mitigation planning should be done in two layers: + +- Business - identify the business flows that might harm the business if they + are excessively used. +- Engineering - choose the right protection mechanisms to mitigate the business + risk. + +Some of the protection mechanisms are more simple while others are more difficult +to implement. The following methods are used to slow down automated threats: + +- Device fingerprinting: denying service to unexpected client devices (e.g + headless browsers) tends to make threat actors use more sophisticated solutions, + thus more costly for them +- Human detection: using either captcha or more advanced biometric solutions + (e.g. typing patterns) +- Non-human patterns: analyze the user flow to detect non-human patterns + (e.g. the user accessed the "add to cart" and "complete purchase" functions in + less than one second) +- Consider blocking IP addresses of Tor exit nodes and well-known proxies + +Secure and limit access to APIs that are consumed directly by machines (such as +developer and B2B APIs). They tend to be an easy target for attackers because +they often don't implement all the required protection mechanisms. + +CodeIgniter provisions +---------------------- + +- n/a + +API7:2023 Server Side Request Forgery +===================================== + +Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a +remote resource without validating the user-supplied URI. This enables an attacker +to coerce the application to send a crafted request to an unexpected destination, +even when protected by a firewall or a VPN. + +OWASP recommendations +--------------------- + +- Isolate the resource fetching mechanism in your network: usually these features + are aimed to retrieve remote resources and not internal ones. +- Whenever possible, use allow lists of: + + - Remote origins users are expected to download resources from (e.g. Google Drive, + Gravatar, etc.) + - URL schemes and ports + - Accepted media types for a given functionality +- Disable HTTP redirections. +- Use a well-tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies. +- Validate and sanitize all client-supplied input data. +- Do not send raw responses to clients. + +CodeIgniter provisions +---------------------- - :doc:`../libraries/validation` library - :doc:`HTTP library <../incoming/incomingrequest>` provides for :ref:`input field filtering ` +- :doc:`CURLRequest <../libraries/curlrequest>` class +- :doc:`URI <../libraries/uri>` class + +API8:2023 Security Misconfiguration +=================================== + +APIs and the systems supporting them typically contain complex configurations, +meant to make the APIs more customizable. Software and DevOps engineers can miss +these configurations, or don't follow security best practices when it comes to +configuration, opening the door for different types of attacks. + +OWASP recommendations +--------------------- + +The API life cycle should include: + +- A repeatable hardening process leading to fast and easy deployment of a properly + locked down environment +- A task to review and update configurations across the entire API stack. The + review should include: orchestration files, API components, and cloud services + (e.g. S3 bucket permissions) +- An automated process to continuously assess the effectiveness of the configuration + and settings in all environments + +Furthermore: + +- Ensure that all API communications from the client to the API server and any + downstream/upstream components happen over an encrypted communication channel + (TLS), regardless of whether it is an internal or public-facing API. +- Be specific about which HTTP verbs each API can be accessed by: all other HTTP + verbs should be disabled (e.g. HEAD). +- APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) + should, at least: + + - implement a proper Cross-Origin Resource Sharing (CORS) policy + - include applicable Security Headers +- Restrict incoming content types/data formats to those that meet the business/ + functional requirements. +- Ensure all servers in the HTTP server chain (e.g. load balancers, reverse and + forward proxies, and back-end servers) process incoming requests in a uniform + manner to avoid desync issues. +- Where applicable, define and enforce all API response payload schemas, including + error responses, to prevent exception traces and other valuable information from + being sent back to attackers. + +CodeIgniter provisions +---------------------- + +- The config for global secure access (``Config\App::$forceGlobalSecureRequests``) +- :php:func:`force_https()` function +- :ref:`Defined Route Routing ` +- :ref:`auto-routing-improved` + +API9:2023 Improper Inventory Management +======================================= + +APIs tend to expose more endpoints than traditional web applications, making +proper and updated documentation highly important. A proper inventory of hosts +and deployed API versions also are important to mitigate issues such as deprecated +API versions and exposed debug endpoints. + +OWASP recommendations +--------------------- + +- Inventory all API hosts and document important aspects of each one of them, + focusing on the API environment (e.g. production, staging, test, development), + who should have network access to the host (e.g. public, internal, partners) + and the API version. +- Inventory integrated services and document important aspects such as their + role in the system, what data is exchanged (data flow), and their sensitivity. +- Document all aspects of your API such as authentication, errors, redirects, + rate limiting, cross-origin resource sharing (CORS) policy, and endpoints, + including their parameters, requests, and responses. +- Generate documentation automatically by adopting open standards. Include the + documentation build in your CI/CD pipeline. +- Make API documentation available only to those authorized to use the API. +- Use external protection measures such as API security specific solutions for + all exposed versions of your APIs, not just for the current production version. +- Avoid using production data with non-production API deployments. If this is + unavoidable, these endpoints should get the same security treatment as the + production ones. +- When newer versions of APIs include security improvements, perform a risk + analysis to inform the mitigation actions required for the older versions. For + example, whether it is possible to backport the improvements without breaking + API compatibility or if you need to take the older version out quickly and + force all clients to move to the latest version. + +CodeIgniter provisions +---------------------- + +- :ref:`routing-spark-routes` command + +API10:2023 Unsafe Consumption of APIs +===================================== + +Developers tend to trust data received from third-party APIs more than user input, +and so tend to adopt weaker security standards. In order to compromise APIs, +attackers go after integrated third-party services instead of trying to compromise +the target API directly. + +OWASP recommendations +--------------------- + +- When evaluating service providers, assess their API security posture. +- Ensure all API interactions happen over a secure communication channel (TLS). +- Always validate and properly sanitize data received from integrated APIs before + using it. +- Maintain an allowlist of well-known locations integrated APIs may redirect yours + to: do not blindly follow redirects. + +CodeIgniter provisions +---------------------- + +- :doc:`../libraries/validation` library diff --git a/user_guide_src/source/models/model.rst b/user_guide_src/source/models/model.rst index 41a754bc25ee..ce561e0be810 100644 --- a/user_guide_src/source/models/model.rst +++ b/user_guide_src/source/models/model.rst @@ -151,6 +151,8 @@ configured to any name of your choice by using `$deletedField`_ property. .. important:: The ``deleted_at`` field in the database must be nullable. +.. _model-allowed-fields: + $allowedFields --------------