CompTIA Exam Prep - ITF+, A+, Network+, Security+, CySA+

SQL injection happens when user-supplied input is concatenated into a database query instead of being passed as data. The database cannot tell the difference between the query the developer wrote and the fragment the attacker appended, because by the time it arrives they are the same string. Decades after it was first documented it is still a leading cause of breaches, and it still appears on every security certification. The root cause in one line Building a query by string concatenation mixes code and data in the same channel. Input intended as a value — a username, a product ID — becomes part of the query's structure the moment it contains SQL syntax the parser will honor. Everything else about the vulnerability follows from that. The attack payloads vary by database and context, but the defect is always the same: the boundary between instruction and input was never established. The categories In-band injection returns results through the same channel used to atta...

Memory corruption vulnerabilities still exist, and yet exploiting them reliably is far harder than it was twenty years ago. That change came from a stack of mitigations, each addressing one step an exploit must complete. None of them fix the underlying bug — they make the bug expensive to turn into code execution. What an exploit has to achieve Understanding the mitigations requires understanding the steps. A classic stack overflow overwrites a return address so that when the function returns, execution jumps to attacker-chosen code. To succeed, the attacker needs to overwrite the right memory, needs somewhere to put code or something useful to jump to, and needs to know the address of that thing. Each mitigation removes one of those. Stack canaries A random value placed between local variables and the saved return address. Before returning, the function checks it is unchanged; if a linear overflow has overwritten the return address, it has overwritten the canary too, and t...

Most of the code in a modern application was not written by the team that ships it. Frameworks, libraries, and their dependencies typically make up the large majority of a deployed artifact, and every one of them carries whatever vulnerabilities it has. Software composition analysis is the practice of finding out what you are actually shipping and what is wrong with it. Transitive dependencies are the problem A team declares perhaps twenty direct dependencies. Each of those pulls in its own, and those pull in more, so the resolved tree commonly runs to hundreds or thousands of packages. Almost nobody has reviewed that tree. When a vulnerability is announced in a low-level utility library, the question "are we affected" is unanswerable by reading your own manifest, because the affected package is four levels down and was never chosen by anyone. That is why the recent high-profile dependency incidents caused such widespread scrambling: organizations could not determine expo...

Four categories of application security testing exist because each one sees something the others cannot. Choosing between them is the wrong framing; knowing which finds what, and therefore what you are still blind to, is the useful skill. DAST: testing the running application Dynamic Application Security Testing exercises a deployed application from the outside, sending requests and analysing responses. It has no access to source code — it behaves like an attacker with a browser and a great deal of patience. Its strength is that it tests what is actually running: the deployed configuration, the web server, the framework, the authentication flow, and the interactions between components. A finding is real by construction, because the scanner reproduced it against the live system, which keeps false positives low. It reliably finds injection flaws, cross-site scripting, authentication and session weaknesses, security header and TLS misconfiguration, information disclosure in erro...

Some denial of service attacks need no volume at all. A single small request that causes the server to do an enormous amount of work is far more efficient than flooding it, and it arrives through a path the network controls cannot see — a legitimate-looking request on an ordinary connection. The unifying property is asymmetry between input size and processing cost , and the defence is always a limit. Expansion bombs Entity expansion is the classic. An XML document defines an entity referencing another entity several times, which references another, nested a dozen levels deep. Each layer multiplies, so a few kilobytes expand to gigabytes when parsed, exhausting memory. The parser is doing exactly what it was told. Decompression bombs work identically on archives. A small compressed file expands to an enormous one, and nested archives multiply it further. Anything that decompresses untrusted input is exposed — mail gateways scanning attachments, malware sandboxes, backu...

XML has a feature that lets a document define entities — shorthand names expanded when the document is parsed — and an entity may be external , meaning its content is fetched from a URI when the parser expands it. A parser that honours that feature on untrusted input will fetch whatever the attacker names, which is the whole vulnerability. What it enables Local file disclosure. An external entity referencing a file path causes the parser to read that file and insert its contents into the document, which the application then processes and frequently echoes back. Configuration files with database credentials, private keys and system files are the usual targets. Server-side request forgery. An entity referencing a URL makes the server issue that request, from inside the network. That reaches internal services and, in cloud environments, the instance metadata endpoint that returns temporary credentials — the escalation described under SSRF . XXE is one of the most co...

Server-Side Request Forgery tricks a server into making an HTTP request the attacker chooses. The server is the one that connects, so the request comes from inside the network with whatever access the server has — which is the entire point. SSRF turns a web application into a proxy into places the attacker cannot reach directly. Where it comes from Applications fetch URLs for legitimate reasons: importing an image from a link, rendering a page to PDF, validating a webhook endpoint, retrieving an XML schema, previewing a shared link. Any feature that takes a URL from a user and retrieves it is a candidate. It also appears indirectly through document parsers, XML processing with external entities enabled, and libraries that follow redirects without the developer realizing a fetch is happening at all. Why it is severe Internal network access. The server can reach private address ranges the internet cannot. An attacker can enumerate internal hosts and ports by observing respon...

Threat modeling is examining a design to find security problems before they are built. The frameworks get most of the attention; the practice is simpler than the frameworks suggest, and the part that determines whether it works is the diagram. The four questions A widely used framing, and a good structure for a session. What are we building? A shared understanding of the system, which is where most of the value appears — teams routinely discover during this step that they disagree about how their own system works. What can go wrong? The threat identification, structured by a taxonomy such as STRIDE . What are we going to do about it? Mitigations, with owners. Did we do a good job? Review and iteration. The data flow diagram The artefact everything else depends on, and it needs only five element types. External entities — users, third-party services, anything outside your control. Processes — components that do something. Data stores — databases,...

A key derivation function turns input material into cryptographic keys. There are two distinct jobs, they have different requirements, and using the function designed for one to do the other is a recurring mistake worth understanding. Two different problems Deriving a key from a password. The input is low-entropy — a human chose it — so the function must be deliberately slow to make guessing expensive. This is key stretching, and it is what PBKDF2, bcrypt, scrypt and Argon2 do. Deriving keys from an existing high-entropy secret. The input is already strong — a shared secret from a key exchange, a master key, random bytes — so slowness serves no purpose and would only cost performance. The function must distribute the input's entropy evenly and produce independent outputs. This is what HKDF does. The distinction to hold: slowness is a defence against guessing, and it is pointless when there is nothing to guess. Running a shared secret from a Diffie-Hellma...

File inclusion vulnerabilities occur when an application uses user-supplied input to decide which file to load. The intended behaviour is selecting a template or a language file from a fixed set; the actual behaviour, when the input is not constrained, is loading whatever the attacker names. Local file inclusion LFI reads files already present on the server. A parameter meant to select a page instead receives a path with traversal sequences — ../ repeated enough times to climb out of the intended directory and then descend to something interesting. Standard targets tell you a lot about a system: the password file and user list, application configuration files containing database credentials and API keys, environment files, private keys, and log files. On Linux, the process filesystem exposes environment variables and command lines for running processes, which frequently contain secrets passed at startup. Even without code execution this is a serious finding. Configuration fi...

A race condition occurs when the correctness of an operation depends on the timing of events the program does not control. In security terms the classic form is time-of-check to time-of-use — a program checks a condition, then acts on it, and something changes in the gap between the two. The TOCTOU pattern The structure is always the same. Check that a condition holds. Act on the assumption that it still holds. The window between them is where the attacker operates. The filesystem case is the textbook one. A privileged program verifies that a file is owned by the user and is not a symbolic link, then opens it to write. Between the check and the open, the attacker replaces the file with a link to something privileged. The check passed on the real file; the write lands on the target. The window may be microseconds, which sounds impractical and is not — an attacker repeats the attempt thousands of times, and can widen the window by loading the system or by using filesyste...