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...

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...

HTTP has no memory. Every request is independent, so applications issue a session identifier after login and the browser presents it with each subsequent request. That identifier is the authentication for the rest of the session — anyone holding it is the user, and no password is required. Session hijacking is simply obtaining someone else's. How tokens are stolen Cross-site scripting is the most common route. Injected JavaScript running in the victim's page can read cookies and send them anywhere, and because the script runs inside the site's own origin, nothing about it looks abnormal to the browser. Network interception works wherever a session travels unencrypted, which today usually means a mixed-content page or an application that redirects to HTTPS but has already exposed the cookie on the initial plaintext request. Malware on the endpoint reads tokens straight from browser storage, which is why stolen-cookie marketplaces exist and why a user who has been in...

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...

Cross-site scripting injects attacker-controlled script into a page that other users load. The script then runs inside that site's origin , with the same access the site's own code has — which is the part people underestimate, because "someone can run JavaScript" sounds less serious than it is. The three types Stored XSS is the most serious. The payload is saved on the server — in a comment, a profile field, a support ticket, a filename — and served to everyone who views that content. One injection, many victims, no interaction required beyond visiting a legitimate page. Stored XSS in an administrative interface is particularly severe, because the victim is an administrator. Reflected XSS takes the payload from the request and includes it in the response — typically a search term or an error message echoed back. It affects only the person who made the request, so it requires delivering a crafted link, usually with the destination hidden as under obfuscated ...

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...