Common Network Attacks

Every time you log in to a website, stream a video or fill in an online form, your device is talking to a server across a network. Most of that traffic is friendly — but some of it is sent by attackers trying to break in, steal data, or knock a service offline. To keep systems safe you first have to understand how these attacks work, so you can spot them and defend against them.

This page looks at three of the classics you need for GCSE: the brute-force attack, the denial-of-service (DoS/DDoS) attack, and SQL injection. For each one we cover the idea — what the attacker is trying to do — and the defence that stops it. We are learning the locks and the burglar-proofing, not how to be a burglar: there are no working attack recipes here, only the concepts and how to shut them down.

1. Brute-force attacks

A brute-force attack is the least clever attack of all: the attacker simply guesses passwords over and over, trying combination after combination until one works. A computer can test thousands of guesses per second, so a short or common password (1234, password, your pet's name) can fall almost instantly.

The picture below shows the idea: an attacker's program churns through a list of guesses. If the real password is in that list, the door opens. Step through it:

Why length is the best defence

The single most powerful defence is a long password from a big alphabet. Each extra character multiplies the number of possibilities the attacker must try. If your alphabet has A possible characters and your password is L characters long, the number of combinations to check is:

N = A^{L}

Because L is an exponent, adding just one more character can make the attacker's job many times harder. Try it — change the length and alphabet size and press Run to see how fast the number of guesses explodes:

// How many guesses must a brute-force attack try, in the worst case? // N = A^L, where A = size of the alphabet, L = length of the password. const alphabet: number = 26; // e.g. 26 lowercase letters const length: number = 8; // password length const combinations: number = Math.pow(alphabet, length); console.log("Alphabet size A = " + alphabet); console.log("Password length L = " + length); console.log("Worst-case guesses N = A^L = " + combinations.toLocaleString()); // At a (fast) 1,000,000,000 guesses per second, how long is that? const perSecond: number = 1_000_000_000; const seconds: number = combinations / perSecond; const years: number = seconds / (60 * 60 * 24 * 365); console.log("At 1 billion guesses/sec, worst case ~ " + years.toFixed(4) + " years"); // Try bumping length to 12, or the alphabet to 95 (letters + digits + symbols)!

The other defences all attack the speed of guessing rather than the number of combinations:

Account lockout — after, say, 5 wrong tries the account is locked for a while, so an attacker can't fire off thousands of guesses.
Rate limiting — the server refuses to accept guesses faster than a set rate (a few per minute), turning a "millions per second" attack into a crawl.
Multi-factor authentication (MFA) — even a correct password isn't enough without a second factor (a code on your phone), so guessing alone gets nowhere.

2. Denial-of-service (DoS & DDoS)

A denial-of-service attack doesn't try to break in at all — it tries to make a service unavailable to everyone else. The attacker floods the server with so much fake traffic that it has no capacity left to answer real users. Imagine one till at a shop and a hundred people crowding the counter just to ask the time — genuine customers can never reach the front.

A DDoS (Distributed Denial-of-Service) is the same idea but the flood comes from thousands of computers at once — often ordinary machines hijacked by malware to form a botnet. Because the traffic arrives from many different places, it is much harder to block. The diagram shows many attacking machines all aiming at one server:

Defending against DoS/DDoS

Traffic filtering — a firewall or specialist service inspects incoming traffic and drops the junk before it reaches the server.
Rate limiting — cap how many requests any one source may send per second, so a single machine can't hog the server.
Extra capacity & load balancing — spreading traffic across many servers so the load can be absorbed.
Anti-DDoS services — companies that sit in front of a website and soak up floods before they land.

The hard part is telling a real visitor from a fake one. A single attacking machine is easy to block — but in a DDoS the requests come from thousands of scattered, ordinary-looking devices, each sending a modest amount. Every individual request looks almost legitimate, so a filter that's too aggressive would also lock out genuine users. Defence is a constant balancing act between blocking the flood and letting real people through.

3. SQL injection

Many websites store their data in a database, and they fetch it using a language called SQL. When you type into a login box or search field, the website builds an SQL query from what you typed. An SQL injection attack happens when a site trusts your input too much: the attacker types in cleverly crafted text so that part of their input is treated not as ordinary data but as part of the query itself — potentially reading, changing or deleting data they should never see.

The root cause is always the same: user input got mixed up with the command. Here's a deliberately unsafe pattern (shown so you can recognise the danger — never write code like this):

// UNSAFE — do NOT do this. The user's text is glued straight into the query. const username: string = getInput(); const query: string = "SELECT * FROM users WHERE name = '" + username + "'"; // If the input contains SQL punctuation, it can change what the query does.

The fix is to never build a query by gluing text together. Instead, use a parameterised query (also called a prepared statement), where the user's input is handed to the database separately and can only ever be treated as a value, never as a command:

// SAFE — the '?' is a placeholder; the input is passed as a separate value, // so the database always treats it as plain data, never as part of the command. const username: string = getInput(); const query: string = "SELECT * FROM users WHERE name = ?"; db.run(query, [username]); // input can never become code

Defending against SQL injection

Parameterised queries / prepared statements — the main defence: keep the command and the data strictly separate.
Input validation — check that input is the right shape (e.g. a username is only letters and digits) and reject anything unexpected.
Escaping — neutralise special characters so they can't be read as SQL.
Least privilege — give the website's database account only the permissions it truly needs, so even a successful attack can do less damage.

Anything a user can type is untrusted until you have checked it.
Data from a user must stay data — it must never be allowed to become part of a command or query.
Validate, escape, or parameterise every input on the way in; a single unchecked field is enough to let an attacker in.

The pattern across all three

Notice the common thread. A brute-force attack abuses the fact that guessing is allowed — so we limit the guessing and make passwords long. A DoS abuses the fact that the server answers everyone — so we filter and rate-limit the traffic. SQL injection abuses the fact that input is trusted — so we never let input become code. Each attack exploits a different kind of over-trust, and each defence is about trusting less and checking more.

We explain how these attacks work for one reason only: so you can defend against them. Two ideas do most of the heavy lifting. First, SQL injection is beaten by never trusting user input — always validate or escape it, and use parameterised queries so a user's text can never turn into a command. Second, long passwords make brute-force impractical: because the number of combinations is A^{L}, every extra character multiplies the attacker's work, so length matters far more than swapping a letter for a symbol in a short password. Understanding the attack is what lets you close the door on it.