Common attacks and fixes (OWASP)

After the design is drawn, the interviewer asks: "How do you keep it safe?" Or: "A user types something strange into the search box. What happens?"

A weak answer is "we use HTTPS and passwords". A strong answer names real attacks and gives one fix for each.

A careless bank clerk follows every line on a form, even "and give me the key to the safe". Many attacks work like this: the program obeys a stranger's words.

An attack makes a system do what its owner did not want. OWASP is a non-profit group that publishes free security guides. Its Top 10 lists the most common web risks. One rule covers every attack below: never trust input. Input is anything from outside your servers, such as form fields, parts of a URL, headers and files.

1. SQL injection. The code joins text into a query (SQL is the database language of lesson 17): "... WHERE customer_id = '" + id + "'". The attacker sends the id x' OR '1'='1, so the query says WHERE customer_id = 'x' OR '1'='1', which is true for every row. Fix: a parameterised query. The query has a placeholder and the value travels apart, so the database treats it as data, never as a command.
2. Broken access control. The server checks that the user is logged in, but not that the order is theirs. The attacker changes /orders/42 to /orders/43. Fix: check the owner on every request, and deny by default (lesson 101). Random IDs (lesson 23) only make guessing hard.
3. Cross-site scripting (XSS). A page prints text that a user typed, such as a review, as it is. If the text holds a small program, each viewer's browser runs it with the rights of your site. Fix: output encoding. Change < into <, so the browser shows text. An HttpOnly cookie (lesson 99) only limits the harm.
4. Cross-site request forgery (CSRF). A browser sends your cookie with every request to a site, even when another site's page starts it. A hidden form on a bad page posts to /orders/42/cancel, and the server thinks you did it. Fix: the cookie setting SameSite=Lax, which makes the browser skip the cookie on most requests that another site starts, such as a form post. Also add a secret CSRF token to each request that changes data. Never change data with GET (lesson 9).
5. Login guessing. Brute force tries many passwords for one account. Credential stuffing tries pairs leaked from another site, because people reuse passwords. Fix: multi-factor authentication (MFA), a second proof such as a phone code. Add rate limits (lesson 56) and a slow password hash (lesson 99).
6. Server-side request forgery (SSRF). A feature fetches a URL that the user gives, such as a link preview. The attacker gives an internal address such as http://169.254.169.254/, where cloud machines read their own keys. Fix: an allow-list of hosts the server may call, no redirects, and no internal addresses, which work only inside a company network.

SwadKart, a food-delivery app. Assumptions (made up): 40,000,000 orders of 200 bytes and 2,000,000 customers (lesson 20). The attacker sends 100 requests a second.

Predict box. A sees order 43, which belongs to someone else. The owner check stops it. With IDs that go up by one, the attacker reads every order in 40,000,000 / 100 = 400,000 seconds = 111 hours, or 4.6 days.

Injection. A normal request returns 40,000,000 / 2,000,000 = 20 orders, which is 4,000 bytes. The attack returns 40,000,000 x 200 = 8,000,000,000 bytes = 8 GB, which is 2,000,000 times more.

Login guessing. Assumptions: 1,000,000 leaked pairs, and 1% also work here, which is 10,000 accounts. A limit of 5 tries a minute for each IP address slows one machine: 1,000,000 / 5 = 200,000 minutes = 139 days. With 2,000 addresses: 1,000,000 / (5 x 2,000) = 100 minutes.

Each fix solves one attack, and most cost little. MFA adds friction, so some users give up. I would loosen a layer only when it blocks more real users than attackers.

"We use HTTPS, so these attacks cannot happen." HTTPS protects the connection (lesson 102). All six attacks arrive over a good connection.

"The app checks the form, so bad input never arrives." An attacker can skip your app, so the server checks every input.

1. Name three of the six attacks. For each, give one fix.
2. An attacker sends 200 requests a second against 24,000,000 orders with IDs that go up by one. How long to read them all? Another attacker holds 2,000,000 leaked pairs, and your limit is 10 tries a minute for each IP address. How long with 500 addresses?
3. A search page shows "No results for" and then the text the user typed, as it is. A teammate says: "We reject the character < in the app." What do you say?