Remediation and Hardening

Step 1: Prioritize the Findings

You have multiple confirmed findings from Unit 3. Before fixing anything, decide the order.

Direct Claude to rank the findings by risk:

Review all confirmed findings from the assessment. Rank them by risk to Ruta's customers and business -- not by the order we discovered them. Consider: which vulnerabilities affect the most people? Which give the deepest access? Which are easiest for an attacker to exploit?

AI fixes findings in discovery order unless you impose priority. The tool reports SQL injection first because sqlmap ran first, not because SQL injection is the highest risk. The stored XSS that fires for every visitor to a product page is a higher priority than information disclosure in error messages. The priority ordering from the TTP selection document provides guidance, but the specific ordering for Ruta's situation depends on what you found.

This is a professional judgment call. A generic severity label does not account for Ruta's context -- a shop with customer accounts in 15 countries, approaching the Christmas rush, with a nephew who has not updated plugins in six months.

Step 2: Fix the Highest-Priority Finding

Start with the finding you ranked first. Direct Claude to implement the fix:

Fix the highest-priority finding first. Implement the remediation in the application code. Then re-run the specific exploit from Unit 3 to verify the fix works -- the same payload, the same endpoint.

Different vulnerability types require fundamentally different remediation approaches. XSS remediation means output encoding -- converting special characters like < and > to their HTML entities so the browser renders them as text, not executable code. Command injection remediation means input validation and avoiding shell execution entirely. Credential weakness remediation means enforcing strong passwords and implementing account lockout. AI may apply a pattern from one type to another -- encoding where it should be validating, or sanitizing where it should be restructuring.

Check what Claude produces. The fix should match the vulnerability type, not be a generic "sanitize input" applied everywhere.

Step 3: Fix the Next Finding and Check Composition

Fix the second-priority finding. Verify it the same way. Then check something new: does the first fix still work?

Fix the next finding in priority order. Verify it by replaying its exploit. Then go back and verify the first fix is still working -- re-run its exploit too.

Fixing multiple vulnerabilities is not repeating the single-fix process. Fixes can interact. A CSRF token implementation might conflict with the output encoding applied for XSS. A change to how the application processes POST data might break a command injection fix. AI fixes each vulnerability independently without checking composition -- it does not consider whether the new fix affects previous ones.

After two fixes are in place, the whole is different from the sum of the parts.

Step 4: Complete All Remediation

Continue through the remaining findings in priority order. Each fix follows the same cycle: implement, verify individually, then spot-check that previous fixes still hold.

Continue fixing the remaining findings in priority order. For each one: implement the fix, re-run its specific exploit, and check that at least one earlier fix still works. Document what you changed for each finding.

Per-fix verification confirms each individual change works. But per-fix verification does not mean whole-system verification. A new issue may have been introduced by one of the fixes -- a page that no longer loads, a form that rejects valid input, a function that broke because its input handling changed. The whole-system check comes after all fixes are in place.

Step 5: Apply Security Headers

Hardening goes beyond fixing the specific findings. Security headers prevent entire classes of attack, not just the specific exploits you tested.

Direct Claude to add security headers:

Add security headers to the application's HTTP responses: X-Content-Type-Options set to nosniff, X-Frame-Options set to DENY, and Content-Security-Policy with a restrictive default. Explain what each header prevents.

Each header blocks a specific attack class. X-Content-Type-Options: nosniff prevents the browser from guessing a file's type, which stops attacks that serve malicious code disguised as an image. X-Frame-Options: DENY prevents the page from being embedded in a frame on another site, blocking clickjacking. Understanding what each header does matters -- applying them all as a bundle without understanding produces a configuration you cannot troubleshoot when something breaks.

Now verify the headers are actually present in the response:

curl -I http://localhost:8080

Hardening verification requires testing the actual response, not reading the configuration file. A header set in the config but overridden by the framework, or applied in the wrong location, produces a false sense of security. The curl output is ground truth.

Step 6: Remove Information Disclosure

In Unit 2, you used version information from HTTP headers and Nmap scans to understand the application stack. An attacker would use that same information to select exploits. Remove it.

Remove information disclosure from the application: suppress the Server version header, disable detailed error pages, and turn off directory listings. Then verify with curl and Nmap that the information is no longer exposed.

The student who used Apache version strings to understand the target now understands why that information should be hidden. The attacker's reconnaissance becomes harder when the server stops announcing exactly what software it runs.

If you run a ZAP passive scan against the application, it will report on missing headers and information disclosure. A ZAP finding that says "missing X-Content-Type-Options header" is informational -- it tells you a header is absent but does not confirm the application is vulnerable to the specific attack that header prevents. Severity depends on whether the application serves content that could be exploited without that header.

Step 7: Whole-System Verification

Everything is fixed and hardened. Now verify the entire system as a unit, not just the individual fixes.

Re-run all the exploitation attempts from Unit 3 against the fully remediated and hardened application. Every exploit that succeeded before should now fail. Also check that the application still functions correctly -- product pages load, search works, the admin login accepts the new credentials.

This final check is different from the per-fix verification. You are checking the whole system after all changes, looking for regressions, broken functionality, or new issues introduced by the fixes. A system where every individual fix works but the application no longer loads is not a successful remediation.