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.

SQL injection defense, part 2: 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.

This is part 2 of our SQL injection defense series. The original version of this post published a list of third-party websites presented as targets for injection attacks — the kind of "target list" that serves no defensive purpose and puts real systems at risk. That list has been removed entirely and replaced with what actually protects applications: how to find injection flaws in systems you own, and how to fix them.

Never test systems you don't own

Scanning or probing a website for SQL injection without the owner's explicit permission is unauthorized access, and it is illegal in most jurisdictions — even if you never extract data and even if your motive is curiosity. There are no exceptions for "the site looked vulnerable" or "I was just testing." If you don't own it and don't have written authorization, don't touch it.

Learn and practice in legal labs

If you want to understand how injection works so you can defend against it, use environments built for that purpose. All of these are free, legal, and designed for learning:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP application with graded difficulty levels, ideal for learning how injection manifests and how fixes change the behavior.
• bWAPP — a buggy web app with hundreds of vulnerabilities, including many injection variants, widely used in training courses.
• WebGoat — OWASP's intentionally insecure application with structured lessons on injection and other flaws.

Run these locally or in an isolated virtual machine — Docker makes this straightforward — never on shared or public infrastructure. Practice recognizing vulnerable code patterns, confirming flaws in the lab, and verifying that your fixes actually close them.

Finding injection flaws in your own applications

For systems you own or are authorized to assess, combine several approaches:

• Code review: search for SQL queries built by concatenating strings with user input. This is the root cause in the vast majority of cases. Review data-access layers, reporting endpoints, and legacy code first.
• Static analysis (SAST): run automated scanners in your CI pipeline to flag unsafe query construction before code ships.
• Dynamic testing (DAST) and authorized penetration tests: exercise the running application the way an attacker would, within the scope of your authorization.
• Bug bounty programs: if you run a public-facing application, a scoped bounty program lets vetted researchers report flaws to you instead of exploiting them.

Remediation that actually works

• Parameterized queries / prepared statements are the gold standard. User input becomes data, never executable SQL.
• Use a modern ORM or query builder with safe defaults, and avoid raw query methods unless you parameterize them.
• Least privilege: application database accounts should have the minimum permissions required. A reporting user does not need write access.
• Server-side input validation as defense in depth — never as the sole control.
• Generic error handling: never expose database errors to users; log them internally where your team can investigate.
• WAF and monitoring as compensating controls while code fixes are rolled out.

After fixing, re-test to confirm the flaw is closed, and add regression tests so it doesn't return in a future release.

If you find a flaw in someone else's system

Report it through the organization's responsible-disclosure or security contact channel. Do not demonstrate the impact, do not extract data, and do not publish details before the owner has had a reasonable chance to fix it.

Authorization reminder

All security testing must only be performed on systems you own or are explicitly authorized to assess. The labs listed above exist precisely so you can build these skills without ever touching a system that isn't yours.

How automated SQL injection tools work — and how to detect and block them

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

Automated SQL injection tools are among the most common weapons attackers point at web applications. Utilities such as Havij were originally marketed to penetration testers, but in the wild they are frequently used against live sites: they probe a URL parameter, fingerprint the back-end database, enumerate tables and columns, and extract data — all with almost no manual effort from the attacker. Understanding what these tools do at a high level is essential for anyone defending a web application, because the same knowledge tells you what to look for in your logs and how to shut the attack down.

How attackers use automated injection tools

At a high level, the attacker's workflow looks like this. First, they look for pages that appear to pass values into a database — classic signs are URLs carrying parameters such as ?id=. Then they test whether the application mishandles a single quote character, which produces a database error and confirms the parameter is interpreted as part of a SQL query. Once confirmed, the tool automates the tedious work: identifying the database type, listing databases and tables, and pulling data row by row.

The point is not the tool itself. A determined attacker can do all of this by hand. The takeaway for defenders is that SQL injection is a vulnerability class, not a tool problem — if your application builds SQL queries by concatenating user input, it is exploitable regardless of which utility the attacker happens to prefer.

What the attack looks like in your telemetry

Automated injection attempts are noisy, which is good news for detection. Watch for:

• Database error noise: repeated 500 errors or SQL error messages following requests containing quote characters, SQL keywords, or comment sequences.
• Enumeration patterns: bursts of requests to the same endpoint with systematically varying parameters — the signature of automated table and column dumping.
• Anomalous timing and volume: a single parameter being hit hundreds of times in minutes, or queries that take far longer than normal because the attacker is extracting data character by character.
• WAF and IDS alerts: rule hits for UNION SELECT, information-schema access, or stacked queries, especially clustered around one IP or session.

Correlate web access logs with database and application logs. A spike in slow queries against a single endpoint, paired with 5xx responses, is a strong indicator of an active injection campaign.

Fixing the root cause

Detection helps, but the durable fix is in the code:

• Use parameterized queries (prepared statements) everywhere user input reaches the database. This is the single most effective control and it eliminates the vulnerability class.
• Apply least privilege to database accounts: the application's DB user should only have the permissions it needs — no file-system access, no command execution, no schema modifications if it only reads data.
• Validate input on the server side as defense in depth, and fail safely: return generic error pages instead of raw database errors, which hand attackers free reconnaissance.
• Keep everything patched — application frameworks, database engines, and libraries.

Defense in depth

Deploy a web application firewall (WAF) with rules tuned for injection, but treat it as a safety net, not a fix. Regularly scan your own applications with SAST and DAST tools, and include injection testing in every release cycle. If you discover that a database may have been accessed, treat it as a data-breach scenario: rotate credentials, review audit logs for what was extracted, and follow your incident-response plan.

Authorization reminder

All security testing — including scanning for injection flaws — must only be performed on systems you own or are explicitly authorized to assess. Probing third-party websites for vulnerabilities without permission is illegal in most jurisdictions, regardless of intent.

SQL injection: how attackers exploit it, and how to test your own apps safely

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

The original post was a list of third-party websites the author claimed were vulnerable to SQL injection, presented as targets. That list is gone — deliberately. Publishing sites as attack targets is harmful, not educational. This rewrite covers the same vulnerability from the only side that matters now: how to find it in your own applications, how to fix it, and how to learn it safely.

How attackers exploit SQL injection (defender's view)

Attackers look for places where your application passes user input into a database query unsanitized. They probe by changing how the application responds — error messages, different result counts, timing differences. Once they confirm a flaw, they use it to read, alter, or delete data, or to pivot deeper into the network. From your side, the fingerprints are: odd characters in request logs, database errors echoed to clients, and queries requesting far more data than the page should display.

Test your own apps — legally

Never test this against someone else's site. Use purpose-built vulnerable applications that exist exactly for this:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP/MySQL app you run locally, with adjustable difficulty levels.
• bWAPP (buggy Web Application) — hundreds of vulnerable scenarios, including multiple SQL injection flavors, in one local package.
• WebGoat — OWASP's interactive lessons on web flaws with guided fixes.

Run them in an isolated VM or Docker container, offline or on a closed network, and test only what you spun up yourself. Add SAST (static analysis) and DAST (dynamic scanning) tools to your own CI/CD pipeline for continuous, authorized coverage.

Finding SQL injection in your codebase

• Search for query strings built by concatenating variables — that's the pattern injection lives in.
• Review every place user input (URL parameters, form fields, headers, cookies) reaches the database.
• Check error handling: stack traces and DB errors shown to users hand attackers a roadmap.

Fixing it permanently

• Parameterized queries / prepared statements in every data-access layer — the root fix.
• Least-privilege database accounts: the web app's DB user should read/write only the tables it needs — never admin rights.
• Stored procedures and ORMs used correctly (with binding, not string interpolation) reduce exposure.
• A WAF and query monitoring as defense-in-depth: block known injection patterns and alert on anomalous query behavior — they don't replace fixing the code.
• Patch and review regularly so fixes don't regress in future releases.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Scanning or attacking real websites for SQL injection without written permission is illegal, even if your goal is "just to check."

How website attacks work — and how to defend your site

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

The original version of this post taught readers how to attack a website's database with a few crafted inputs. That technique — SQL injection — still works against vulnerable sites today, which is exactly why this rewrite exists: to help site owners recognize, detect, and eliminate the flaws attackers exploit, described only at the level of detail defenders need.

How the classic attacks look to a defender

1. SQL injection

Attackers probe input fields (logins, search boxes, URL parameters) to see whether their input gets executed as part of a database query. What your telemetry shows: requests containing quote characters, SQL keywords, or boolean conditions in fields that should hold names or numbers; unusual error messages returned to the browser; sudden changes in query result size.

2. Authentication abuse

Attackers hammer login and password-reset flows with credential stuffing and brute force. What your telemetry shows: bursts of failed logins from many IPs or a single rotating proxy, high session-creation rates, and successful logins from impossible geographies right after a failure wave.

3. Cross-site scripting (XSS)

Attackers try to get the site to render their content in other users' browsers — stealing sessions and spreading malware. What your telemetry shows: script tags or event handlers appearing in stored user content, comments, and form submissions; CSP violation reports spiking.

Fixes that actually close these holes

• Parameterized queries / prepared statements for all database access — never build queries by concatenating user input. This is the single fix that ends SQL injection.
• Output encoding plus a strict Content-Security-Policy to neutralize stored and reflected XSS.
• Input validation and least-privilege DB accounts so that even a successful injection can only touch what the app itself can touch.
• Rate limiting, account lockout policies, and MFA on every authentication path, including password reset.
• Keep frameworks, CMS, and plugins patched — known web-app CVEs are the cheapest attacker's foothold.

Detect, don't just prevent

• Log web requests centrally and alert on injection signatures and abnormal input patterns.
• Monitor database audit logs for queries touching unexpected tables or running at odd hours.
• Run periodic authorized scans (DAST/SAST) against your own site to catch regressions before attackers do.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Probing any other website's inputs for vulnerabilities without written permission is illegal, no matter how curious you are.