James Harton

A session fixation issue allows an attacker to maintain an authenticated session if they can plant a session identifier in a victim's browser before the victim signs in. This occurs because the function `store in session/2` in `AshAuthentication.Plug.Helpers` uses `Plug.Conn.put session/3` to write the authenticated subject without calling `Plug.Conn.configure session(renew: true)`, causing the pre-authentication identifier to persist. This affects the default `success/4` function in `AshAuthentication.Phoenix.Controller. using /1`, the `AuthController` from `mix ash authentication phoenix.install`, and remember-me auto-login. Additionally, the `clear session/2` function uses `Plug.Conn.clear session/1`, which removes session content but keeps the identifier, allowing a planted ID to survive a logout-then-login sequence. In deployments using server-side session stores (such as ETS, Mnesia, Redis, or a database), this can lead to full account takeover. This is possible if the attacker can plant a cookie via sibling subdomain cookie tossing, an HTTP host without HSTS, or a shared browser.

Insufficient session expiration allows a revoked session to remain fully authenticated. When a resource is configured with `session identifier :jti` and `require token presence for authentication?` is disabled, the session value is stored as `<jti>:<subject>`. The functions `AshAuthentication.Plug.Helpers.authenticate resource from session/4` and `AshAuthentication.Phoenix.LiveSession.on mount/4` use `split identifier/2` to discard the `jti` and pass only the subject to `AshAuthentication.subject to user/3`. Since the revocation record is not consulted, the revoked state and expiry of the `jti` are ignored, allowing sessions captured before sign-out to remain active.

An improper authentication issue allows an attacker to sign in as another user by linking an OAuth2 identity to an account that does not belong to them. The `AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3` function matches an existing account using `upsert identity` keys and validates the link via `email trusted?/2`. However, this check only verifies the provider's `email verified` boolean and fails to compare the provider's email value with the matched account's email. This flaw also exists in `OAuth2.SignInPreparation` when `registration enabled?` is false and the account is matched by the sign-in action's read filter. An attacker with a verified email from a provider can be issued a session for an account matched on a different attribute. Additionally, the process rewrites the matched account's email to the attacker's address, allowing the attacker to intercept future account recovery attempts.

An authentication bypass by spoofing exists in the `dynamic oidc` strategy. This allows an attacker using one identity-provider connection to be signed in as a local user associated with a different connection. The issue occurs because the intended identity namespacing, which should format the `strategy` field of `UserIdentity` rows as `"<name>/<connection id>"`, is not applied. Instead, the ` connection id ` variable is only populated on an ephemeral runtime struct and is not used during the identity change process in the `DynamicOidc.IdentityChange.change/3` function. Consequently, the system falls back to the bare strategy name for identity writes and reads in `oauth2/user resolver.ex` and `oauth2/sign in preparation.ex`. Because the unique key for the identity resource is `(uid, strategy)` and the system does not handle the `iss` (issuer) claim, users from different providers with the same `sub` (subject) value are treated as the same user. This can lead to account takeover without victim interaction or the silent merging of distinct users who happen to share the same subject identifier across different providers.

An authentication bypass by spoofing allows an attacker to replace a victim's authenticated session with their own account by planting a remember-me cookie in the victim's browser. This occurs because the function `sign in using remember me/3` checks the session for a `<subject name> token` key to avoid re-authenticating already-signed-in users. However, the `store in session/2` function only writes this key when `require token presence for authentication?` is enabled; otherwise, it writes only the subject name. Under default settings, the guard reads a key that is never written, causing the remember-me sign-in process to run on every request. Consequently, a planted cookie is honored even if a live session exists, leading the victim to unknowingly enter data into an account controlled by the attacker. This discrepancy exists because the read path in `authenticate resource from session/4` selects the key correctly, while the guard does not.

Improper verification of cryptographic signatures in AshAuthentication allows a caller of the token revocation action to neutralize a revocation or write arbitrary rows into the token resource. The function `AshAuthentication.TokenResource.RevokeTokenChange.change/3` reads the `:token` argument and decodes it using `AshAuthentication.Jwt.peek/1`, which delegates to `Joken.peek claims/1` without performing a signature check. Consequently, the `jti`, `exp`, and `sub` claims are written directly to the revocation record. An attacker can provide a forged token with a backdated `exp` claim, causing the revocation row to be treated as expired and removed by `expunge expired`, which allows the genuine token to pass the `revoked?` check. Additionally, arbitrary `jti` and `sub` values can be inserted into the resource.

Improper authentication allows an attacker with a sign-in token for one authenticated resource to be signed in as a user of a different resource. The function `extract primary keys from subject/2` within `AshAuthentication.Strategy.Password.SignInWithTokenPreparation` parses the JWT `sub` claim using `URI.parse/1` and retains only the query string, discarding the path segment that identifies the subject for which the token was issued. Because `AshAuthentication.Jwt.verify/3` only validates the signature and specific claims (`exp`, `nbf`, `jti`, and library-version) without restoring the resource binding, and primary-key field names are identical across resources, the authentication is bypassed. This behavior also affects WebAuthn sign-in and remember-me preparations. The magic link sign-in path is not affected.

An issue in AshAuthenticationPhoenix allows an attacker with access to access logs, proxy logs, or browser history to recover a single-use sign-in token and authenticate as the token owner. This occurs because `AshAuthentication.Phoenix.Components.Password.SignInForm` constructs the `sign in with token` path using the `user. metadata .token` as a query parameter and performs a GET redirect. Consequently, the token is recorded in the request line by web servers, reverse proxies, and browser history, exposing a live credential in locations that are typically less secure than session storage.

Insufficient session expiration allows an attacker who obtains a victim's OAuth2 `state` value to replay the callback and sign that victim into an attacker-controlled account. The function `AshAuthentication.Strategy.OAuth2.Plug.callback/2` fails to clear stored `session params` during failure paths, such as when the provider returns an access denied error, an invalid code, or a token-exchange error. Because the `else` block in the Elixir `with` chain reaches `store authentication result/2` while holding the original connection, the session entry is not removed. Consequently, the value intended to protect against Cross-Site Request Forgery (CSRF) is only consumed upon successful authentication and persists after cancelled or failed attempts.

An authorization bypass allows an authenticated attacker to overwrite and confirm another user's email address to take over their account. This occurs because a confirmation token issued to one user is accepted on any other user's record. Specifically, the `AshAuthentication.AddOn.Confirmation.ConfirmChange` function verifies the token's signature and its `act` claim but fails to compare the `sub` claim against `changeset.data` before applying changes to the target record. An attacker can register an account, change their own email, and replay the resulting token against a victim's record ID using `force change attributes/2` to set their own address and stamp `confirmed at`, subsequently gaining access via a password reset. The confirmation flow using `AshAuthentication.AddOn.Confirmation.Actions.confirm/3` is not affected as it correctly resolves `sub` to a user.

AshAuthentication allows the disclosure of user password digests to readers of the audit store. The `audit log` add-on builds `extra data` for each entry in the `AshAuthentication.AddOn.AuditLog.Auditor.build extra data/4` function, which takes the `:actor` from the action callback context verbatim. When an audited action is invoked with `actor:` set to a user record, the record—including the `hashed password` attribute—is deposited into the audit entry. While other identities are collapsed via `AshAuthentication.user to subject/1` and parameters are filtered, the actor remains unfiltered. Setting the attribute `sensitive?: true` is ineffective as it only redacts `inspect/1` output and not JSON encoding or raw-term storage. Exploitation requires independent read access to the audit store (e.g., database credentials, backups, or log shippers), enabling offline password attacks against active accounts. Persistence of this data depends on the data layer; raw-term stores keep it verbatim, whereas SQL stores may drop the entry unless the user resource derives `Jason.Encoder`.

AshAuthentication contains an issue where readers of the audit store can recover client IP addresses that the audit log add-on's `:hash` privacy mode is intended to pseudonymise. The function `hash ip/1` computes an unkeyed `:crypto.hash(:sha256, salt <> ip)` and truncates the result to 16 hexadecimal characters. The salt is retrieved from the `:audit log ip salt` or `:secret` application config keys; however, it defaults to a constant string "default-salt-change-in-production" if neither is set, without providing a warning. Because the IPv4 address space is limited to 2^32 values and SHA-256 is computationally efficient, the hash table can be precomputed, allowing stored values to be mapped back to their original source addresses. This risk persists even with a configured salt if the salt is leaked, as the hash remains cheap to enumerate.

An inefficient algorithmic complexity issue allows an unauthenticated attacker to cause CPU and memory exhaustion by submitting an API key with an oversized base62 segment. The function `AshAuthentication.Base.decode62/1` in `lib/ash authentication/base.ex` processes arguments by splitting them into binaries per character and using `charval62/2`, which recomputes `Integer.pow(62, index)` at every position. This results in a cubic growth in cost relative to input length. Additionally, the `bindecode62/1` function exhibits quadratic growth due to the use of `Integer.undigits/2` and `Integer.digits/2`. Because `AshAuthentication.Strategy.ApiKey.SignInPreparation` processes underscore-separated segments of the submitted key without capping `byte size/1` or requiring prior authentication, the system is susceptible to resource exhaustion that cannot be mitigated by existing rescue clauses.

A Time-of-check Time-of-use (TOCTOU) Race Condition occurs when a magic link is configured with `single use token?`. This allows an attacker with a leaked magic link to replay a single-use token and authenticate as the target subject. The issue arises because the token validity check is not serialized against its consumption, allowing concurrent redemptions to succeed and yield full user tokens. The sign-in process verifies the JWT using `Jwt.verify/4` and revokes it subsequently via `AshAuthentication.Strategy.MagicLink.SignInPreparation` in a `Query.after action` callback and `AshAuthentication.Strategy.MagicLink.SignInChange` in an `after transaction` hook. Because `AshAuthentication.TokenResource.Actions.revoke/3` performs the revocation as an upsert, concurrent duplicate revocations succeed without conflict.

An authentication bypass allows unconfirmed users to obtain a session, bypassing mandatory email confirmation requirements. The issue occurs in the `check user/2` function within `AshAuthentication.Strategy.Password.Actions`, which uses `is nil(Map.get(user, value))` to verify the attribute specified by `require confirmed with`. If the attribute is not selected or denied by a field policy, `Map.get/2` returns `%Ash.NotLoaded{}` or `%Ash.ForbiddenField{}` instead of `nil`, causing the system to incorrectly treat the user as confirmed. Additionally, the `require confirmed with` check is only performed within `AshAuthentication.Strategy.Password.Actions` and not on the actions themselves. Consequently, callers that invoke actions directly, such as `AshGraphql` or `AshJsonApi`, skip the confirmation check entirely in default configurations.

An unauthenticated attacker can forge application log entries by submitting a password reset identity containing newlines or control characters. The function `AshAuthentication.Strategy.Password.RequestPasswordReset.run/3` interpolates the `identity` variable, which contains the email or username from the reset request, into `Logger.warning/1` heredocs without escaping, truncating, or type-restricting it. Because a newline in the `identity` variable ends the log record, any subsequent text is written as a new line, allowing an attacker to manipulate the severity tag and the content of entries to make them appear as if they originated from the application.

تسمح المصادقة غير السليمة بإعادة استخدام رموز JSON Web Tokens (JWTs) المحددة الغرض كبيانات اعتماد API كاملة لحامل الرمز عندما يستخدم المورد التحقق من رمز الحامل بدون حالة. تقوم الدالة المساعدة `retrieve from bearer/3` بالتحقق من توقيع رمز JWT من نوع Authorization: Bearer وترفض الرموز التي تحتوي على مطالبة `act`، ولكنها تفشل في التحقق مما إذا كانت مطالبة `purpose` للرمز تساوي `user`. عندما يتم تكوين المورد بحيث تكون قيمة `require token presence for authentication?` مضبوطة على `false`، فإن الدالة المساعدة `validate token/3` تُرجع `{:ok, nil}` دون الرجوع إلى مورد الرمز، مما يتجاوز عمليات التحقق من الغرض في المراحل اللاحقة. ونتيجة لذلك، يتم قبول رموز JWT الصالحة التي لم تنته صلاحيتها والمصدرة لأغراض محددة — مثل رمز `sign in` الصادر عن WebAuthn أو استراتيجية Password — كبيانات اعتماد حامل للأغراض العامة، مما يمنح التعيين الكامل لـ `current user`. يمكن للمهاجم الذي يحصل على رمز `sign in` صالح أن يقوم بالمصادقة بصفته الكيان المستهدف، متجاوزًا دلالات الاستخدام لمرة واحدة والإلغاء. وهذا يتطلب من التطبيق استخدام `retrieve from bearer/3` على مسار يمكن الوصول إليه وتوظيف إما WebAuthn أو استراتيجية Password مع تعيين `sign in tokens enabled?` إلى `true`.

تحدث ثغرة البرمجة النصية عبر المواقع (XSS) المنعكسة عندما يتم تكوين إستراتيجية مع تعيين `require interaction?` على ”true“. يقدم البرنامج صفحات HTML وسيطة تدمج معلمات الطلب مباشرةً في سمات قيم الإدخال المخفية دون إجراء عملية الهروب من أحرف HTML. وعلى وجه التحديد، يتم إدراج المعلمة `confirm` في الملف `lib/ash authentication/add ons/confirmation/confirmation form.html.eex`، ويتم إدراج معلمة رمز الرابط السحري في الملف `lib/ash authentication/strategies/magic link/sign in form.html.eex`. ونظرًا لأن هذه القوالب تستخدم تعبيرات بسيطة لا تقوم بأي عملية هروب، ولأن وظائف `accept/2` في `AshAuthentication.AddOn.Confirmation.Plug` و`AshAuthentication.Strategy.MagicLink.Plug` لا تتحقق من صحة القيم، يمكن لمهاجم غير مصدق صياغة عنوان URL لحقن علامات برمجية ضارة. يتم تنفيذ البرنامج النصي المحقون في مصدر التطبيق، مما يسمح بالوصول إلى ملفات تعريف الارتباط والجلسات والاستجابات من نفس المصدر.

تسمح ثغرة تجاوز المصادقة عن طريق التزوير بالاستيلاء على حسابات المستخدمين المحليين أثناء تسجيل الدخول عبر OAuth2 أو OIDC. تحدث هذه المشكلة لأن البرنامج يطابق المستخدمين المحليين عن طريق عنوان البريد الإلكتروني بدلاً من استخدام مزيج مطالبات OpenID Connect `iss` (المُصدر) و`sub` (الموضوع)، وهما المعرفان الوحيدان المستقران والفريدان للمستخدم النهائي. يمكن لمهاجم غير مصدق تسجيل حساب لدى مزود OAuth معتمد باستخدام البريد الإلكتروني للضحية — بما في ذلك عناوين البريد الإلكتروني غير المؤكدة أو المعاد استخدامها — للحصول على امتيازات محلية كاملة لحساب الضحية.

تؤثر هذه المشكلة على مكتبة ash authentication phoenix، حيث تظل رموز الجلسة صالحة على الخادم بعد قيام المستخدم بتسجيل الخروج. ويؤدي ذلك إلى ثغرة أمنية تسمح لرموز الجلسة المخترقة بالاستمرار في العمل، حتى بعد تسجيل خروج المستخدم. لا تزال الجلسات المخزنة في قاعدة البيانات تنتهي صلاحيتها، مما يحد من المدة التي يمكن خلالها استغلال هذه الثغرة. لا يمكن للمستخدمين إبطال صلاحية جلساتهم بالكامل عند تسجيل الخروج من أجهزة مشتركة أو أجهزة قد تكون تعرضت للاختراق. ومع ذلك، فإن تغيير كلمة المرور يؤدي إلى إبطال صلاحية جميع الجلسات الأخرى. وقد يتسبب هذا في مشكلات تتعلق بالامتثال لأطر العمل الأمنية التي تتطلب إبطال صلاحية الجلسات بالكامل.