How attacks work and get stopped

If you have written SQL, this attack should chill you more than any other.

Suppose you wanted to search by a name somebody typed in, and you built the SQL by joining strings together. With an ordinary name nothing happens. But what if the input were ' OR 'A'='A?

What you joined becomes the condition "name is empty, or A = A". Since A = A always holds, every row in the table comes back. Slip in -- and everything after it becomes a comment; add a ; and you can append another statement entirely.

What is being prodded is not a weakness in the database but your own code that joined text together. The attacker only typed characters into a box, and with that rewrote the very syntax of your SQL.

There is only one idea behind the countermeasure: stop the characters somebody typed from being read as SQL symbols.

The surest way is a placeholder. You leave a ? shaped hole in the SQL and hand the value over separately. Then a ' arriving is a ' as a character and never a syntax boundary. Nothing is built by joining text, so there is no gap in which to rewrite anything.

Where placeholders are not available, you replace characters that carry special meaning, such as ', with harmless forms (escaping). The aim is exactly the same.

What to watch here is not mixing this up with countermeasures for similar but different attacks. The exam lines them up deliberately.

• Replacing HTML tags with some other string → the countermeasure for cross-site scripting
• Rejecting input containing ../ → the countermeasure for directory traversal
• Limiting the length of input → the countermeasure for length problems (buffer overflow and the like)

This time the hole is on the way out. Say you meant to show a posted comment on screen and put it into innerHTML.

If the comment were <img src=x onerror="...">, that is not text — it gets read as a tag. The moment the load fails, whatever is inside onerror runs. Which means JavaScript written by an attacker runs in the browser of whoever is looking.

That it runs "in a visitor browser" is the crux of this attack. Cookies get taken, fake login boxes get shown. This is cross-site scripting (XSS).

The defence is to replace things on the way out so they are not read as HTML tags (escaping). Put it into textContent and input shaped like a tag simply shows up as ordinary text.

Setting it beside SQL injection makes it clear. The hole on the way in is SQL injection; the hole on the way out is XSS.

Cross-site request forgery (CSRF) is an attack that gets somebody already logged in to press the button for you.

Show them a booby-trapped page and it fires a request off to the real site by itself. The browser attaches the cookies automatically, so from the server point of view it looks as though the user did it. This is how people get made to close their accounts or transfer money. The defence is to check for a token issued by the screen the request should have come from.

The difference from XSS is what runs, and where. XSS has a script running in a visitor browser. CSRF needs no script at all; it has a visitor perform an operation they did not intend, from another site.

The other one is directory traversal. Build things so a file name arrives from outside and somebody can line up ../ to read files in places you never meant to publish. The lesson is that the material for building a path must not come from outside.

There are attacks that stop you even with no holes in your code. Sending a huge volume of traffic until the service cannot be provided is a DoS attack (denial of service).

While it comes from one machine, blocking traffic from that source is enough. So attackers take over machines all over the place and have them all send at once. That is a DDoS attack (distributed). Because the sources are scattered, the awkward part is that there is nobody in particular to block.

A machine taken over and made to join in like this is called a stepping stone. From the point of view of whoever is under attack, the apparent culprits are the owners of the stepping stones.

This is where bots, coming later, connect. The herd of machines that make up the ammunition for a DDoS is usually ordinary PCs that were taken over and left that way.

The names look alike and get muddled, so line them up by what is held fixed and what is varied.

• Dictionary attack … fix one user ID and try words from a dictionary
• Brute force attack … fix one user ID and try combinations of characters one after another
• Reverse brute force attack … the other way round. Fix one password and try IDs exhaustively
• Password list attack … take a list of IDs and passwords leaked from another site and simply try logging in

The fourth is the one that actually gets through most often today. It leans on nothing but somebody having reused a password, so how long the password is makes no difference at all. Length and complexity only defend against the first three.

Those first three can be neutralised by stopping after enough wrong attempts (a login attempt limit). A password list attack gets past that too, so not reusing passwords is itself the countermeasure.

From here are the methods that get through even with no holes in the code.

Phishing sets up a fake site that looks just like the real one, lures you there by email or the like, and has you type your password in yourself. The attacker broke nothing. They only got you to type.

A targeted attack gives up on scattering messages indiscriminately and builds something aimed at one particular organisation. That is what makes it work: the subject and the body are made to look relevant to the recipient own job — "an invoice from a supplier", "a message from HR". Being on your guard against obviously suspicious spam will not save you.

Methods like these, which prod human psychology and carelessness rather than technology, are gathered under the name social engineering. Ringing up pretending to be an administrator and asking for a password, looking over somebody shoulder (shoulder hacking), picking discarded documents out of the bin — all of it counts.

Telling them apart is easy: is it a person being prodded, rather than a device? A brute force tool or a buffer overflow prods a machine, not a person, so neither is social engineering.

A man-in-the-middle attack is one where the attacker sits between two parties who are talking.

From both sides it looks like an ordinary exchange with the other party. In fact everything reaches the attacker first and is then passed along. So the contents can be read, and they can be rewritten.

Mere eavesdropping is stopped by encryption, but what makes this attack frightening is that the attacker can impersonate one side and take part in exchanging the keys. Which is exactly why an arrangement for checking that the other end is genuine is needed. That was the previous lesson.

Worth knowing one method used to set this up: DNS cache poisoning feeds nonsense mappings to whatever resolves names, steering you to a fake server. The name in the address bar is correct and only the destination differs, so it is hard to notice.

Software that does harm is gathered under the name malware. The exam asks about how it spreads and what it does, so sort them on those lines.

• Virus … spreads by attaching itself to other programs or files. It needs a host
• Worm … needs no host and makes copies of itself, spreading across a network on its own
• Trojan horse … does not spread. It poses as useful software, lurking as a standalone program, and waits until the conditions are right
• Bot … once it has taken over, it waits for orders from outside before acting. It becomes ammunition for a DDoS
• Ransomware … encrypts your files without asking and demands money to give them back
• Spyware … settles in unnoticed and gathers personal information and records of what you do, then sends them out

The server that gives bots their orders is called a C&C server (command and control). The mass of hijacked machines together with the C&C server is a botnet. The attacker never lifts a finger; they just direct from the C&C server — "attack that one", "gather information and send it".

When in doubt, split on whether it spreads by itself. Spreading by itself is a worm; waiting is a Trojan horse or a bot.

Since you can never say every hole is plugged, you also put in arrangements for stopping things before they get in. What stands at that boundary is the firewall.

Its most basic action is packet filtering. For each packet it looks at the source and destination addresses and port numbers and decides whether to pass it or drop it. Usually a list of rules is applied from the top down, stopping at the first that matches.

What becomes a problem here is where to put the servers you want to expose. A web server is pointless unless people can reach it from outside — but put the database holding customer data there too, and the moment the web server falls, the lot goes with it.

So you make one more room at the boundary: a middle zone reachable from both outside and inside, but from which only limited traffic reaches further in. That is the DMZ.

Put what you expose in the DMZ, and the data you want to protect inside. That is the answer this arrangement gives, and it is the right answer in the exam as it stands.

Packet filtering looks only at destinations and numbers. It never looks inside, so anything correctly shaped and arriving on port 80 goes through. Hence the tools that do look inside.

• IDS (intrusion detection system) … finds and reports suspicious traffic or behaviour. It does not stop anything
• IPS (intrusion prevention system) … finds it and stops it on the spot
• WAF (web application firewall) … looks as far as the contents of the HTTP exchange and blocks attacks aimed at web application vulnerabilities

Be clear about the WAF beat. It blocks attacks on application vulnerabilities before they land, which is how it stops input-driven attacks such as SQL injection. Equally, finding and fixing vulnerabilities, applying OS patches and detecting defects during development are all not its job. That is exactly what gets mixed into the choices.

The real countermeasure is still reducing the vulnerabilities themselves: keep applying fixes to the OS and libraries, validate input values, and confirm what is left with penetration testing (actually attacking to see whether you can get in). The tools that stop things early are there to buy time until the fix lands.