Pizza Restaurant Example STRIDE Threat Model

What are we working on?

The project being reviewed is an online pizza restaurant. To help make the experience more engaging, it includes a social component where people can see what pizzas have been ordered and customers can track their pizza through the creation process. For simplicity, only credit cards are taken for payment, only one payment processor is used, and all pizza is picked up from the store (no delivery). The typical “happy path” flow includes:

The customer builds their pizza on the website from a list of ingredients.
When finished building, the website calculates the price of the pizza by querying the database.
The customer enters their payment information on the website and the website connects to the credit card processor to process the payment.
The pizza order is added to the database.
For the social component, once the order is in the database, it is also displayed on the starting page of the webpage with the user’s username.
Pizza makers in the pizza shop check the database and begin building the pizza through various stations, including dough, sauce, cheese, toppings, baking, and boxing. One pizza worker is at each station.
At each step, the pizza maker updates the database with current progress. As the database is updated, the pizza tracker on the website is updated, showing current progress and who has completed that step.
Customer picks up their pizza once it is ready.

What can go wrong?

STRIDE reminders

Mnemonic Threat	Definition	Question
Spoofing	The ability to impersonate another user or system component to gain unauthorized access.	Is the user who they say they are?
Tampering	Unauthorized alteration of data or code.	Has the data or code been modified in some way?
Repudiation	The ability for a system or user to deny having taken a certain action.	Is there enough data to “prove” the user took the action if they were to deny it?
Information Disclosure	The over-sharing of data expected to be kept private.	Is there anywhere where excessive data is being shared or controls are not properly in place to protect private information?
Denial of Service	The ability for an attacker to negatively affect the availability of a system.	Can someone, without authorization, impact the availability of the service or business?
Elevation of Privilege	The ability for an attacker to gain additional privileges and roles beyond what they initially were granted.	Are there ways for a user, without proper authentication (verifying identity) and authorization (verifying permission) to gain access to additional privileges, either through standard (normally legitimate) or illegitimate means?

Threat table

Threat	Issues
Spoofing	Spoof.1 - (Step 1) An attacker could submit an order as another user. Spoof.2 - (Step 3) If credit card information is stored in the user profile, a spoofed pizza order could be submitted automatically to the CC processor, making another user pay for the pizza order. Spoof.3 - (Step 7) An attacker “blasts” erroneous pizza updates at the website, eroding trust in the data and process.
Tampering	Tamper.1 - (Step 2) An attacker submits their own query injecting SQL into the DB query. Tamper.2 - (Step 2) An attacker modifies the values returned from their pizza price query and gives themselves a discount. Tamper.3 - (Step 4) An attacker builds and quotes a “cheap” pizza, but after payment, submits a much more expensive order. Tamper.4 - (Step 6) Pizza Maker modifies an order at someone else’s station to make them look incompetent.
Repudiation	Repudiate.1 - (Step 3) An attacker places an order but refutes the CC charge. Repudiate.2 - (Step 4) An attacker submits an order for another user directly to the DB without ever interfacing with the rest of the system. Repudiate.3 - (Step 4) Multiple valid orders can be submitted with the same CC processing token.
Information Disclosure	Info.1 - (Step 4) An attacker farms sequential order IDs to interact with them. Info.2 - (Step 2) An attacker is able to query more information and is able to access stored CC info. Info.3 - (Step 4) - An attacker is able to farm sequential coupon codes. Info.4 - (Step 5) - When the website is updated with the newest pizza order, behind the scenes, it returns the entire pizza order but only displays the pizza. An attacker can farm PII from the pizza order page.
Denial of Service	DoS.1 - An attacker targets the website to take it down. DoS.2 - (Step 1) An attacker identifies and repeatedly calls the API endpoint to create a new user. DoS.3 - (Step 4) An attacker bulk drops orders to lock up the ordering process. DoS.4 - (Step 2) An attacker bulk drops orders to lock up the pricing process.
Elevation of Privilege	Elevation.1 - An attacker is able to trick the pizza website into displaying the admin interface on the website. Elevation.2 - (Step 6) A pizza maker uses his manager’s access to delete pizza orders so he doesn’t have to make them.

What are we going to do about it?

Threat	Issues
Spoofing	Spoof.1 - (Step 1) An attacker could submit an order as another user. S1R1 - Ensure proper authentication is required before a website visitor is authorized to submit an order. Ensure the location information from the user profile is used for order information. Spoof.2 - (Step 3) If credit card information is stored in the user profile, a spoofed pizza order could be submitted automatically to the CC processor, making another user pay for the pizza order. S2R1 - Ensure all data required to process a credit card payment is not stored together in the customer profile. All data should be encrypted at rest and in transit. One way of accomplishing the end goal would be to use CCV # as only ephemeral data and capture it each time the credit card is used. CCV should never be stored. Spoof.3 - (Step 7) An attacker “blasts” erroneous pizza updates at the website, eroding trust in the data and process. S3R1 - Ensure pizza states updates are performed via a PULL style where the website queries a server it trusts for pizza status updates. S3R2 - Alternatively, allow PUSH style updates from the pizza server, but only expose that API endpoint internally.
Tampering	Tamper.1 - (Step 2) An attacker submits their own query injecting SQL into the DB query. T1R1 - Ensure all queries for all database lookups that utilize untrusted user data are performed with prepared statements and all input is properly encoded. Tamper.2 - (Step 2) An attacker modifies the values returned from their pizza price query and gives themselves a discount. T2R1 - The pricing info coming back from the database server should only ever be used for display purposes. The price should be calculated on the server separately when the charge is actually applied and the financial tracking information should only trust the specific pizza order that is customized. All calculations for price should be performed separately on the back-end. Tamper.3 - (Step 4) An attacker builds and quotes a “cheap” pizza, but after payment, submits a much more expensive order. T3R1 - The pizza order that was priced should be placed directly from the database server to the CC processor. This prevents quoting one pizza but ordering another. Tamper.4 - (Step 6) Pizza Maker modifies an order at someone else’s station to make them look incompetent. T4R1 - This is an “insider threat” type of attack. Each pizza maker should have a way of authenticating to their station, so all actions are trackable and auditable. One approach could be to have each pizza maker have a keycard that authenticates them to their pizza station. The keycard should be connected to the pizza maker, such that if they leave, the keycard is automatically removed. The keycard must be present for changes to be submitted to the database server.
Repudiation	Repudiate.1 - (Step 3) An attacker places an order but refutes the CC charge. R1R1 - Ensure that when a new user profile is created, a public/private key pair is generated. These should be used to sign and validate messages between the user and the server. When a pizza order is submitted to the server, the server calculates the hash of the order along with a secret salt and sends the salted hash back to the originating user. The originating user signs the salted hash with their private key and submits the signed bundle back to the server. The server should store the order, the secret salt (through persistence in the process environment), the salted hash, and the signed bundle. If a user refutes the order, the server can simply verify that the user’s public key properly decrypts the signed bundle. Repudiate.2 - (Step 4) An attacker submits an order for another user directly to the DB without ever interfacing with the rest of the system. R2R1 - Ensure order submissions require an active JWT session token. Ensure the session timeout for a session reflects the actual usage patterns expected (it doesn’t take 7 hours to order a pizza). R2R2 - Ensure that a pizza order has been properly quoted by recalculating the pizza price at submission time. Repudiate.3 - (Step 4) Multiple valid orders can be submitted with the same CC processing token. R3R1 - Ensure CC processing tokens are sufficiently short-lived. R3R2 - Work with CC processor to invalidate the token after a transaction is confirmed.
Information Disclosure	Info.1 - (Step 4) An attacker farms sequential order IDs to interact with them. I1R1 - Ensure all IDs (order IDs, user IDs, transaction IDs, etc) use non-sequential, difficult to guess GUIDs. Info.2 - (Step 2) An attacker is able to query more information and is able to access stored CC info. I2R1 - Utilize a filtering framework like CASL to limit what information is available through queries. I2R2 - Ensure CC info is stored in a separate context and not easily reachable (network segmented to only allow very specific known actions to reach the CC environment). I2R3 - Ensure tokenization is used to obfuscate the CC info. One example could look like the following: 1. User submits their order and the signing process takes place. 2. The website prompts the user for their CVV and submits it to the database server. 3. The database server then submits the order price they have confirmed along with a CVV and a CC number identifier to the API endpoint to submit a payment request. 4. The payment request API call submits a payment request to the CC processor. 5. When success is returned, the API call resolves to being paid. This method never exposes the CC to the database or web server. Info.3 - (Step 4) - An attacker is able to farm sequential coupon codes. I3R1 - Ensure coupon codes are not sequential. I3R2 - Alternatively, if availability of the coupon code is more important (i.e., it is being used to drive traffic and there is minimal concern with the secrecy), then be sure to build in the discount price into cost projection models. Additionally, consider setting a maximum number of coupons to be used to provide an upper bound for cost in the event of abuse. Info.4 - (Step 5) - When the website is updated with the newest pizza order, behind the scenes, it returns the entire pizza order but only displays the pizza. An attacker can farm PII from the pizza order page. I4R1 - Ensure that the query used to present the data on the pizza order page only returns the data strictly necessary to accomplish the update to the status page in context. If address, email address, or CC number is not necessary to accomplish the update for a pizza status, do not include those fields in the query.
Denial of Service	DoS.1 - An attacker targets the website to take it down. D1R1 - Ensure the website follows some mitigation strategy for DDoS protection. This could include CloudFlare DDoS, Cloudflare WAF, F5 DDoS Mitigation, or others. D1R2 - As an alternative or in addition, rate limiting should be applied at the server level to limit the capability of imposing a DDoS attack. DoS.2 - (Step 1) An attacker identifies and repeatedly calls the API endpoint to create a new user. D2R1 - Set up rate limiting for sensitive API calls (like this one). Ensure CAPTCHA or other bot preventions are in place to make it more difficult. DoS.3 - (Step 4) An attacker bulk drops orders to lock up the ordering process. D3R1 - Set up Cloudflare DDoS and Cloudflare WAF. D3R2 - Set up rate limiting for the API call to submit orders. D3R3 - Set up X-Forwarded-For headers on the server to enable rate limiting by origin IP. D3R4 - Set up rate limiting by IP. D3R5 - Ensure the website can identify large numbers of orders from a single user and limit it to an appropriate value. DoS.4 - (Step 2) An attacker bulk drops orders to lock up the pricing process. D4R1 - The same mitigations apply here as for DoS.3. D4R2 - Additionally, ensure the pricing system also identifies large number of price lookups or price re-lookups originating from the same IPs.
Elevation of Privilege	Elevation.1 - An attacker is able to trick the pizza website into displaying the admin interface on the website. E1R1 - Ensure the administrative interface for the website is presented at a different URI. E1R2 - Ensure the invocation of sensitive or administrative tasks is done by administrators as identified from a lookup of the user’s session on the server. Elevation.2 - (Step 6) A pizza maker uses his manager’s access to delete pizza orders so he doesn’t have to make them. E2R1 - Ensure the keycard that grants access is not left unattended without the manager present.

Did we do a good job?

Has the data flow diagram been referenced since it was created?
- Yes, it was invaluable in building the threat profile.
Did the STRIDE model uncover any new design issues or concerns that had not been previously addressed or thought of?
- Yes. We realized we needed to change the pizza station authentication scheme. Additionally, we reframed the queries for the pizza order social display to only deliver the needed information.
Did the treatments identified in the “What are we going to do about it” section adequately address the issues identified?
- Yes. We are continuing to monitor these in the event additional mitigations are needed.
Have additional issues been found after the threat model?
- None yet. As new features are added, the threat model will be updated to reflect the new additions.
Any additional thoughts or insights on the threat modeling process that could help improve it next time?
- None.

​What are we working on?

​What can go wrong?

​STRIDE reminders

​Threat table

​What are we going to do about it?

​Did we do a good job?