SQL injection defense, part 3: detection, logging, and ongoing protection

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The vulnerable-site target list this post once contained has been removed. This is the third installment of our SQL injection defense series — parts 1 and 2 covered finding and fixing injection flaws; this part covers what comes after the fix: detection, logging, and ongoing protection.

Why detection still matters after you've fixed the code

Parameterized queries eliminate SQL injection at the source — but no codebase stays fixed by accident. New code ships, dependencies change, legacy endpoints resurface, and regressions happen. A detection layer catches what secure coding misses and tells you when someone is actively probing your applications, which is intelligence worth having.

Log what matters

You can't detect what you don't record. Make sure these are captured and centralized:

• Full request details on database-backed endpoints: URL, parameters, user agent, source IP, and session identity.
• Database error events with the failing query context (logged server-side, never returned to the user): syntax errors, type-conversion failures, and permission denials.
• Query performance telemetry: execution time per query pattern. Time-based blind injection shows up as anomalous delays.
• Authentication and session events tied to the same requests, so you can correlate a probe with an account.
• WAF/edge block events — even blocked attempts are signal; a rising block rate against one endpoint means someone is working on it.

Build alerts that fire on real attacks

Turn the telemetry into detection rules in your SIEM:

• Error-rate anomalies: alert when database errors spike on an endpoint relative to its baseline — classic injection probing.
• Signature matches: flag requests containing SQL keywords, comment sequences, or stacked-query syntax in parameters that should never contain them. Tune to your application's normal input to control false positives.
• Behavioral anomalies: a single client cycling through many parameter values, unusually large result sets served to low-privilege sessions, or response-time patterns consistent with blind extraction.
• Known-bad correlation: match source IPs and request fingerprints against threat intelligence feeds of active scanners.

Ongoing protection: keep the fix fixed

• Test in legal labs continuously: DVWA, bWAPP, and WebGoat remain the right places to train your team and validate scanner coverage — never someone else's production site.
• Scan every release: integrate SAST and DAST into CI/CD so new injection flaws are caught before deployment, not after.
• Re-audit data access: periodically review database account privileges — least privilege drifts over time as features are added.
• Keep the WAF tuned: update rule sets, review what's being blocked, and investigate repeated blocks rather than ignoring them.
• Run tabletop exercises: walk through a "we're being probed" scenario so your team knows who triages the alert, who checks the code, and when to escalate to incident response.

Measure it

Track mean time to detect probing, the number of injection findings per release, and the percentage of database-backed endpoints covered by alerting. If those numbers improve quarter over quarter, your program is working.

Series wrap-up

Part 1 taught you to find injection flaws in your own applications using safe labs. Part 2 covered remediation — parameterized queries, least privilege, and layered controls. This part closes the loop: log the right things, alert on the right patterns, and keep testing so the flaw stays fixed. SQL injection is a solved problem technically; the remaining work is operational discipline.

How web shells end up on WordPress sites — and how to harden yours

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The original post gave step-by-step instructions for planting a malicious shell on a WordPress site — that walkthrough has been removed entirely. This rewrite explains how attackers get shells onto sites so you can detect and stop them.

What is a web shell, and why do attackers want one?

A web shell is a malicious script (often PHP on WordPress hosts) that an attacker places on a compromised server. Once in place, it gives them a remote interface to run commands, browse files, and pivot to other sites on the same server. For defenders, a web shell on your server means the attacker already had a way in — the shell is the foothold, not the break-in.

How shells get onto WordPress sites

Attackers rarely start with the shell. They start with an opening, then use it to drop one. The common paths:

• Vulnerable plugins and themes. Outdated or abandoned plugins with file-upload or code-execution flaws are the single most common entry point. Attackers scan the internet for known-vulnerable versions automatically.
• Weak or reused admin credentials. Brute-forced or phished wp-admin logins give attackers the same file-editing powers the old post abused (Appearance → Editor, plugin uploads). Enforce strong passwords and MFA.
• Unrestricted file uploads. Forms or plugin features that accept uploads without strict type validation let attackers place executable scripts where the web server will run them.
• Compromised hosting neighbors. On shared hosting, a shell planted on one site can sometimes reach others — another reason to isolate sites and choose reputable hosting.
• Nulled/cracked themes and plugins frequently ship with backdoors pre-installed. Never use them.

Detection: signs of a shell in your logs and files

Catch the foothold early. Watch for:

• New or modified PHP files in uploads directories, theme/plugin folders, or odd locations (e.g., files with random names, or recently modified core files). File integrity monitoring (FIM) turns this into an automatic alert.
• Suspicious request patterns: POST requests to unfamiliar .php files, requests with encoded/obfuscated parameters, or repeated hits to a single odd URL.
• Unexpected outbound connections from the web server process — shells often "phone home" or download second-stage payloads.
• Admin activity anomalies: logins from unusual locations, new admin users you didn't create, or theme/plugin editor usage outside change windows.
• Server-side clues: processes spawned by the web server user, spikes in CPU at odd hours, or antivirus/malware scanner hits on the document root.

Hardening: make your site a hard target

• Update relentlessly: WordPress core, themes, and plugins — promptly, and remove anything unused or abandoned.
• Least privilege: file permissions that prevent the web server from writing where it shouldn't; disable the theme/plugin file editor; run PHP with functions like exec and shell_exec disabled where possible.
• Lock down uploads: restrict allowed file types, store uploads outside the web root or deny script execution in upload directories via server configuration.
• Strong authentication: MFA on all admin accounts, limit login attempts, and restrict wp-admin/wp-login access by IP where feasible.
• WAF + monitoring: a web application firewall to block known exploit patterns, plus centralized logging and FIM so tampering triggers an alert, not a surprise.
• Backups you can restore: tested, offline backups are your fastest recovery path if a shell is found — assume the whole install is untrusted and rebuild clean.

If you find a shell

Don't just delete the file — treat it as an active incident: take the site offline or isolate it, preserve logs, identify the entry point (outdated plugin? weak credentials?), rebuild from a known-clean backup or fresh install, rotate all credentials and secrets, and close the hole before going back online.

The 3-step web attack pattern — and how to break it with defense in depth

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The original version of this post walked readers through attacking other people's websites — that content has been removed. What remains is something far more useful: understanding the pattern attackers follow so you can break it at every stage.

The attack pattern, from the defender's side

Most web compromises follow the same three phases. The 2013 version of this post inadvertently documented them from the attacker's chair. Let's flip the camera around.

Step 1: Reconnaissance — attackers map the internet

Before touching a target, attackers search at scale for exposed entry points: admin panels indexed by search engines, forgotten subdomains, and pages that reveal their technology stack. This "recon" phase is noisy by nature.

How to break it:

• Reduce your attack surface: remove or restrict indexing of admin interfaces, staging sites, and internal tools (robots.txt is a hint, not a control — use authentication and IP allow-listing).
• Monitor for reconnaissance in your logs: bursts of requests to predictable paths (login, admin, config, backup files) from a single source are a classic early indicator.
• Use external attack-surface monitoring to find what the internet sees — and close what shouldn't be public.

Step 2: Finding the entry point — attackers probe for weakness

Once a candidate page is found, attackers probe it: submitting malformed input, testing how the application handles unexpected characters, and watching error messages for clues about the underlying technology and database.

How to break it:

• Return generic error pages to users and log the details internally. Verbose stack traces and database errors are free intelligence for an attacker.
• Alert on probing behavior: repeated 4xx/5xx responses, parameter tampering, and error-rate spikes per endpoint are high-value SIEM signals.
• Harden authentication pages specifically: rate-limit login attempts, enforce MFA for admin accounts, and lock out or slow down brute-force patterns.

Step 3: Exploitation — attackers turn a flaw into access

The final step is converting a discovered weakness into access — for example, abusing an injection flaw in a login form to bypass authentication entirely. One unvalidated input, one missing control, and the attacker is inside.

How to break it:

• Fix the root cause: parameterized queries, server-side input validation, and secure session management eliminate entire classes of exploitation.
• Apply defense in depth so a single flaw isn't fatal: WAF rules, least-privilege service accounts, network segmentation, and egress filtering all raise the cost of exploitation.
• Assume breach: log authentication events centrally, alert on anomalous logins (new locations, odd hours, impossible travel), and have an incident response runbook ready before you need it.

The defender's advantage

Here's the asymmetry the original post missed: the attacker must succeed at all three steps; the defender only needs to break one of them. Reconnaissance defeated by a small attack surface, probing defeated by quiet errors and alerting, exploitation defeated by secure code and layered controls. Every step you harden compounds.

Stop thinking like the person following the three steps. Start thinking like the person who makes each step fail.

SQL injection defense: finding and fixing injection flaws in your own applications

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. Testing someone else's website without written permission is illegal in most jurisdictions — including the "vulnerable site lists" this post used to contain, which have been removed. If you find a vulnerability on someone else's site, do not exploit it; report it responsibly through the site's contact or bug bounty channel.

Why SQL injection still matters

SQL injection (SQLi) has topped vulnerability lists for over two decades, and it hasn't gone away. Attackers still probe the internet automatically for applications that concatenate user input into database queries. A single injection point can expose customer data, credentials, and entire databases. The good news: the fix is well understood, and it starts with finding the flaws in your own code before attackers find them.

Find injection flaws in your own applications — safely

Never test against live third-party sites. Instead, practice and validate your skills in legal lab environments built for exactly this purpose:

• DVWA (Damn Vulnerable Web Application) — deliberately vulnerable app with adjustable difficulty levels; ideal for learning what SQLi looks like and how defenses stop it.
• bWAPP — a buggy web app with dozens of vulnerabilities including many SQL injection variants.
• WebGoat — OWASP's interactive training app with guided SQL injection lessons and explanations.

Run these in a local VM or container, with the traffic isolated from production networks. For your own production applications, use automated scanners (DAST) and manual code review as part of your SDLC, and run authenticated assessments under a written rules of engagement.

What attacker probing looks like in your logs

Knowing what to look for is half the battle. Injection probes often leave recognizable traces:

• Requests containing SQL syntax fragments or error-triggering characters in parameters that should be plain numbers or names.
• Spikes of database error messages (syntax errors, type-conversion errors) correlated with a single client IP.
• Unusual query timing — blind injection techniques cause measurable delays, so watch for abnormal response-time patterns on database-backed endpoints.
• Exfiltration-style responses: large, unexpected result sets returned to unauthenticated or low-privilege sessions.

Feed these signals into your SIEM and alert on them — database error-rate anomalies per endpoint are one of the most reliable early warnings.

Fix and harden: the remediation playbook

• Parameterized queries (prepared statements) are the primary defense. Never build SQL by concatenating user input — pass values as parameters so the database treats them as data, not code.
• Least privilege for database accounts. Your application's DB user should not be able to drop tables or read unrelated schemas. If injection happens anyway, limited privileges contain the blast radius.
• Input validation and allow-listing as a complementary layer — validate types, lengths, and formats on the server side.
• Error handling: return generic errors to users; log the details server-side. Verbose database errors help attackers map your schema.
• WAF rules (Web Application Firewall) as defense in depth — block known injection patterns at the edge, but never treat the WAF as a substitute for fixing the code.
• Patch and scan continuously: keep frameworks and drivers updated, and re-scan after every release.

Bottom line

The vulnerable-site list this post once carried is gone, and good riddance. The defensive path is more valuable: learn injection in legal labs, instrument your logging to catch probes, and eliminate the flaw at the source with parameterized queries and least privilege. That's how you win against SQL injection — by making your own applications a dead end for it.