Application, code and operating-system vulnerabilities

Objective 2.4 asks you to explain vulnerabilities and attack surfaces. This lesson takes the weaknesses that live in software: race conditions, malicious updates, the coding mistakes SY0-801 now names — secrets left in source and careless error handling — injection as a class, operating-system and cryptographic flaws, and the zero-day. The next lesson takes systems, credentials, devices and exposed services.

Why this matters

This objective asks you to explain vulnerabilities, not to exploit them, and that is how the exam treats them. You are expected to recognise a described weakness by name, know what class of control addresses it, and not confuse it with the attack that uses it.

That last distinction is the one that costs marks. Injection is a vulnerability in 2.4 and an attack in 2.5, and the two objectives ask different questions: 2.4 asks what the weakness is and how it is fixed, 2.5 asks what its exploitation looks like in a log.

The lesson

Race conditions: time-of-check to time-of-use, and why the gap matters

A race condition is a flaw where the outcome depends on the timing of events that were assumed to happen in order.

The security-relevant form is time-of-check to time-of-use (TOCTOU). The program checks a condition — this file is safe, this user has permission, this balance is sufficient — and then acts on it. Between the time of check and the time of use there is a window, and if the thing being checked can change inside that window, the program acts on a decision that is no longer true.

A file-system example: a program confirms that a path points to an ordinary file, then opens it — and in between, the path is swapped to point at a privileged file. The check passed; the open hit the wrong file.

The same shape appears in business logic: a voucher validated and then redeemed, or a balance checked and then debited, where many simultaneous requests all pass the check before any of them completes the use. That is why the exam's race condition scenarios often describe "the same request submitted many times at once" and a voucher or withdrawal that succeeded more often than it should have.

The fix is to make check and use atomic — one indivisible operation, or a lock held across both — rather than to shorten the window, which only makes the flaw harder to hit rather than impossible.

Malicious updates, and the trust an updater is granted by design

A malicious update installs successfully, is signed correctly, arrives through the official channel — and is hostile.

It deserves its own heading because it inverts the usual advice. "Keep software patched" is correct and stays correct, and it also means every machine has a standing agreement to run code a third party sends it, with privilege, automatically.

Three routes:

• the vendor's build pipeline is compromised, so the malicious code is present before signing and the signature is genuine;
• the vendor's signing key is stolen, so an attacker can sign anything;
• the distribution channel is compromised, the weakest of the three because signature checking catches it.

What you can do: verify signatures, obtain software from the vendor rather than a mirror, stage updates so a small group gets them first, monitor what newly updated software does rather than assuming an update is inert, and know what every agent on your machines is allowed to do. Then accept the residual risk consciously, which is a Domain 5 decision, not a technical one.

Secrets hard-coded into source, and error handling that tells an attacker too much

Two code-level weaknesses SY0-801 names directly.

Hard-coded secrets are passwords, API keys, tokens, private keys and connection strings written into source code, configuration files, scripts or container images. They leak because code travels: it is pushed to repositories, shared with contractors, shipped inside mobile apps and desktop software where it can be read back out, and copied into build logs. Two facts make it worse. Version control remembers, so deleting the secret in a later commit leaves it in the history. And the same secret is often used in every environment, so one leak opens production.

Controls: keep secrets in a secrets manager or vault and fetch them at run time; run secrets scanning before code is committed and in the build pipeline; give each environment its own credentials; and when a secret is exposed, rotate it — removing it from the code is not enough, because it must be assumed copied.

Unsafe exception handling is what happens when code meets an error it did not plan for. Three failures to recognise:

• Information disclosure — a detailed error page showing a stack trace, a database query, file paths or software versions, which gives an attacker a map of the application.
• Failing open — an error inside a security check is caught and ignored, so processing continues as though the check had passed.
• Crashing — an unhandled error stops the service, which is a denial of service anyone who can trigger it can repeat.

Controls: show users a generic message and write the detail to a protected log; design checks to fail closed, so an error means "deny"; handle errors centrally rather than in every function; and test error paths as deliberately as success paths.

Injection flaws, SQL and script injection among them, recognised as one class

Every injection flaw has the same root cause: input supplied by a user is treated as instructions rather than as data. The interpreter differs — a database, a browser, an operating system shell, a directory service, an XML parser — but the mistake does not.

• SQL injection exists when user input is joined into a database query, so part of the input is read as query syntax. Consequences run from reading data the user should not see to altering or deleting it. The fix is parameterised queries, where the query's structure is fixed and input can only ever be a value; input validation and a least-privilege database account limit the damage.
• Script injection (cross-site scripting) exists when user input is placed in a page without being neutralised, so a visitor's browser runs it. It may be stored and served to everyone, or reflected back from a crafted link. The fix is output encoding for the context, supported by a content security policy that restricts where scripts may load from.
• Command injection passes input to an operating system command; the fix is not to build shell commands from input at all, but to call functions that take arguments separately.

A web application firewall is a compensating control for all of them: it blocks known patterns and buys time, and it fixes none of them. When an exam option offers the WAF alongside parameterisation or encoding, the code fix is the answer.

Operating-system and cryptographic weaknesses, and the zero-day nobody has a patch for

OS-based vulnerabilities are flaws in the kernel, privileged services and drivers. They matter more than application flaws of similar severity because the OS enforces every boundary above it: one kernel privilege escalation defeats user permissions, application sandboxes and container isolation together. Watch for privilege escalation flaws, which turn a limited foothold into full control; driver flaws, which run with very high privilege and are often patched by the hardware vendor on a different schedule; and memory-safety flaws such as buffer overflows, which platform protections like address randomisation and non-executable memory make harder to exploit without removing.

Cryptographic vulnerabilities are weaknesses in how data is protected rather than in the logic around it:

• weak or deprecated algorithms — MD5 or SHA-1 for integrity, DES or RC4 for confidentiality;
• short keys that modern hardware can search;
• legacy protocol versions left enabled, such as SSL or early TLS;
• poor randomness, which makes keys or tokens predictable;
• implementation errors — keys hard-coded or reused, certificates not validated.

The controls are to use vetted libraries rather than writing cryptography, disable deprecated algorithms and versions outright, keep an inventory of where cryptography is used so it can be replaced when an algorithm falls, and manage keys properly.

A zero-day is a vulnerability the vendor does not yet know about, or knows about but has not fixed — so no patch exists. You cannot patch your way out of it. What helps is everything that does not depend on knowing the specific flaw: defence in depth, segmentation that limits where a compromised system can reach, behavioural detection that notices what the exploit does, least privilege so the foothold is small, and fast application of the vendor's interim mitigation — or a WAF or IPS rule as a virtual patch — once the flaw is announced.

What to take into the exam

• TOCTOU is fixed by making check and use atomic, not by shortening the gap.
• A malicious update is correctly signed and arrives normally; staging and behavioural monitoring are what help.
• A hard-coded secret that has been exposed must be rotated; scanning and a vault stop the next one.
• Unsafe exception handling leaks detail, fails open or crashes. Generic errors for users, detail in logs, fail closed.
• Injection is one class: data treated as instructions. Parameterised queries fix SQL injection; output encoding fixes script injection; a WAF fixes neither.
• A zero-day has no patch; defence in depth and behavioural detection are the answers.