ECIH: Handling and Responding to Web Application Security Incidents

What you are looking for

Map alerts to the OWASP Top 10: broken access control, cryptographic failures, injection (SQL, NoSQL, OS command, LDAP), insecure design, security misconfiguration, vulnerable and outdated components, identification/authentication failures, software and data integrity failures (insecure deserialization, supply chain), logging and monitoring failures, and SSRF. Also know XSS (stored, reflected, DOM), CSRF, file inclusion (LFI/RFI), path traversal, and XML external entities.

Investigating from logs

Web server access logs (Apache/Nginx access.log, IIS logs), WAF logs, application logs, database audit logs, and authentication logs are the primary sources. Enumerate the tells: UNION SELECT, OR 1=1, '--, ../, %2e%2e%2f, <script>, onerror=, ;cat /etc/passwd, php://input, unusually long parameters, sequential ID enumeration, and spikes in 4xx/5xx from one source. Always URL-decode and double-decode before judging - attackers obfuscate with encoding, case variation and comment injection.

Traps that appear in questions

Source IP is not always the attacker. Requests may traverse a CDN, reverse proxy or NAT; X-Forwarded-For is client-controlled and spoofable. Corroborate with timing, session and user agent.
Not every UNION SELECT is an attack - vulnerability scanners and authorised penetration tests generate the same strings. Check authorisation, source ranges and timing windows before declaring an incident.
Success matters more than attempt. A 200 response carrying database output is far worse than a 403.

Response

Contain (WAF virtual patch or rule, block the source, take the vulnerable function offline, invalidate sessions and rotate secrets if credentials or tokens may be exposed) → preserve evidence (export logs and a memory/disk image of the app tier) → eradicate (patch the code, fix input validation, correct access-control logic) → recover and monitor → lessons learned (add detections, add testing to the SDLC).

Rule of thumb: if the database was reachable from the injected parameter, assume data exfiltration and treat it as a data breach, not merely a defacement.