Sequence - Identity Document

When initiating an auth flow, the identity instrument does not request any proof that one owns the auth keypair. The authkey parameter in any request simply represents the public key component of the keypair, and can be easily hijacked. An attacker could create a new auth flow with the a keypair that is already in use at the moment. This will allow the attacker to override the owner's auth key record, associating it with the attacker's signer. The system, however, will not allow the attacker, nor the true owner, to proceed with signing transactions, causing a temporary DoS. The owner, in turn, will be forced to re-authenticate.

Upon a valid auth flow, one could abuse the sign logic by submitting many sign requests. Whenever a user session is in place, code-level rate limiting is highly advisable as an extra security layer to prevent Denial-of-Service (DoS) attacks, since cloud-based ones are less granular and generally based on IPs, which could be rotated.

The application renders parts of the authenticated user interface (UI) to unauthenticated users who visit arbitrary or deep-linked paths (e.g., [https://v3.sequence-dev.app/foo](https://v3.sequence-dev.app/foo)). While backend API calls fail due to lack of authentication, the presence of elements like "Logout" and partial dashboard components implies that routing and view rendering are not properly gated by authentication status. This exposes internal UI logic and workflows, which can aid attackers in reconnaissance, phishing, or crafting targeted social engineering attacks. In more severe scenarios, it may also leak static content or mislead users into believing they are logged in. Even if no sensitive data is exposed directly, showing logged-in-only UI to unauthenticated users violates the principle of least privilege and secure defaults.

A variety of attacks are actually performed using invalid symbols in headers. There is a setting in the load balancer, if it is an application load balancer, to prevent those headers to be forwarded to the target resource.

There are two critical considerations in the way the application interacts with Amazon DynamoDB, especially in the context of permanent data storage and unbounded payload sizes: A. Time-to-Live (TTL) Not Explicitly Controlled DynamoDB offers an optional Time to Live (TTL) mechanism that allows automatic deletion of expired items, based on a user-defined timestamp attribute. If the application intends to store items permanently, it is vital that: - No TTL attribute (e.g., ttl or expirationTime) is accidentally set. - Data written into the table is validated to ensure TTL values are not unintentionally populated. If TTL is enabled without strict control, this can lead to silent data deletion, resulting in: - Unexpected missing records - Failures in business logic - Irrecoverable loss of important data (DynamoDB TTL deletions are permanent) B. Risk of Exceeding the 400 KB Item Limit DynamoDB enforces a hard 400 KB size limit per item (including attribute names and metadata). If the data model allows unbounded growth — such as appending to a list or storing user-generated content — there's a real risk of: - Write failures (ValidationException: Item size has exceeded the maximum allowed size) - Application crashes or inconsistencies due to write failures - Inability to restore or replicate oversized items This is especially critical when handling logs, document snapshots, or unvalidated client input.

When using EC2-instances, if real-time view on data is critical, it is advisable to enable enhanced monitoring. This also enables teams to get alarms more timely.

When using EC2-instances, it is advisable to enable termination protection, since it is otherwise possible to accidentally lose data or put the cluster in an undesired state.

In the OTP authentication flow, in the commit stage, input email lengths are not validated. This creates an opportunity for malicious actors to send OTP requests with a large payload. This could open-up DoS attack vectors, such as Denial-of-Service (e.g., memory exaustion) or simply cause AWS costs to increase. Developers seem to be somewhat aware of this issue, as validation is currently stated as a TODO comment. ``` func (s \*Sender) NormalizeRecipient(recipient string) (string, error) { // TODO: Validate email address return Normalize(recipient), nil } ``` Similar to the missing email validation logic in the OTP-based auth flow, the sign logic does not verify the digest length, allowing for any digest size (generally expected to be 256 bytes long). The same issues concerning a potentially unbounded input apply here, namely, the risk of DoS attacks and potentially higher AWS costs. Similar to the ones described above, the `auth_key` length should be validated as well.

In order to prevent issues when deploying changes to the code, it is recommended to employ a so-called CI/CD tool. Examples are: - Github Workflows - Jenkins - Bitbucket pipelines - Gitlab pipelines - CircleCI These tools can be used to ensure that a proper code change process is in place and that tests are run every time a change takes place.

When using `FROM` directives in Docker files, it is important to specify the version directly and not just use latest (since this is a changing tag). Alternatively, define a specific digest of the image you aim to use.