9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection

Why web applications are prime targets

Web applications are the public doors of most organizations. They accept input from untrusted networks, they sit in front of databases that hold accounts and personal data, and they combine browser-side code with server-side logic that changes weekly. For a security analyst, that combination matters more than any single vulnerability identifier: a successful web attack can steal sessions, dump tables, or rewrite pages that thousands of customers load, often without dropping a malware file on a laptop.

This independent OpenExamPrep chapter covers TryHackMe Security Analyst Level 1 (SAL1) topics Web Exploitation and Endpoint Attacks from a defender's point of view: recognition, impact, and detection. It does not teach how to exploit systems, and it does not describe OpenExamPrep resources as approved by or equivalent to the exam sponsor.

Prime-target reasons you will see in ticket notes:

• Reachability. Internet-facing Hypertext Transfer Protocol (HTTP) and HTTP Secure (HTTPS) services are scanned continuously. An analyst's first question on a web alert is whether the Uniform Resource Locator (URL) is meant to be public.
• Trust in input. Search boxes, login forms, file-name parameters, and JavaScript Object Notation (JSON) APIs all carry attacker-controlled strings. If the application treats those strings as code or as query language, impact follows.
• High-value data. Authentication cookies, password hashes, exports, and API tokens live one hop behind the web tier.
• Mixed execution. Harm can run in the victim's browser (client-side) or on the application host and database (server-side). Those two classes leave different artefacts.

Client-side versus server-side vulnerabilities

Client-side vulnerabilities execute in a user's browser. The application server may return a page, but the harmful behavior runs where the human is. Typical analyst-visible effects include stolen session cookies reused from a new network, unexpected outbound fetches to an unapproved host, and defacement (page content that no longer matches the site baseline).

Server-side vulnerabilities execute on the application process or the database engine. Typical analyst-visible effects include abnormal Structured Query Language (SQL) activity, bulk data returned from an endpoint that normally returns a small object, authentication succeeding when it should fail, and the web worker spawning unexpected child processes (covered in the next section as code injection).

A useful triage split: if the database looks healthy and other users are the ones harmed, think client-side. If the data store or the authentication decision is wrong, think server-side. Cross-Site Scripting (XSS) is the flagship client-side family in these SAL1 web topics; SQL injection (SQLi) is the flagship server-side family.

XSS types as effects, not payloads

Analysts classify XSS by how the dangerous content is delivered and who is hit. You do not need a proof of concept. You need to recognize stolen cookies, unexpected script hosts, and defacement.

Reflected XSS echoes attacker-controlled input in an immediate response, often from a query string on a search or error page. One user clicks a crafted link. Recognition: a single victim, a suspicious parameter on a reflective endpoint, then rapid session reuse from a different source IP address or user-agent. Impact: that user's cookies or tokens are stolen; other customers may be unaffected.

Stored XSS persists in a comment, profile field, ticket body, or banner. Every visitor who loads the stored content can be affected until it is removed. Recognition: multiple users report pop-ups or a changed homepage; the same unexpected remote script host appears in HTML stored in the content management system; cookie-theft alerts cluster after one content-update event. Impact: mass session theft or lasting defacement.

Document Object Model (DOM)-based XSS happens when client-side script writes unsanitized data (for example a URL fragment after #) into the page. The origin server may never log the fragment. Recognition: proxy or endpoint telemetry shows the browser contacting an unapproved host after visiting a legitimate path, while Apache or nginx logs look ordinary. Trap: clean origin logs do not rule out XSS.

Worked, sanitized access and proxy snippets (no working payload):

# Origin access log — reflective endpoint, one client
2026-09-18T14:22:07Z src=198.51.100.17 GET /search q=[URL-encoded markup] proto=HTTP/1.1 status=200 bytes=1822

# Corporate proxy — same user fetches an unapproved host milliseconds later
2026-09-18T14:22:08Z src=198.51.100.17 GET https://cdn.example-bad.invalid/x.js status=200 category=uncategorized

# Identity provider — same session cookie from a new network
2026-09-18T14:22:19Z event=session_reuse cookie_hash=8f3a src=203.0.113.44 prev_src=198.51.100.17

Interpretation: the search page returned 200; the browser then loaded a script from an unapproved content-delivery host; the session identifier was presented from 203.0.113.44. That is cookie theft, not a password spray. Contain the session, capture stored HTML if this was a stored case, and ask whether a Web Application Firewall (WAF) even saw the first request.

Defacement as a stored-XSS or CMS-write artefact:

2026-09-18T09:01:11Z PUT /api/banners/home user=support_ticket_bot bytes=4412
2026-09-18T09:04:00Z GET / status=200 content_hash!=baseline title_contains=unexpected_string

Ticket 4412 in a typical SOC queue might read: marketing reports the homepage banner changed; identity reports fourteen session-reuse alerts in eight minutes. Start from impact (defacement plus stolen sessions), then decide reflected versus stored versus DOM by counting victims and by whether origin logs contain the suspicious parameter.

SQL injection artefacts in web and database logs

SQLi is a server-side flaw in which untrusted input is incorporated into a database statement. Analysts recognize effects, not recipes.

Data theft artefacts include unusually large 200 responses from export or search endpoints; database audit showing row counts far above the baseline for a login or lookup; and application accounts running statements that are not in the normal query allow-list. Some database audit products flag tautology patterns or comment tokens in the statement text. Treat those flags as indicators that the login path did not run the intended parameterized query. Do not treat them as instructions.

Authentication bypass artefacts include a login that issues a session despite a failed or skipped password check; a mismatch between the identity provider and the app's local auth table; and a 500 error on /login immediately followed by a 200 and an administrator cookie.

Worked, sanitized pair:

# Web
2026-09-18T16:40:02Z POST /login user=admin src=192.0.2.66 ua=generic-scanner status=200 latency_ms=4
2026-09-18T16:40:02Z GET /admin/export.csv status=200 bytes=940221 src=192.0.2.66

# Database audit (sanitized)
2026-09-18T16:40:02Z db=app runtime_user=web_runtime duration_ms=812 rows=18440
  note=login path produced a full users-table read; statement flagged tautology/comment tokens

Triage: revoke the session, preserve the export, compare WAF action (block versus allow), and do not treat user-agent strings as proof — they are spoofable. Correlate web and database timestamps to the same second. A four-millisecond login that then downloads nearly a megabyte of CSV is not a human typing a password.

Putting it together for triage

Do not wait for malware on an endpoint. Web compromise can be browser-only (XSS) or data-layer-only (SQLi). Do not close a ticket because origin logs lack a payload (DOM XSS). Do not assume a 403 from a WAF means the origin never saw a sibling request on another hostname. Always pair impact (stolen cookie, dumped rows, defaced banner) with the log class that can prove it. The next section adds code injection, path traversal, and the three defenses SAL1 training content names: input validation, patching, and WAF.