# STRIDE
STRIDE thread categorization.
# Overview
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 level. 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, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.
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/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 off-the-shelf application frameworks.
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, the user, or to potentially become that user. Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure 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 available to anonymous users. For applications that do not 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, 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/her role to a higher privilege 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.
# Analysis
| Nr. | Threat | Violation | CRA Reference | Fix / Mitigation |
|---|---|---|---|---|
| 001 | Viewing or tampering with the data from the web client to the reverse proxy (MITM) | S (e.g. impersonate the user) T (e.g. manipulate a new password) I (e.g. gain access to passwords) D(e.g. don't serve the webclient) E(e.g. if the attacked user is a superuser) | Annex I, Sec. 1 (a), (e), (f) | Enforce TLS 1.3, HSTS headers, CSP |
| 002 | Viewing or tampering with the data from the admin portal to the reverse proxy (MITM) | S (e.g. impersonate the user) T (e.g. manipulate health check response) I (e.g. gain access to email addresses) D(e.g. delete other users sessions) E(e.g. attacked user is a superuser) | Annex I, Sec. 1 (a), (e), (f) | Enforce TLS 1.3, HSTS headers, CSP |
| 003 | Viewing or tampering with the data from the reverse proxy to the server (MITM) | S (e.g. impersonate the user) T (e.g. manipulate a new password) I (e.g. gain access to passwords) D(e.g. don't serve the webclient) E(e.g. if the attacked user is a superuser) | Annex I, Sec. 1 (a), (f) | Use internal-only APIs, segmented traffic zones |
| 004 | Viewing or tampering with the data from the server to the database (MITM) | T (e.g. manipulate links) I (e.g. gain access to stored passwords) D (e.g. delete users) E (e.g. promote own user to superuser) | Annex I, Sec. 1 (a), (f) | TLS for DB connections, encrypted data, DB access control |
| 005 | Viewing or tampering with the data from the server to the email server (MITM) | I (e.g. e-mail addresses) D (e.g. block registration) T (e.g. impersonate email server and send links to phishing website) | Annex I, Sec. 1 (a), (f) | Use SMTPS, mail relay restrictions, validate email server certs |
| 006 | Viewing or tampering with the data in the database | S (e.g. manipulate passwords, API tokens) T (e.g. change urls to websites) I (e.g. e-mail addresses) D (e.g. corrupt data, making it impossible to login) | Annex I, Sec. 1 (f) | DB encryption at rest, strong DB ACLs, audit logging |
| 007 | Viewing or tampering with the web client application | T (e.g. send requests to other server) I (e.g. send password to other backend) D (e.g. deface the website) E (e.g. catched passwords can be used to login) | Annex I, Sec. 1 (a), (f) | Enforce TLS 1.3, Restrictive access to servers & code |
| 008 | Viewing or tampering with the server application | S (e.g. forward API tokens to third parties) T (e.g. manipulate stored data) R (e.g. prevent logging) I (e.g. access user data) D (e.g. block requests) E (e.g. catched passwords can be used to login) | Annex I, Sec. 1 (a), (b), (f), Sec. 2 | Secure CI/CD, RBAC enforcement, WAF |
| 009 | A malicious user deletes logs | R (e.g. deletes audit logs) | Annex I, Sec. 1 (f), Sec. 2 | Immutable logs, centralized logging |
| 010 | DDoS against the database | D (noone is able to login) | Annex I, Sec. 1 (b) | Isolated DB |
| 011 | DDoS against the backend server | D (noone is able to login) | Annex I, Sec. 1 (b) | Auto-scaling, WAF rules, caching, DoS protection services, Cloudflare |
| 012 | DDoS against the reverse proxy | D (noone is able to login) | Annex I, Sec. 1 (b) | Auto-scaling, caching, DoS protection services, Cloudflare |
| 013 | DDoS against the web client | D (noone is able to login) | Annex I, Sec. 1 (b) | Content caching, global load balancing, DoS protection services, Cloudflare |
| 014 | DDoS against the admin portal | D (admins are not able to login) | Annex I, Sec. 1 (b) | Content caching, global load balancing, DoS protection services, Cloudflare |
| 015 | DDoS against the email server | D (noone can register) | Annex I, Sec. 1 (b) | Email queueing, Rate Limits, DoS protection services |
| 016 | DDoS against the time server | R (e.g. audit logs become "unreadable") D (some login methods wont work with a wrong time) | Annex I, Sec. 1 (b), (f) | Distributed NTP servers (e.g. time.google.com) |
| 017 | Bruteforce attack against the login form | S (e.g. impersonate the user) T (e.g. change user data) I (e.g. disclose private information) E (e.g. if the target is an admin user) | Annex I, Sec. 1 (e) | Rate limiting, MFA |
| 018 | Bruteforce attack against the password recovery form | S (e.g. impersonate the user) T (e.g. change user data) I (e.g. disclose private information) E (e.g. if the target is an admin user) | Annex I, Sec. 1 (e) | Rate limiting |
| 019 | SQL injection | S (e.g. impersonate the user) T (e.g. change user data) I (e.g. disclose private information) E (e.g. bypass validation checks for admin roles) | Annex I, Sec. 1 (b), (f) | Use parameterized queries, ORM, input validation |
| 020 | LDAP injection | S (e.g. impersonate the user) T (e.g. change user data) I (e.g. disclose private information) E (e.g. bypass validation checks for admin roles) | Annex I, Sec. 1 (b), (f) | LDAP query escaping, input validation |
| 021 | Cross-site Scripting (XSS) | S (e.g. impersonate the user) T (e.g. change user data) I (e.g. disclose private information) E (e.g. trick client to send data to the wrong url) | Annex I, Sec. 1 (b), (f) | CSP, input/output encoding, DOM sanitization |
| 022 | Software Vulnerability | S (e.g. weak random number generator) T (e.g. gain access and tamper with any data) I (e.g. causing crashes that reveal sensitive data) D (e.g. causing crashes) E (e.g. bypass security controls) | Annex I, Sec. 1 (b), Sec. 2 | Vulnerability scanning, regular security updates |
| 023 | Security Missconfiguration | S (e.g. weak configuration of authentication methods) T (e.g. gain access and tamper with any data) I (e.g. weak crypto) D (e.g. filepointer too low) E (e.g. bypass security controls) | Annex I, Sec. 1 (b), (e), (f) | Regular audits of configurations |
| 024 | Supply Chain Risks | S (e.g. system backdoor) T (e.g. manipulate data) I (e.g. weak crypto, backdoor) D (e.g. ransomware) E (e.g. bypass security controls) | Annex I, Sec. 1 (b), Sec. 2 (patch management), Art. 10(2)(e)) | SBOM, CVE monitoring, code reviews |
| 025 | Insecure defaults | T (e.g. manipulate data) E (e.g. bypass security controls) | Annex I, Sec. 1 (d) | Secure-by-default configs, code reviews |
| 026 | Inadequate Logging | R (e.g. user account deleted and no one takes responsibility) | Art. 10(3), Annex I Sec. 2 (vulnerability handling) | Centralized logging, tamper-evident audit trails |
| 027 | Secure Update Mechanism Risks | I (e.g. gain access to passwords) D (e.g. delete or encrypt data) E (e.g. bypass security controls) | Art. 10(4), Annex I Sec. 1 (g) | Updates distributed through official stores (docker hub, play store, AMO, ...) |
# Source
https://www.owasp.org/index.php/Threat_Risk_Modeling#STRIDE (opens new window)
← V19 Configuration FAQ →