STRIDE

STRIDE is a methodology for identifying known threats. The STRIDE acronym is formed from the first letter of each of the following categories and is an example of a simplified threat-risk model that is easy to remember and apply.

Spoofing Identity Identity spoofing is a key risk for applications that have many users but provide a single execution context at the application and database levels. In particular, users should not be able to become any other user or assume the attributes of another user .

Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, that are obtainable only from within the application itself. The application also should carefully check data received from the user and validate that it is sane and applicable before storing or using it. For web and other applications with a client component, ensure you perform your validation checks on the server and not the client, where the validation checks might be tampered with.

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, "But I didn't transfer any money to this external account!" and you cannot track his or her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier , or the same user context from top to bottom. Preferably, the application should run with the user's privileges, not more, but this may not be possible with many commercial off-the-shelf applications.

Information Disclosure Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also consider if the user's web browser may leak information. Some web browsers may ignore the no-caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser just in case it leaks or leaves information behind which can be used by an attacker to learn details about the application or the user, possibly using that information to assume the role of an authorized privileged user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should never be relied on to secure especially sensitive information or to provide adequate personal privacy safeguards.

Denial of Service Application designers should be aware that their applications may be subject to a denial-of-service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users and not be available to anonymous users.

For applications that don't have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, and to avoid exposing large files or unique links per user in order to prevent simple denial-of-service attacks.

Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his or her role to a higher privileged one. In particular, simply not displaying privileged-role links is insufficient. Instead, all actions should be gated through an authorization matrix to ensure that only the permitted roles can access privileged functionality.