← Back to GCSE guidesCodeBash GCSE Computer Science← PreviousNext →
Cyber Security

Threats and Vulnerabilities

Every attack on this page exploits either a technical weakness (software that trusts input it shouldn't) or a human one (people who trust messages they shouldn't). Understanding both is the entire point of this topic: you can't defend against a threat you can't recognise.

Section 2

Malware: not all the same thing

"Malware" is a catch-all term. Exam questions usually want the specific type, because they behave, and spread, in genuinely different ways.

Click a malware type above.
Section 3

Social engineering: attacking the human, not the machine

No amount of technical security helps if someone can just be persuaded to hand over their password. Click each suspicious phrase below to reveal exactly what makes it a red flag.

Found 0 of 5 red flags. Click the underlined phrases.
Click a highlighted phrase in the email to see why it's suspicious.

Other social engineering techniques

  • Pretexting (blagging): inventing a false scenario to obtain information, e.g. phoning and claiming to be IT support who "just needs your password to fix an issue".
  • Shoulder surfing: simply watching someone type their password or PIN over their shoulder, no technology involved at all.
  • Pharming: malicious code redirects a user to a fake website even when they typed the correct address, unlike phishing, the user did not need to click anything suspicious.
Section 4

Denial of Service: winning by overwhelming, not breaking in

A DoS attack doesn't need to find a clever vulnerability at all. It just needs to send more requests than the server can possibly handle, so genuine users can't get through. Watch the server's capacity fill up.

Controls

Exam tips

  • DoS: one attacking machine. DDoS (Distributed DoS): many machines, often an unwitting "botnet" of infected devices, attacking at once, making it much harder to block by simply banning one source address.
  • The goal isn't theft, it's denying legitimate users access, which is exactly why it's named what it is.
Section 5

SQL injection: when input is trusted too much

This is a conceptual, illustrative walkthrough of the classic textbook example, showing why unsanitised input is dangerous and how it's actually prevented, not a working attack against any real system.

A login form's query, built by joining text directly

What does the user type?

The defence: parameterised queries

The actual fix isn't "block certain words", it's never building a query by joining raw text together at all. A parameterised query keeps the structure and the data completely separate, so user input can never be interpreted as part of the query's logic, no matter what characters it contains.

SELECT * FROM users WHERE username = ? AND password = ? -- the ? placeholders are filled in safely afterwards, -- whatever the user typed is always treated as pure data, -- never as part of the query's actual structure.
Section 6

Data interception: reading traffic that isn't yours

Data travelling across a network can, in principle, be read by anyone positioned along its route, using tools called packet sniffers. Whether that's a problem depends entirely on one thing.

Unencrypted (e.g. HTTP)Encrypted (e.g. HTTPS)
If interceptedThe intercepted data is readable exactly as sent, including passwords typed into a formThe intercepted data is scrambled ciphertext, useless without the decryption key
Where this mattersPublic WiFi is the classic risk, anyone else on that network can potentially capture unencrypted trafficThe padlock icon in a browser is confirming this protection is active for that specific connection

This connects directly to the earlier networking work: encryption doesn't stop interception from being possible, it makes the intercepted data useless, which is a completely different and far more practical defence.

Section 7

Check your understanding