Cybersecurity in Practice

Never trust the client

Unit 6 ended with a rule: the browser belongs to the user; the server belongs to you. Anyone can send your server any request, written by hand, from any program, with any values in it. So every check that protects something must run on the server, on every request, as if the request came from a stranger. Almost every flaw in this unit is that rule broken in one way or another: a server that believes what it was sent.

Start with the sessions of Unit 6. A session ID is the only thing that tells the server who is asking. Whoever holds it is that person, as far as the server can tell: it has no other way to know. So a session ID must be:

• impossible to guess: a long random value made with a generator meant for secrets (Python’s secrets module), never a counter, a name or a short number;
• hard to steal: sent only over HTTPS (the cookie’s Secure setting), out of reach of the page’s JavaScript (HttpOnly), and never put in an address, where it lands in browser histories and in other sites’ records of where their visitors came from;
• short-lived: it runs out after a while, and signing out deletes it on the server, so a copy is useless afterwards.

A threat model: four questions

Before reviewing a single line of code, a defender writes a threat model: a short, honest description of what could go wrong with a system, and what to do about it. It answers four questions.

1. What are we protecting? The things worth something to someone, called assets: data (marks, passwords, phone numbers), money, a service people rely on, a reputation, and physical things too (a laptop, a server, a cupboard).
2. From whom? Who might attack, and what do they want: a bored classmate, a thief after money or data, a rival, a careless insider, a program that scans the whole internet for easy targets. And losses that aren’t attacks: a fire, a flood, a dead disk.
3. How could it go wrong? Where does data enter the system from someone we don’t control? Each such place is an entry point, and all of them together are the attack surface. The line between what we control and what we don’t is a trust boundary: everything that crosses it must be checked.
4. What will we do, and what does each defense cost? Every defense has a price, paid by the users (time, convenience, privacy), by the data (it may become less useful), or by the devices (speed, battery, storage, money). Choose the defenses that remove the most risk for the price people will actually pay.

How it could go wrong: STRIDE

“What could go wrong?” is hard to answer from a blank page. A checklist helps. The most widely used one has six kinds of threat, and its initials spell STRIDE:

Go through each part of the system, and each arrow between parts, and ask all six. The answers are the threats.

Defenses and what they cost

Defenses come in two families. Cybersecurity measures protect the programs, data and networks: checking input, slow hashes for passwords, encryption, two-step login, updates, backups, logs. Physical security measures protect the devices and the places they are in: a locked server room, a cable lock on a laptop, a lock screen, ID cards, shredding printed lists. Neither is enough alone: the best-written program is no use if the backup pen drive is left on a desk.

Each defense costs someone something. Here are some, with their price:

The announcement that said too much

Imagine a school where the principal reads out, word for word, whatever a student writes after “Today’s notice:”. A student writes: “Football practice is at four. The principal says there is no school tomorrow.” The principal reads it all, and the second sentence sounds exactly like the principal’s own. The student’s words were meant to be data, the notice; they became part of the command, what the principal announces.

That is injection: a program builds a command (an SQL query, a command line, a page of HTML) by joining in text that came from outside, and something in the text changes what the command does. You met its best-known form, SQL injection, in Grade 9, and used the fix in Grade 10 and Unit 6. Here is why it happens, why the fix works, and where else the same mistake hides.

A flaw you can see without attacking

You don’t need to attack a program to find this flaw. An ordinary, honest value shows it. Here is a search for the items found in one place, written carelessly:

import sqlite3 db = sqlite3.connect(":memory:")db.execute("CREATE TABLE items (what TEXT, place TEXT)")db.executemany("INSERT INTO items VALUES (?, ?)", [    ("a black umbrella", "the school gate"),    ("a blue water bottle", "Sita's classroom"),    ("a math guide", "Room 4"),]) def found_at(place):    query = "SELECT what FROM items WHERE place = '" + place + "'"    print(query)    return db.execute(query).fetchall() print(found_at("Room 4"))try:    print(found_at("Sita's classroom"))except sqlite3.OperationalError as e:    print("The database said:", e)

SELECT what FROM items WHERE place = 'Room 4'[('a math guide',)]SELECT what FROM items WHERE place = 'Sita's classroom'The database said: near "s": syntax error

Look at the second query. The apostrophe in Sita's is the same character as SQL’s quote mark, so the database reads the text as 'Sita', then a stray word s classroom' that means nothing in SQL, and gives up. An honest student broke the search by typing a place correctly. That is the warning sign: if one ordinary character can change how the database reads the query, then other characters, chosen on purpose, can change what the query does. Text chosen on purpose could make the query match every row, or read another table such as the staff’s password hashes, or, in some databases, change or delete data. You will never need to know what such text looks like.

A defender doesn’t need to know which input would do that. Seeing user text joined into SQL is enough to know the code is wrong.

Why placeholders fix it

import sqlite3 db = sqlite3.connect(":memory:")db.execute("CREATE TABLE items (what TEXT, place TEXT)")db.executemany("INSERT INTO items VALUES (?, ?)", [    ("a black umbrella", "the school gate"),    ("a blue water bottle", "Sita's classroom"),    ("a math guide", "Room 4"),]) def found_at(place):    query = "SELECT what FROM items WHERE place = ?"    return db.execute(query, (place,)).fetchall() print(found_at("Room 4"))print(found_at("Sita's classroom"))

[('a math guide',)][('a blue water bottle',)]

The query is now fixed text, with a placeholder ? where the value goes, and the value is sent separately, in the tuple. A query written this way is called a parameterized query. It works because of the way a database runs SQL, which you saw for Python in Unit 4: first the SQL text is compiled into a plan of steps (in SQLite, into instructions for its own little virtual machine), and only then are the values bound to the placeholders, as data in memory. By the time Sita's classroom arrives, the plan is already made: “compare the place column with value number 1”. Whatever the value contains, quote marks, SQL words, anything, it can only ever be compared with places. There is no moment at which the database reads it as SQL.

That is the whole idea, and it is worth saying as a rule: keep the command and the data apart. Joining strings is fine for building a value; it is never fine for building a command.

What a placeholder can’t hold

A placeholder can stand only for a value, never for a part of the SQL itself, such as a column’s name. Suppose the board lets visitors sort the list by any column they choose. The column’s name has to go into the SQL text, so here the defense is an allow-list: a list of the only values the program accepts, checked before anything is joined.

SORTABLE = {"what", "place", "found_on"} def list_query(order_by):    if order_by not in SORTABLE:        raise ValueError("Can't sort by " + repr(order_by))    return "SELECT what, place, found_on FROM items ORDER BY " + order_by print(list_query("place"))print(list_query("found_on"))try:    print(list_query("color"))except ValueError as e:    print("Refused:", e)

SELECT what, place, found_on FROM items ORDER BY placeSELECT what, place, found_on FROM items ORDER BY found_onRefused: Can't sort by 'color'

Only three exact strings, written by the programmer, can ever reach the SQL. Anything else, honest mistake or not, is refused. An allow-list (“only these”) is almost always safer than a blocklist (“anything except these”), because the programmer knows every good value, but can never list every bad one.

The same mistake in other places

Injection isn’t only about SQL. Wherever a program builds a command for another program out of text from outside, the same mistake can happen, and the fix is always to keep command and data apart:

The last row is new, and has a name: prompt injection. A chatbot that summarizes your email reads the emails as part of its prompt; an email can contain sentences that look like instructions. Unlike SQL, a language model has no placeholders that keep instructions and data apart, which is why careful designers give an AI that reads outside text only the power to suggest, never to send, pay or delete on its own.

Text that the browser reads as a page

A web page is text in HTML, and the browser reads every < as the start of a tag. When a server puts something a user typed into a page, with no change, the browser can’t tell where the page’s own HTML ends and the user’s text begins. It reads it all as the page.

You can see this with no attack at all. Suppose someone reports a key that fell off a keyboard, and types its letter the way it is printed, inside angle brackets:

import html report = "The <i> key from a keyboard"print("<li>" + report + "</li>")print("<li>" + html.escape(report) + "</li>")print(html.escape('Tom & Jerry <3 "Ram\'s" pencil'))

<li>The <i> key from a keyboard</li><li>The &lt;i&gt; key from a keyboard</li>Tom &amp; Jerry &lt;3 &quot;Ram&#x27;s&quot; pencil

In the first line, <i> is HTML’s tag for italics: the browser shows “The key from a keyboard”, with the letter gone and everything after it on the page in italics, the rest of the list and the footer too, for every visitor. That is a harmless tag. Text that contains a script element instead, or one of the many other ways HTML has of running JavaScript, would run that program in every visitor’s browser, as if the website itself had sent it. This flaw is cross-site scripting, usually written XSS.

What a script in someone else’s page can do

A script that runs inside a page has the page’s powers, in the visitor’s browser, with their sign-in. On the lost-and-found board, if a member of staff opens the list, such a script could:

• send requests as that staff member, such as deleting every item, because the browser adds their session cookie by itself;
• read anything the page shows them, and send it elsewhere;
• change what the page shows: a fake “Your session ran out, sign in again” box that sends the password to someone else;
• read the session cookie itself, if it isn’t marked HttpOnly (Unit 6), and then the attacker has the session.

When the text was stored (a report, a comment, a profile name), it attacks everyone who opens the page later: stored XSS. When it is only reflected back from the request (a page that says “You searched for: …” and repeats the search words), an attacker must get the victim to open a crafted link: reflected XSS. The fix is the same for both.

The fix: escape what you show

Escaping means replacing each character that has a meaning in HTML by a code that shows the character itself: < becomes <, > becomes >, & becomes &, and quote marks become " and '. That is what html.escape() did in the program above, and in Unit 9’s certificates. The browser then shows the angle brackets instead of reading them: The <i> key from a keyboard, exactly as typed.

The rules that make it work:

• Escape when you put text into the page, every time, whatever the text is and wherever it came from: a report, a name, a value from your own database (which someone else put there), even an error message that repeats what was typed.
• In the page’s JavaScript, use textContent, never innerHTML, for text (Unit 6 and Grade 9): the browser puts it in as text and never reads it as HTML.
• Mind where the text goes. Escaping is right for text between tags and inside quoted attributes. A link’s address is different: an address can itself say “run this script” instead of “open this page”, so check what kind of address it is, with an allow-list (only https://). Never put user text inside a <script> element or a style.
• Let the tools do it. Web frameworks’ page templates escape every value automatically unless told not to. The flaw comes back when a programmer switches that off “just here”, or builds HTML by joining strings, as below.

Two more defenses limit the damage if a flaw slips through anyway (defense in depth, Grade 9): session cookies marked HttpOnly, so a script can’t read them; and a Content-Security-Policy, a header in the server’s response that tells the browser which scripts the page may run (for example, only scripts from the site’s own files, none written into the page), so injected script is refused.

Counting the thief’s guesses

Grade 9 showed how a careful website stores passwords: never the password, but a salted, slow hash of it. Now see why, by counting. No password is cracked here: we only count how much work a thief would have to do.

Suppose the board’s database is copied: through a flaw like the ones above, a backup on a lost pen drive, a careless insider. The thief has every user’s stored value. A hash can’t be undone, so the thief can only guess: take a likely password, hash it, and see whether the result is in the table. How long that takes depends on three numbers:

1. How many guesses. Most people choose from a small set: common passwords, names, words, dates. When RockYou, a website that made apps for social networks, lost 32 million passwords in 2009, the 5,000 most common passwords on it were used by one user in every five (Imperva’s analysis). A list of a few million leaked passwords covers far more. Four words picked truly at random from a list of 7,776 give 7,776⁴, about 3.7 × 10¹⁵ possibilities.
2. How much each guess costs. A fast hash such as SHA-256 is built to be quick: a gaming graphics card works out billions a second. A slow hash made for passwords (scrypt, PBKDF2, Argon2, bcrypt) is built to cost a lot, deliberately: PBKDF2 at 600,000 rounds costs at least 600,000 fast hashes per guess; scrypt also needs a block of memory for each guess, which makes graphics cards, with their thousands of small cores sharing little memory, much less of an advantage.
3. How many users each guess covers. Without salt, every user with the same password has the same hash, so the thief hashes each guess once and looks it up among all the stored hashes at once, in a dictionary (Unit 3’s hash table: about one step, however many users). With a different random salt for each user, each guess must be hashed again for every user: the work is multiplied by the number of users.

So: work = guesses × users (if salted) × cost of each guess.

A slow hash, by hand

Here is the idea of a slow hash, in a program you can run: hash the password, then hash the result again, and again, 100,000 times. The program times one guess both ways, on whatever device you are using.

import hashlibimport time  def fast_hash(salt, password):    return hashlib.sha256((salt + password).encode()).digest()  def slow_hash(salt, password, rounds=100_000):    """For learning only: the idea of a slow hash, the same hash again and again."""    h = (salt + password).encode()    for _ in range(rounds):        h = hashlib.sha256(h).digest()    return h  guesses = ["123456", "password", "namaste", "sagarmatha", "kathmandu"]for name, hash_it in [("fast", fast_hash), ("slow", slow_hash)]:    start = time.perf_counter()    for guess in guesses:        hash_it("k7Qp2x", guess)    each = (time.perf_counter() - start) / len(guesses)    print(f"{name}: {each * 1000:.4f} ms a guess, about {1 / each:,.0f} guesses a second")

On a laptop, the fast hash manages hundreds of thousands of guesses a second even in Python, the slow one about twenty (fewer still on this page, where Python runs inside the browser, and on a phone). The user signing in waits a fraction of a second, once; the thief waits that long for every guess, for every user.

The real thing, in Python

Python’s hashlib module has scrypt. This is how a real server stores and checks a password. (The Python on this page has no scrypt, because the browser’s version of Python leaves out the library it comes from; run this one on a computer.)

import hashlibimport hmacimport secrets N, R, P = 2**14, 8, 5      # the cost of every guess: memory and time  def new_password(password):    """What to store when someone sets a password."""    salt = secrets.token_bytes(16)    key = hashlib.scrypt(password.encode(), salt=salt, n=N, r=R, p=P)    return f"scrypt${N}${R}${P}${salt.hex()}${key.hex()}"  def check_password(stored, typed):    """True if typed is the password that stored was made from."""    _, n, r, p, salt, key = stored.split("$")    again = hashlib.scrypt(typed.encode(), salt=bytes.fromhex(salt),                           n=int(n), r=int(r), p=int(p))    return hmac.compare_digest(again.hex(), key)  sita = new_password("tiger rice window")print(sita[:17] + "…", len(sita), "characters")print(check_password(sita, "tiger rice window"))print(check_password(sita, "tiger rice windows"))print(new_password("tiger rice window") == sita)

scrypt$16384$8$5$… 178 charactersTrueFalseFalse

Read it closely; every line is there for a reason:

• Line 5: the cost. n sets how much memory each guess needs (here 16 MiB) and p how many times the work is done; together about a tenth of a second on an ordinary computer.
• Line 10: a new random salt for every password, from secrets, Python’s module for security (never random, which is made for games and simulations, and whose numbers can be predicted).
• Line 12: the stored value names the method, the cost and the salt, then the hash. The salt is no secret; it is needed to check the password. Because the cost is stored too, the server can raise it in a few years, when computers are faster, and still check old passwords; it re-hashes each one the next time its owner signs in.
• Line 20: hmac.compare_digest() compares in the same time whether the first character differs or the last, so how long the check takes tells an attacker nothing.
• The last line: the same password, signed up twice, gives a different stored value, because the salt is different. Nobody can tell that two users chose the same password.

A real review is rarely one flaw in three lines. Here is the staff part of a lost-and-found board, as a beginner might write it: sign-in, sessions, the list as HTML, and Delete. It has five flaws, one from each of the ideas so far. Find them all.

Fixes and their trade-offs

Finding a flaw is half the job. A reviewer also explains what each fix costs, so the owner can decide:

Notice which fixes are free: most flaws in code cost nothing to fix once they are seen. The expensive part is finding them, which is why teams have their code read by a second person before it goes live, and why the questions you asked in the widget, where did this come from, and where does it go?, are worth asking of every line.

A breach is any time someone gets at data or systems they shouldn’t. Investigators and regulators publish reports of the big ones, and reading them is how the whole industry learns. For each, ask three questions: what caused it, who was harmed and how, and what would have prevented it.

Notice the pattern. Two of three began with a flaw in code that was well known and easy to fix; the third needed no code at all. And in every case, more than one thing went wrong before harm was done: defense in depth means that one failure shouldn’t be enough.

Only with permission

In Grade 9 you studied Nepal’s Electronic Transactions Act, 2063. Its Section 45 makes it a crime to use a computer, a program or data without the owner’s permission, or beyond the permission given, whether or not anything is changed, with up to three years in prison, a fine of up to Rs 2 lakh, or both Grade 9: Crimes involving computers. Damaging data is Section 46. “Just testing” a website you don’t own, to see whether a flaw is there, is using it beyond the permission given, however good the intention. Other countries’ laws say the same.

So security testing is done only with the owner’s written permission, saying exactly what may be tested, how, and when. Companies hire penetration testers (“pen testers”) to try to break into their own systems under such an agreement; the agreement is what makes it a job and not a crime. The only systems you may test freely are your own: the app you build in the project below, on your own computer.

If you find one by accident

Sometimes a flaw just shows itself: a page shows someone else’s marks; a link opens a folder of other people’s files. What you do next matters:

1. Stop. Don’t look further, don’t try it again to be sure, don’t download or keep anything, don’t show your friends.
2. Write down what you saw: the address, the time, what appeared, what you did just before.
3. Tell the owner, privately. Look for a security contact: many sites list one in a file at /.well-known/security.txt (a standard since 2022) or on a page called “Security” or “Report a vulnerability”. For a school or government site, tell the office that runs it; a teacher can help you find who that is.
4. Give them time to fix it, and don’t make it public until they have.
5. Never ask for money in return for keeping quiet: that is blackmail, a crime of its own.

This is responsible disclosure, also called coordinated vulnerability disclosure: the finder and the owner agree on when the flaw is fixed and when it can be described, so that users are protected before attackers learn of it. Many companies go further and run a bug bounty: a public invitation, with written rules (which systems, which kinds of testing, what is off limits), promising not to take legal action against those who follow the rules and paying a reward for each real flaw reported. Inside a bug bounty’s rules, testing is permitted, because the owner has given permission in writing; outside them, it isn’t.

Work in pairs, on the lost-and-found board you built in Unit 6 (or any small web app you have built yourselves). You are its owners, so you have permission to test it, on your own computer only.

1. Threat model. Draw its trust boundary, as in Figure 7.1. List its assets, who might attack, and its entry points. Go through STRIDE for each entry point. Write a table of threats, defenses and their costs, and choose the three most important.
2. Review. Swap code with another pair. Read theirs line by line, following everything that comes from outside: where does it enter, where does it go? List every flaw you find, with the line, what harm it could allow (in words, never as an attack), and the fix. Give the list back.
3. Fix. Fix the flaws found in your own code. For each, write one sentence on its trade-off.
4. Passwords. Add the staff sign-in, with new_password() and check_password() from this unit, and a session ID from secrets. Check that two staff with the same password get different stored values.
5. Test the defenses, honestly. Report an item at a place with an apostrophe (Sita's classroom) and one whose description contains angle brackets (The <i> key). Both should be saved and shown exactly as typed. Send a Delete without a session cookie (with ask.py from Unit 6): it should be refused with 401.
6. Present your threat model, one flaw the other pair found in your code and how you fixed it, and the defense you chose not to add, with your reason.

With only a phone: do steps 1, 2 and 3 on paper with the programs in this unit and in Unit 6, and the review in the widget above; for step 4, read passwords.py and explain each line to your partner.