Web Application Security — DedSec Project

Web application security is the study of how user-controlled requests move through browsers, proxies, application code, identity systems, databases, queues, and external services. The most important question is not “which payload works?” but “which security invariant can fail, at what trust boundary, and how can we prove and fix it safely?”

Authorized-use boundary: Test only applications and accounts in scope. Prefer intentionally vulnerable training applications or your own local code. Avoid destructive payloads, mass data extraction, real credential capture, or uncontrolled automated scanning.

Learning objectives

• understand input handling, output encoding, authentication, authorization, session management, and business logic;
• reason about injection, XSS, CSRF, SSRF, path handling, and insecure deserialization at a defensive level;
• test access control with synthetic accounts;
• understand browser-origin and cookie boundaries;
• write minimal proofs and remediation tests;
• use OWASP resources as structured guidance rather than a checklist substitute.

Input is not the same as authority

Applications receive path parameters, query strings, headers, cookies, JSON/XML bodies, uploaded files, messages, and data retrieved from other services. Validation should enforce the expected schema and business rules, but authorization must still be evaluated separately.

Injection

Injection occurs when untrusted data is interpreted as part of a command or query language rather than as data. Common defenses include parameterized queries, safe APIs, context-aware escaping where appropriate, avoiding shell construction, and least privilege for the downstream interpreter.

In labs, prove injection with harmless values and minimal output. Do not use a database flaw to extract unrelated records.

Cross-site scripting

XSS occurs when attacker-controlled data becomes executable script in another user's browser context. Defenses include correct output encoding for the destination context, safe templating, avoiding dangerous DOM sinks, sanitizing user-authored HTML with a maintained library, and Content Security Policy as defense in depth.

Authorization

Broken object-level or function-level authorization occurs when the server trusts an identifier or client-side UI decision without checking whether the current identity may access the specific resource/action.

A safe authorization test uses two synthetic accounts and a small set of test objects. Record expected versus observed access without reading real users' data.

CSRF

CSRF exploits automatically attached browser credentials to trigger unwanted state changes. Use SameSite cookies, anti-CSRF tokens, origin checks where appropriate, and sound request semantics. State-changing actions should not be implemented as ordinary GET requests.

SSRF

Server-side request forgery occurs when an application fetches a destination influenced by untrusted input and the server has more network authority than the user. Defenses include allowlists where practical, strict URL parsing, network egress controls, blocking sensitive address ranges, and separating fetch services from high-privilege networks.

Use localhost toy services for SSRF labs; do not query cloud metadata or third-party internal services.

File handling

Uploads and path operations need content/size limits, safe storage names, separation from executable web roots, malware/content scanning where appropriate, and authorization for download/delete actions. Path traversal risk appears when untrusted path fragments are joined without safe normalization and base-directory enforcement.

Security headers and browser controls

CSP, HSTS, frame-embedding policy, MIME controls, cookie attributes, and CORS can reduce risk, but each solves a specific problem. CORS is not an authorization mechanism, and CSP does not fix server-side access control.

Business logic

Some vulnerabilities are valid operations performed in an unsafe sequence or quantity: duplicate redemption, negative quantity, race conditions, workflow-step skipping, or inconsistent state across services. Model state transitions and invariants rather than looking only for malformed input.

Safe testing workflow

1. Create synthetic users/objects.
2. Record expected policy.
3. Capture a normal request.
4. Change one variable.
5. Observe response and server-side evidence.
6. Stop when the invariant is proven or disproven.
7. Apply a fix and turn the test into a regression case.

Common mistakes

• Running large automated scans before understanding the application.
• Treating CORS as access control.
• Testing authorization with real customer data.
• Reporting reflected input as XSS without proving executable context.
• Using intrusive SQL injection techniques when a harmless boolean proof is enough.
• Ignoring business logic and state transitions.

Safe lab

Use an intentionally vulnerable local application with two synthetic users. Build a small authorization matrix, test one reflected-input path using inert markers, inspect cookie attributes, and identify one state-changing request that should have CSRF protection. Do not collect or alter unrelated data.

Knowledge check

1. Why are validation and authorization separate controls?
2. What makes parameterized queries effective against SQL injection?
3. Why is CORS not an authorization mechanism?
4. How can SSRF increase authority beyond the user?
5. What makes a business-logic flaw different from a parser bug?

Guided study workflow

Use the shared Study Method. For deeper browser and parser behavior continue with Modules 52, 69, 70, 71, and 127.

Continue with

Recommended next modules: 22, 39, 40, 41, 52.