Skip to content

Latest commit

 

History

History
86 lines (73 loc) · 9.43 KB

attack-surface.md

File metadata and controls

86 lines (73 loc) · 9.43 KB

Attack Surface Analysis for ory/kratos

Attack Surface: 1. Misconfigured Identity Schema

  • Description: The identity schema defines the structure and attributes of user identities. Errors or overly permissive configurations in this schema can lead to significant vulnerabilities, directly within Kratos's core functionality.
  • How Kratos Contributes: Kratos's core functionality relies on the identity schema. Its flexibility, while powerful, introduces the risk of misconfiguration within Kratos itself.
  • Example: A schema allows users to modify a role trait via a self-service profile update (managed by Kratos), without proper validation or authorization checks. A user changes their role from "user" to "admin".
  • Impact: Privilege escalation, data leakage, account takeover, denial of service.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Schema Validation: Use Kratos's built-in JSON Schema validation to enforce the structure and data types of the schema.
    • Least Privilege: Design the schema with the principle of least privilege within Kratos. Only allow users to modify traits that are absolutely necessary through Kratos's interfaces.
    • Access Control: Implement strict access control on schema modification within Kratos. Only authorized administrators should be able to change the schema through Kratos's administrative APIs.
    • Auditing: Regularly audit the schema and its usage within Kratos to identify potential issues. Log all schema changes made through Kratos.
    • Input Validation: Even if a trait is modifiable through Kratos, validate all user-provided input to prevent malicious data. Use Kratos's validation features.
    • Pre/Post Hooks: Use Kratos's pre- and post-hooks for flows (like registration or profile update) to perform additional validation and authorization checks within Kratos's execution context before committing changes to the identity.

Attack Surface: 2. Weak or Default Secrets (Specifically secrets.cookie and secrets.cipher)

  • Description: Kratos uses secrets for critical functions like encrypting cookies (secrets.cookie) and encrypting/decrypting data at rest (secrets.cipher). Weak, default, or exposed secrets directly compromise Kratos's security.
  • How Kratos Contributes: These secrets are fundamental to Kratos's operation and security model. Kratos uses these secrets directly.
  • Example: The default secrets.cookie value is used in a production deployment. An attacker finds this default value in the documentation and uses it to forge valid session cookies, hijacking user sessions managed by Kratos.
  • Impact: Session hijacking, data decryption (if secrets.cipher is compromised), impersonation of Kratos services.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Strong Secrets: Generate strong, random secrets using a cryptographically secure random number generator before deploying Kratos.
    • Secrets Management: Use a dedicated secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager) to store and manage these secrets outside of Kratos's configuration files.
    • Rotation: Implement a process for regularly rotating these secrets, updating Kratos's configuration accordingly.
    • Environment Variables: Use environment variables to inject secrets into the Kratos process, avoiding hardcoding in Kratos's configuration.
    • Configuration File Permissions: If using configuration files, ensure they have strict permissions (read-only by the Kratos process) to protect the secrets used by Kratos.

Attack Surface: 3. Brute-Force and Credential Stuffing Attacks (Against Kratos's Login Flow)

  • Description: Attackers attempt to guess passwords or use lists of compromised credentials to gain access to accounts through Kratos's login flow.
  • How Kratos Contributes: Kratos's login flow is the direct target of these attacks. The vulnerability lies in how Kratos handles authentication attempts.
  • Example: An attacker uses a list of common passwords to try to log in to multiple accounts via Kratos's /sessions/whoami or login API endpoints.
  • Impact: Account takeover.
  • Risk Severity: High
  • Mitigation Strategies:
    • Rate Limiting: Implement strict rate limiting on Kratos's login flow, based on IP address, user, or other factors, using Kratos's built-in rate-limiting capabilities.
    • CAPTCHA: Use a CAPTCHA integrated with Kratos's login flow to distinguish between human users and automated bots.
    • Multi-Factor Authentication (MFA): Strongly recommended. Utilize Kratos's built-in MFA support to significantly reduce the risk.
    • Password Policies: Enforce strong password policies (minimum length, complexity requirements) within Kratos's identity schema and validation rules.
    • Account Lockout: Lock accounts after a certain number of failed login attempts using Kratos's account locking features. Be mindful of potential denial-of-service.
    • Monitoring: Monitor Kratos's logs for patterns of failed login attempts.

Attack Surface: 4. Unvalidated Webhooks (Sent by Kratos)

  • Description: Kratos can send webhooks to external services. If these webhooks are not properly validated by the receiving service, attackers can forge requests. The vulnerability is in the receiving service, but Kratos is the sender.
  • How Kratos Contributes: Kratos initiates the webhook communication. The lack of validation on the receiving end is the primary issue, but Kratos's configuration determines what is sent and when.
  • Example: An attacker discovers the webhook URL for a post-registration hook (sent by Kratos) and sends a forged request to create a new administrator account in a connected system.
  • Impact: Unauthorized actions in connected systems, data manipulation, potential for wider system compromise.
  • Risk Severity: High
  • Mitigation Strategies:
    • Signature Verification: Crucially important. Configure Kratos to sign webhooks using a shared secret. The receiving service must verify the signature. This is a Kratos configuration setting.
    • HTTPS: Configure Kratos to use HTTPS for all webhook communication.
    • Input Validation: While primarily the receiver's responsibility, consider what data Kratos is sending in the webhook. Minimize sensitive data.

Attack Surface: 5. Insecure Third-Party Integrations (Misconfigured within Kratos)

  • Description: Vulnerabilities in third-party identity providers or misconfigurations in the integration within Kratos can compromise Kratos users.
  • How Kratos Contributes: Kratos's configuration for integrating with third-party providers (OIDC, Social Login) is the direct point of vulnerability.
  • Example: A misconfigured OAuth 2.0 flow with a social login provider, due to incorrect settings within Kratos's configuration, allows an attacker to obtain a valid access token.
  • Impact: Account takeover, data leakage.
  • Risk Severity: High
  • Mitigation Strategies:
    • Provider Selection: Choose reputable providers. (Not directly a Kratos mitigation, but important context).
    • Configuration Review: Carefully review and test the integration configuration within Kratos. Follow the provider's and Kratos's documentation precisely.
    • Token Handling: Ensure Kratos is configured to handle access tokens, refresh tokens, and ID tokens securely, according to best practices and Kratos's documentation.
    • Scope Limitation: Request only the minimum necessary scopes (permissions) from the third-party provider within Kratos's configuration.
    • Regular Updates: Keep Kratos and any related integration libraries up-to-date.

Attack Surface: 6. Outdated Kratos Version

  • Description: Running an outdated version of Kratos exposes the application to known vulnerabilities that have been patched in newer releases. This is entirely about the Kratos version.
  • How Kratos Contributes: This is directly related to the version of Kratos being used. The vulnerability exists within Kratos itself.
  • Example: An older version of Kratos has a known vulnerability in its session management that allows for session hijacking. An attacker exploits this vulnerability in Kratos.
  • Impact: Varies depending on the specific vulnerability, but can range from denial-of-service to remote code execution and complete system compromise.
  • Risk Severity: High to Critical (depending on the vulnerability)
  • Mitigation Strategies:
    • Regular Updates: Update Kratos to the latest stable version.
    • Security Advisories: Subscribe to Kratos's security advisories.
    • Testing: Thoroughly test updates before deploying.
    • Rollback Plan: Have a plan to roll back.
    • Dependency Management: Keep track of Kratos's dependencies.