Exam practice

1. What are we protecting? The catalog (true records of which books exist and where), who has borrowed what (students’ privacy), the librarians’ accounts, the app staying up during exam weeks, and the books themselves.
2. From whom? A student who wants to hide a late book or see what a classmate borrowed; a prankster; a program scanning for easy websites; a librarian’s mistake; a dead disk.
3. How could it go wrong? Entry points: the search box (injection), the sign-in page (guessed passwords), the “mark as borrowed” request (a student sending it by hand, or a librarian’s stolen session), the borrowing list (shown to the wrong person); the database’s backups.
4. What will we do, and at what cost? Placeholders in every query and escaping in every page (no cost to users); the server checks for a librarian’s session on every change (none); slow, salted password hashes and two-step login for librarians (a little time each day); show each student only their own borrowing (none); a daily backup kept locked away (a little money and time).

Joining the text into the SQL means the database reads the user’s text as part of the command. An honest value with an apostrophe, such as Sita's classroom, already breaks the query, with an error; and a value chosen on purpose could change what the query does, to match every row or read another table. A program that breaks on honest input is wrong whether or not anyone attacks it.
With a placeholder, the SQL text is fixed and compiled into a plan first; the value is then bound to the plan as data. It is never read as SQL, so every value, apostrophes and all, is simply compared with the places. It fixes the bug and the security flaw together.

Cross-site scripting is when text a user typed is put into a page without escaping, so the browser reads it as part of the page’s HTML; if it contains a script, the script runs in the browser of everyone who views the page, as if the site had sent it.
On a site where teachers sign in, a script in a comment would run in a teacher’s browser with the teacher’s sign-in: it could send requests as the teacher (change marks, delete notices), read what the page shows them, show a fake sign-in box to steal their password, or read their session cookie if it isn’t HttpOnly.
Prevention: escape every piece of user text when it is put into the page (html.escape() on the server, or a template that escapes automatically); in JavaScript use textContent, never innerHTML. Also limit the damage: HttpOnly session cookies, and a Content-Security-Policy that lets only the site’s own script files run.

1. No salt: users with the same password have the same hash, so a thief hashes each guess once and checks it against every user at once, and ready-made tables of common passwords’ hashes work immediately.
2. Fast: SHA-256 is built for speed, so a thief can try billions of guesses a second on one graphics card.

It should store a slow, salted hash made for passwords, with a random salt for each user from secrets, and the method and cost stored with it: for example new_password() in this unit, which uses hashlib.scrypt(password.encode(), salt=salt, n=2**14, r=8, p=5) and stores scrypt$16384$8$5$<salt>$<hash>. Check passwords with hmac.compare_digest().

Slow and salted: guesses needed = 10⁶ passwords × 1,000 users = 10⁹; each costs 600,000 fast hashes, so 10⁹ × 6 × 10⁵ = 6 × 10¹⁴ fast hashes; at 10¹⁰ a second, 6 × 10¹⁴ ÷ 10¹⁰ = 60,000 seconds ≈ 17 hours.
Fast and unsalted: each of the 10⁶ passwords is hashed once and looked up among all 1,000 users at once: 10⁶ ÷ 10¹⁰ = 10⁻⁴ seconds, a tenth of a millisecond.
The good storage multiplies the thief’s work by 1,000 × 600,000 = 600 million.

1. Line 4: user text in HTML, unescaped. A report containing HTML would become part of the page, and a script in it would run in every visitor’s browser (cross-site scripting). Fix: return "<h2>" + html.escape(item["what"]) + "</h2><p>Found at " + html.escape(item["place"]) + "</p>" (and import html).
2. Line 7: a session token anyone could guess. Only 900,000 possible values, from random, whose numbers can be predicted; someone could try values until one belongs to a signed-in member of staff. Fix: return secrets.token_urlsafe(32) (and import secrets).
3. Lines 9 and 10: SQL joined from a value, and nobody checked. The id is joined into the SQL (injection: if item_id came from the request as text, it could change the query), and session is never checked, so anyone could mark any item collected (elevation of privilege). Fix:
   if session not in sessions: return 401, "Sign in as staff"
db.execute("UPDATE items SET collected = 1 WHERE id = ?", (item_id,))
   (Also: hashlib is imported and not used here; if passwords are hashed elsewhere, check that it is with a slow, salted hash.)

For example, RockYou, 2009. Cause: an SQL injection flaw in its website, and passwords stored as they were typed, with no hashing. Harmed: individuals, 32 million of them, whose passwords were published, and since many reused them, their email and other accounts were opened; everyone online, because the list made password guessing better on every website afterwards; the company, which lost trust. Prevention: parameterized queries (no injection); a slow, salted hash (even when copied, the passwords would have been very costly to guess); and having the code reviewed, so the flaw was found by the company first.
(For TalkTalk: cause, SQL injection in old pages it didn’t know it had, not updated, two earlier attacks not followed up; harmed: 156,959 customers’ details, 15,656 with bank details, and the company (a £400,000 fine); prevention: an inventory of all its systems, placeholders, updates, investigating the first attack. For Twitter: cause, social engineering by phone and staff tools too powerful for one person; harmed: people who sent money, a community misled by trusted accounts, the company; prevention: security keys that a fake page can’t copy, fewer people with such tools, two-person approval.)

Using a computer or its data without the owner’s permission, or beyond the permission given, is a crime under Section 45 of Nepal’s Electronic Transactions Act, 2063, even if nothing is changed and the intention is good: up to three years in prison, a fine of up to Rs 2 lakh, or both. Downloading the list would be using data without permission, and would put the customers’ numbers in one more place they could leak from; posting about it before the shop fixes it would show others how to take the list, harming the customers.
He should stop, keep nothing, write down what he saw (the address, the time, what appeared), and tell the shop privately (its owner, or its security contact if the website has one), giving them time to fix it. That is responsible disclosure. If the shop doesn’t respond, a teacher can help him find who else to tell.

• a.Users: they must sign in again often, which is annoying on a site they use all day (so some sites choose a longer time for low-risk pages).
• b.Devices: a little speed and battery; and the data: if the key or PIN is forgotten, it is lost for ever.
• c.Data: the list is less useful; owners must ask at the office and describe their phone.
• d.Users: a code or a tap each time, and a phone to hand; losing the phone means a slow recovery.