application_security/authentication

146 notes in this subject, read out of this brain and free to use. This is page 1 of 3.

Rails access control with cancancan or pundit

Use resource-based access control libraries like cancancan (cancan replacement) or pundit to prevent Insecure Direct Object Reference attacks. These ensure all operations on database objects are authorized by application business logic rather than relying on hand-coded controller checks.

Rails password complexity with zxcvbn gem

Use devise_zxcvbn gem for password complexity enforcement. Add :zxcvbnable to Devise configuration in User model. Set minimum complexity score in config/initializers/devise.rb: config.min_password_score = 4

Rails token-based authentication with devise_token_auth

For token authentication instead of cookies, use devise_token_auth gem which supports multiple front-end technologies. Install with 'gem devise_token_auth' and 'gem omniauth'. Define route: mount_devise_token_auth_for 'User', at: 'auth'. When using only token authentication, CSRF protection is not needed in controllers.

Rails password hashing with bcrypt via Devise

Devise uses bcrypt for password hashing by default. Configure stretches in config/initializers/devise.rb: config.stretches = Rails.env.test? ? 1 : 10. This applies 10 stretches in production for appropriate security.

Rails Devise authentication gem setup

Install Devise gem with 'gem devise', run 'rails generate devise:install', then wrap protected routes with authenticate :user block. Example: Rails.application.routes.draw do authenticate :user do resources :something end devise_for :users root to: 'static#home' end

Signed URLs for object storage pros and cons

Signed URLs for object storage use cryptographically guaranteed URLs for access to specific resources. Best used when direct access to specific user files is necessary and data is not very sensitive. Pros: Access to only one resource, minimal user visibility to object storage, efficient file transfer. Cons: Anonymous access possible, anyone can access with URL, possibility of injection with custom code.

IAM Access to object storage pros and cons

IAM Access for object storage involves indirect access through managed or self-managed service running on infrastructure containing persistent control plane IAM credentials. Pros: No direct access to data, no user visibility to object storage, identifiable and loggable access. Cons: Potential use of broad IAM policy, credential loss gives access to control plane APIs, credentials could be hardcoded.

Authentication definition and factors

Authentication is the process of verifying who a user is. It answers the question "Who are you?". Authentication factors include something you know (password), something you have (token), and something you are (biometrics).

Federated identity terms: Identity Provider, Relying Party, Service Provider, Principal

Identity Provider (IdP) is the system that creates, maintains, and manages identity information and provides authentication services, with examples being Google, Okta, and Azure AD. Relying Party (RP) is an application or service that relies on an IdP to authenticate users, such as a web app using Login with Google. Service Provider (SP) is the SAML equivalent of a Relying Party, used in enterprise apps with SAML. Principal is the entity being authenticated, which can be a user, service, or device.

Authorization definition and timing

Authorization is the process of verifying what a user has permission to do. It answers the question "Are you allowed to do this?". Authorization occurs after successful authentication. Examples include Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

Good IAM Policy for serverless: scoped actions and resource

A properly scoped IAM policy example: {"Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"}. This restricts permissions to only GetItem and PutItem operations on a specific DynamoDB table.

Bad IAM Policy for serverless: wildcard effect, action, resource

An overly permissive IAM policy that should never be used: {"Effect": "Allow", "Action": "*", "Resource": "*"}. This grants unrestricted access to all AWS services and resources.

Secure function invocation: enforce authentication on all triggers, validate function-to-function calls, apply rate limiting

Enforce authentication and authorization on all triggers including API Gateway, Pub/Sub, S3, and IoT. Validate function-to-function calls with signed tokens or workload identities. Apply rate limiting and throttling to mitigate denial-of-service and abuse attacks.

API Gateway Authorizer for JWT validation

API Gateway authorizer configuration for JWT validation: Type is "JWT", IdentitySource is "$request.header.Authorization", Issuer is "https://secure-idp.example.com/", and Audience is "my-api-client".

Principle of Least Privilege for serverless IAM: role-per-function, minimal permissions, scoped resources

Assign minimal IAM permissions to each serverless function. Use a role-per-function approach to avoid shared high-privilege roles. Scope database and API keys to the smallest set of actions needed. Bad example: allowing Action "*" on Resource "*". Good example: allowing only ["dynamodb:GetItem", "dynamodb:PutItem"] on a specific DynamoDB table ARN.

Implement Strong Access Control for SSC

Compromised accounts, particularly privileged ones, represent a significant threat to SSCs. Account takeover allows attackers to inject code into dependencies, manipulate CI/CD pipeline execution, and replace benign artifacts with malicious ones. Best practices include adhering to least privilege and separation of duties principles, enforcing MFA, rotating credentials, and ensuring credentials are never stored or transmitted in clear text or committed to source control.

Symfony access control configuration

Access control rules determine which users can access specific application parts. Rules are configured under 'access_control' key with 'path' (URL pattern) and 'roles' (required role or PUBLIC_ACCESS) parameters.

Entity User Provider configuration

Entity User Provider uses Doctrine to fetch users by unique identifier. Configuration syntax: providers -> app_user_provider -> entity with 'class' (User entity class) and 'property' (unique property like 'email').

Symfony firewall configuration structure

Firewalls define security configurations for different application sections. Configuration includes: pattern (URL pattern to match), security (enable/disable), lazy (lazy authentication), provider (user provider to use), custom_authenticator (custom authentication class), logout (logout configuration).

Symfony authentication configuration location

Symfony Security authentication settings are configured in config/packages/security.yaml. Configuration includes three main sections: Providers, Firewalls, and Access Control.

OAuth/SSO redirect URI validation to prevent subdomain takeover

Do not whitelist entire subdomain patterns in redirect URI validations. Use exact-match redirect URIs. A taken-over subdomain in an OAuth redirect allowlist enables token theft and session compromise.

Cookie scoping to prevent subdomain takeover impact

Do not scope session cookies to the parent domain (`.example.com`) unless necessary. Prefer setting cookies on the specific fully qualified subdomain (`app.example.com`). Use the `__Host-` cookie prefix where possible, which restricts the cookie to the exact origin.

What You See Is What You Sign (WYSIWS) principle

An authorization method must permit a user to identify and acknowledge all significant transaction data. For example, in a wire transfer, the user must be able to identify the target account and amount. Developers should base decisions about which data is significant on the real risk, technical capabilities and constraints of the chosen authorization method, and user experience.

Confirm specific transaction values during authorization

If a transaction process requires a user to enter transaction data into an external device, the user should be prompted to confirm a specific value in the transaction, such as a target account number. The absence of a meaningful prompt can be easily abused by social engineering and malware attacks.

Transaction authorization methods

Transaction authorizations can be implemented using: a card with a transaction authorization number, time-based one-time password (OATH TOTP), out-of-band OTP sent by SMS or phone, digital signature from a smart card or smartphone, or challenge-response tokens including unconnected card readers or screen-scanning solutions. These can be implemented with physical devices or mobile applications.

Authorization token change requires current authorization

If a user can change their authorization token through the application interface, they must authorize the change operation with their current authorization credentials. For example, when a user changes a phone number for SMS codes, an authorization SMS code should be sent to the current phone number.

Transaction authorization definition and scope

A transaction authorization is a second factor or secondary verification that a system uses to check whether a user is authorized to perform a sensitive operation. Transaction authorizations are commonly used in financial systems for operations like wire transfers, but the need for secure transactions has driven adoption across the internet, including email account unlocking with secret codes or tokens.

User training for transaction authorization data verification

Users should be trained to rewrite transaction data from a trusted source and not from the computer screen when typing significant transaction data into an authorization component, such as an external dedicated device or mobile application.

Authorization method change must use current method

When an application allows users to choose how their transactions will be authorized, the application must confirm the user's method of authorization using that current method to prevent malware from changing to a more vulnerable authorization method. The application should also inform users about potential dangers associated with their chosen authorization method.

Distinguish authentication from transaction authorization

Applications should not require a user to perform the same actions for authentication and transaction authorization. If the same method is used for both, malware can present a false error message on authentication to trick the user into repeating the procedure, allowing the malware to use the first credential for authentication and the second for a fraudulent transaction.

Unique authorization credentials for each operation

Each set of authorization credentials must be unique for every operation to prevent replay attacks. Credentials can be generated using different methods depending on the mechanism, such as a timestamp, sequence number, or random value in signed transaction data or as part of a challenge.

Limited time validity for authorization credentials

Server should only allow transaction authorization to occur in a limited time window between the generation of a challenge or OTP and the completion of authorization. This prevents attacks where authorization credentials are passed by malware to a command-and-control server and used from an attacker-controlled machine, and helps stop resource exhaustion attacks. The time period should be carefully selected to avoid disrupting normal user behavior.

Final control gate before transaction execution

There should be a final control gate before transaction execution which verifies whether the transaction was properly authorized by the user. This control must be tied to execution and prevent attacks such as Time of Check to Time of Use (TOCTOU) and skipping authorization checks in the transaction entry process. See OWASP ASVS requirement 15.1.

Prevent transaction data modification during authorization

Developers must not allow attackers to modify transaction data when the user enters the data for the first time. Malware could replay the transaction data step in the background before the user enters authorization credentials and overwrite transaction details with a fraudulent transaction. Alternatively, an attacker could add new transaction data parameters to the HTTP request during authorization, causing a poorly implemented process to authorize the initial transaction and then execute a fraudulent one.

Transaction authorization state machine enforcement

Developers must ensure that transaction authorization occurs in sequential order across these steps: user enters transaction data, user requests authorization, application initializes authorization mechanism, user verifies transaction data, user responds with authorization credentials, and application validates and executes the transaction. Users or attackers cannot perform steps out of order or skip steps.

Prevent authorization credential brute-forcing

After a set number of failed authorization attempts, the entire transaction authorization process should be restarted to prevent attackers from brute-forcing transaction authorization credentials. Other methods to prevent brute-forcing and automation-related techniques are described in the OWASP Authentication Cheat Sheet.

Prevent faked transaction data from client-side collection

When developers collect significant transaction data on the client side and pass it to the server, malware could manipulate the data and show faked transaction data in an authorization component. Server-side generation of transaction verification data prevents this attack.

Generate transaction verification data server-side

All significant transaction data must be generated and stored on the server, then passed to an authorization component without any possibility of tampering by the client. When developers transmit significant transaction data programmatically to an authorization component, they must take extra care to prevent client modifications.

Avoid authorization method downgrades in codebase updates

When adding a new authorization method that enhances security, developers should not build it on top of an old codebase. This is insecure because an attacker could manipulate a client to authorize a transaction using parameters from the old, less secure method despite the application switching to a new method.

Enforce chosen authorization method server-side

If multiple transaction authorization methods are available to the user, the server must ensure that the transaction occurs with either the user's chosen authorization method or the method enforced by application policies. Otherwise, malware could downgrade an authorization method to a less secure one. Developers must make it impossible for attackers to change the authorization method by manipulating client parameters.

Encrypt transaction data for confidentiality and integrity

To prevent tampering with transaction data, developers should consider encrypting the data for both confidentiality and integrity, then decrypting and verifying the data on the server side.

Methods to prevent transaction data modification

Transaction data modification can be prevented by: invalidating any previously entered authorization data (such as generated OTP) and the challenge if transaction data is modified, triggering a reset of the authorization process if modifications occur, or logging and monitoring any attempt to modify transaction data after user entry as a system attack.

Server-side authorization enforcement

Transaction authorizations must be enforced on the server side. It must never be possible to influence an authorization result by tampering with parameters containing transaction data, adding or removing parameters to disable authorization checks, or causing an error. Security programming best practices such as default deny and avoiding debugging functionality in production code should be applied.

Unique authorization credentials per transaction

Each transaction must be authorized using unique authorization credentials. If applications only ask for authorization credentials once during a session, attackers can employ malware to sniff credentials and reuse them to authorize any transaction without user knowledge.

Methods to distinguish authentication from authorization

Developers can distinguish authentication from transaction authorization by: using different methods for authentication and authorization, employing different actions in an external security component (such as different modes in a CAP reader), or presenting the user with a clear message about what they are signing using the What You See Is What You Sign Principle.

Use cryptographic operations for transaction protection

Cryptographic operations should be used to protect transactions and ensure integrity, confidentiality, and non-repudiation.

Certificate pinning for protection against CA compromise

Certificate Pinning is the practice of hardcoding or storing a predefined set of information (usually hashes) for digital certificates/public keys in the user agent such that only the predefined certificates/public keys are used for secure communication, and all others will fail. Certificate pinning protects against CA compromise where a compromised CA trusted by a user can issue certificates for any domain allowing eavesdropping, protects in environments where users are forced to accept potentially-malicious root CAs such as corporate environments or national PKI schemes, and protects applications where users may not understand certificate warnings and are likely to allow any invalid certificate.

Panic mode implementation for users under direct threat

A panic mode is a feature that threatened users can invoke when under direct threat to disclose account credentials. Panic modes help users in tumultuous regions survive threats. Examples include modes where users can delete data upon threat, log into fake inboxes/accounts/systems, or invoke triggers to backup/upload/hide sensitive data. Panic modes must not be easily discoverable, if at all. Once inside a panic mode, most non-sensitive normal operations must be allowed to continue and further panic modes must be possible to create from inside the original panic mode. An alternative is to prevent panic modes from being generated from the user account and instead create them out-of-band only with no way for adversaries to know a panic mode exists for that account. Panic mode implementation must confuse adversaries and prevent them from reaching actual accounts/sensitive data while preventing discovery of any existing panic modes for a particular account.

Remote session invalidation for compromised device scenarios

Users should be able to view their current online sessions and disconnect/invalidate any suspicious lingering sessions, especially ones that belong to stolen or confiscated devices. Remote session invalidation is beneficial when user equipment is lost, stolen, confiscated, or suspected of cookie theft. It also helps if a user suspects their session details were stolen in a Man-in-the-Middle attack.

NGINX ssl_ecdh_curve configuration

For NGINX, the supported_groups can be configured using: ``` ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1; ```

OpenSSL supported_groups configuration

For OpenSSL, the list of enabled groups can be configured in openssl.cnf: ``` openssl_conf = openssl_init [openssl_init] ssl_conf = ssl_module [ssl_module] system_default = tls_system_default [tls_system_default] Groups = X25519MLKEM768:x25519:prime256v1:x448:ffdhe2048:ffdhe3072 ```

Elliptic Curve Diffie-Hellman groups for TLS

Elliptic Curve Diffie-Hellman groups include: x25519, prime256v1, x448, secp384r1. For post-quantum cryptography, X25519MLKEM768 is currently used.

Finite Field Diffie-Hellman groups for TLS

The supported_groups extension negotiates Diffie-Hellman groups. Available Finite Field Diffie-Hellman groups are: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 as specified in RFC7919.

TLS 1.2 cipher suite requirements

If TLS 1.2 is still required, prefer AEAD-based suites and avoid CBC-mode ciphers. Always disable: Null ciphers, Anonymous ciphers (TLS_*_anon_*), EXPORT ciphers (TLS_*_EXPORT_*), RSA transport (TLS_RSA_*), and ephemeral/static Diffie-Hellman key agreement (TLS_DH_*, TLS_ECDH_*) which do not provide forward secrecy.

TLS 1.3 AEAD cipher suites

For TLS 1.3, use the standard AEAD cipher suites: AES-GCM or ChaCha20-Poly1305.

TLS_FALLBACK_SCSV to prevent protocol downgrade attacks

The TLS_FALLBACK_SCSV extension should be enabled to prevent protocol downgrade attacks when interoperability with end-of-life clients requires a dedicated endpoint with no access to sensitive data.

Default to TLS 1.3, support TLS 1.2 for compatibility

Web applications must default to TLS 1.3 and may support TLS 1.2 for compatibility. TLS 1.0 and TLS 1.1 are formally deprecated by RFC 8996 (March 2021) and must be disabled. They are forbidden by PCI DSS, disallowed by NIST SP 800-52 Rev. 2, and removed from all mainstream browsers. SSLv2 and SSLv3 must always be disabled.

Apache SSL curves configuration

For Apache, the supported_groups can be configured using: ``` SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1 ```

API endpoints disable HTTP or fail requests

API-only endpoints should disable HTTP altogether and only support encrypted connections. When that is not possible, API endpoints should fail requests made over unencrypted HTTP connections instead of redirecting them.

Disable TLS compression to prevent CRIME attack

TLS compression should be disabled to protect against the CRIME vulnerability which could allow attackers to recover sensitive information such as session cookies by analyzing compression ratio patterns in TLS requests.

Give your agent this brain