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

Search engines index what they can reach, and what they can reach is frequently more than anyone intended. Documents, administrative interfaces, directory listings and error pages containing internal detail all end up indexed — and because the index is public and searchable, finding them requires no scanning, no tooling and no contact with the target at all. Why it is purely passive The distinction matters on the exam and in scoping. Querying a search engine touches the search engine, not the target. Nothing appears in the target's logs, there is no rate limit to trip and no detection to evade. Which means this is the first thing an attacker does and the cheapest thing a defender can check. It is also the reason a finding here cannot be detected after the fact — you will never know someone looked. What operators surface Search engines support qualifiers that narrow results to a site, a file type, a URL pattern, a page title or body text. Combining them turns a general...

LAMP — Linux, Apache, MySQL and PHP — still runs an enormous share of the web, and it is the stack most commonly deployed by someone following a tutorial. Every layer ships with defaults suited to getting something working quickly, and the gap between working and secure is where the incidents come from. What each layer does Linux is the operating system, providing the process, filesystem and network foundation. Apache receives HTTP requests, serves static files and hands dynamic requests to the application. MySQL or MariaDB stores the data. PHP executes the application code. Requests flow through all four, and a weakness at any layer is a weakness in the whole stack. The variants — nginx in place of Apache, PostgreSQL in place of MySQL, Python or Perl in place of PHP — change the components and not the reasoning. Linux Run each service as its own unprivileged account, never root, so a compromise of one is bounded. Set filesystem permissions so the web ...

Security headers are instructions a server sends telling the browser to enforce restrictions on its own page. That framing matters: the browser does the enforcement, and a client that ignores the header enforces nothing. Headers are defense in depth, not a substitute for fixing the underlying flaw. They also happen to be among the cheapest controls available — configuration, not code — which is why they appear on every hardening checklist and in a steady stream of exam questions. Content Security Policy CSP is the most powerful and the most frequently misconfigured. It declares which sources the browser may load scripts, styles, images and frames from. Anything outside the policy is blocked. The attack it addresses is cross-site scripting. Even where an injection flaw exists, a strict policy prevents the injected script from executing, because inline script and unapproved origins are not permitted. Two things undo it. unsafe-inline permits inline script, which is ...

The difference between a thorough web application test and a superficial one is almost never the tooling. It is whether the tester worked through a defined set of categories or poked at whatever looked interesting. A methodology exists to make coverage repeatable and gaps visible — and to let a second tester reach a comparable result. Information gathering Every structured test opens here, and skimping shows up later as missed functionality. Map the application: every page, every parameter, every endpoint, including those reachable only in certain roles or states. Identify the technology stack from headers, cookie names, error pages and file extensions. Find the entry points — every place user input enters, including headers, cookies and hidden fields, which are the ones developers forget are user-controlled. Look for what was not meant to be published: administrative interfaces, test and staging instances, backup files, source repositories, API documentation, and comme...

HTTP status codes in the 400 range mean the client request was the problem. That distinction from the 500 range — where the server failed — is the first thing to establish when troubleshooting, because it tells you which side to investigate. The ones to know 400 Bad Request. The server could not parse the request at all — malformed syntax, an invalid header, a body that does not match its declared type. Often produced by a proxy or gateway before the application ever sees it. 401 Unauthorized. Authentication is required and has not been provided or has failed. Despite the name, this is about authentication , not authorization. A compliant 401 response includes a WWW-Authenticate header telling the client how to authenticate. 403 Forbidden. The server understood the request and refuses it. Authentication may have succeeded perfectly — the identity simply is not permitted. This is authorization . The 401 versus 403 distinction is the most reliably tested ...

An intercepting proxy sits between the browser and the application, showing every request and response and letting you modify them before they continue. It is the foundational tool for manual web testing, and what makes it essential is not automation — it is that it removes the browser's cooperation from the equation. How it works The browser is configured to send traffic through the proxy, and the proxy's certificate authority is trusted so HTTPS can be decrypted — the same mechanism as any forward interception deployment, described under TLS proxies . From there the proxy records everything. A history of requests and responses, the ability to pause a request and edit it, and the ability to replay a captured request with modifications as many times as you like. That last capability is the important one. A scanner sends what it was programmed to send; a proxy lets you send whatever you can think of, against a request the application has already accepted once. Client-s...

A content delivery network puts copies of your content on servers close to your users, so a request travels tens of miles instead of thousands. That is the whole idea. Everything else — the security features, the routing tricks — follows from having a distributed layer in front of the origin. Why Distance Matters More Than Bandwidth Light in fibre covers roughly 200 kilometres per millisecond, and real paths are never direct. A round trip from Sydney to a server in Virginia costs around 200 milliseconds before the server does anything at all. Worse, that cost is paid repeatedly. A TLS handshake takes multiple round trips, and TCP slow start means a connection does not reach full speed immediately. Adding bandwidth does not help; the delay is geometric, not volumetric. Moving the content closer is the only fix. How a Request Finds the Nearest Edge Two mechanisms, and exams ask about both. DNS-based routing. The CDN's authoritative nameserver returns a different a...

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

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

Crawling a website finds what it links to. Content discovery — also called forced browsing or directory brute forcing — finds what it does not: administrative paths, old versions, backup files, staging endpoints, and APIs that exist but appear in no menu. These are frequently the most interesting parts of an application precisely because nobody expected anyone to look. How it works The tool requests a long list of candidate paths and records which ones return something other than "not found." That is the entire technique. Its effectiveness comes almost entirely from three choices. The wordlist. A generic list of common directory names finds common things. A list built from the target — words scraped from the site, the organization's terminology, developer and project names, framework-specific paths once the stack is identified — finds the things specific to that application. This is where skill shows. Extensions. Requesting each word with a set of suffixes...

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

APIs fail differently from web interfaces, and the reason is structural: a web page decides what to show you, while an API answers what you ask for. Remove the interface that was shaping the requests and a whole category of assumptions stops holding. Broken object level authorization The most common and most damaging API flaw. An endpoint accepts an object identifier and returns that object without checking whether the caller is entitled to it. The web interface only ever sent the user's own identifier, so nobody wrote the check. Testing it is mechanical: capture a request for your own resource, change the identifier, and see what comes back. Sequential numeric identifiers make enumeration trivial; random identifiers make it harder and are not a fix, because obscurity is not authorization. The related failure is broken function level authorization — an administrative endpoint that checks authentication but not role, reachable because the button was merely hidden in the inter...

Run a baseline web server scan against almost any deployment and the same categories come back. None of them are sophisticated, all of them are configuration rather than code, and together they account for a large share of the easy wins in a web application assessment. Knowing the list is worth more than knowing any particular tool. Default and leftover content Installation leaves things behind: default index pages that confirm the server software and version, sample applications and scripts, documentation directories, test pages, and administrative interfaces reachable at predictable paths. Deployment adds more — backup files created while editing a configuration, files with editor suffixes, archives left in the web root, and version control directories published along with the application. A .git directory served over HTTP hands an attacker the entire source history, and it appears in real assessments regularly. The fix is a deployment process that publishes only intended ...

Content management systems run an enormous share of the web, and they are compromised at a rate out of proportion to their share. The reason is not that the core software is unusually weak — it is the ecosystem around it, and the fact that most installations are administered by someone whose job is not administration. Plugins and themes, not core Core CMS software is widely scrutinised, patched quickly, and in most cases updates itself. Serious core vulnerabilities are rare. Plugins and themes are the opposite. A typical site runs a dozen or more, written by different authors of varying skill, many maintained by one unpaid person, and a substantial share abandoned entirely. They run with full application privileges and frequently full database access, so a vulnerability in the smallest of them is a vulnerability in the site. The recurring failure modes are ordinary: missing authorization checks on administrative endpoints, unvalidated input reaching the database, unrestricted...

A webhook is an HTTP callback: instead of your application repeatedly asking a service whether anything happened, the service posts to a URL you provide when something does. It replaces polling, it is the backbone of most SaaS integration, and it is an unauthenticated public endpoint accepting data that drives your business logic — which is why the security details matter. Polling versus push Polling wastes requests and adds latency: check every minute and you make 1,440 requests a day to learn about three events, each up to a minute late. Webhooks invert this. The event arrives immediately and no request is wasted, at the cost of running a reachable endpoint and handling delivery reliability yourself — a webhook you were not listening for is simply missed unless the sender retries. The receiver's problem Your endpoint is on the public internet and anyone can post to it. Nothing about a request proves it came from the service it claims. Signature verification is th...

A watering hole attack compromises a website the intended targets already visit, rather than approaching them directly. The victims browse normally to a site they trust, and the site delivers the attack. It is patient, indirect, and it defeats the controls organizations invest in most. Why an attacker chooses it Phishing requires the target to act on an unsolicited message, and organizations have spent years training people not to and filtering what arrives. A watering hole requires nothing unusual from the victim at all — they do their job. It also reaches people who are hard to phish. Someone cautious about links and attachments still visits their industry association's site, their regulator's guidance pages, or the supplier portal they use daily. And it self-selects. Compromising a niche site — a professional body, a sector news publication, a specialist software vendor — reaches exactly the population the attacker wants, without touching anyone else. That narr...

Almost every web application sits behind something — a load balancer, a CDN edge, a reverse proxy . That front-end server parses incoming requests and forwards them to a back-end over a reused connection. Request smuggling exploits a disagreement between those two about where one request ends and the next begins. Get them out of step and part of the attacker's request is treated by the back-end as the beginning of somebody else's. Two Ways to State a Body Length HTTP/1.1 offers two mechanisms, and the ambiguity lives in having both. Content-Length states the body size in bytes. Transfer-Encoding: chunked sends the body in chunks, each prefixed by its size in hexadecimal, terminated by a zero-length chunk. The specification says that if both headers are present, Transfer-Encoding wins and Content-Length must be ignored. In practice implementations disagree — some prefer Content-Length, some mishandle malformed Transfer-Encoding values, some accept header variation...