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.

Credential theft via USB devices: how it works and how to protect yourself

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

The original version of this post was a step-by-step guide to building a USB "rootkit" that silently harvested stored passwords from any Windows computer it was plugged into. Those instructions have been removed. What remains — and what matters — is understanding the threat at a high level so you can defend against it. USB-based credential theft is a real, low-tech attack that still works today in offices, schools, and anywhere strangers have physical access to machines.

How the attack works, at a high level

The concept is simple and requires only brief physical access. An attacker prepares a USB drive with malicious software designed to run when the drive is inserted — historically via the Windows autorun mechanism, today more often through social-engineering tricks that get the victim to click something, or through devices that disguise themselves as keyboards. Once running, the software reads credentials that applications have saved on the machine: browser-stored passwords, saved logins in email and messaging clients, and other cached secrets. The results are written back to the drive, and the attacker walks away with them in seconds.

Two things make this attack potent. First, it needs no network access and leaves little obvious trace to the casual user. Second, many people store passwords in their browsers or stay logged in on shared and work computers, so there is usually something worth stealing.

What defenders and IT teams should watch for

• Removable-media telemetry: endpoint logs showing USB insertions, especially unknown devices on sensitive machines, followed by unexpected process launches from the removable drive.
• Antivirus/EDR detections flagging credential-access tools or suspicious executables running from USB paths.
• Physical indicators: unknown USB drives left in parking lots or desks — a classic social-engineering lure counting on curiosity.
• Policy violations: users plugging personal drives into locked-down workstations.

Protecting yourself and your organization

• Disable autorun/autoplay for removable media via Group Policy or device management — this closes the classic silent-execution path. (Modern Windows versions already restrict it, but verify the setting.)
• Use endpoint device-control policies to restrict or require approval for USB storage devices, especially on sensitive systems. Consider allowing only approved, encrypted drives.
• Don't let browsers save passwords on shared or work machines — and clear any that are already saved. Store credentials in a reputable, encrypted password manager protected by a strong master password and multi-factor authentication.
• Enable multi-factor authentication everywhere it matters. Even if a password is stolen, MFA stops the attacker from using it.
• Lock your screen whenever you step away, and treat physical access as a security boundary: don't leave machines unattended in public areas.
• Never plug in a USB drive you didn't expect — not found drives, not gifted ones, not drives handed to you by strangers.
• Keep EDR/antivirus active and updated, and never disable it at someone else's instruction.

If a suspicious USB was plugged in

Disconnect it, do not investigate it on a production machine, and report it to your IT or security team. Assume credentials on that machine may be compromised: change important passwords from a known-clean device, review account activity for unfamiliar logins, and let incident response determine the scope.

Authorization reminder

Security testing involving other people's systems or credentials must only be done with explicit authorization. Building or deploying credential-harvesting tools against systems you don't own is illegal in most jurisdictions — no exceptions for curiosity or "just testing."

How Metasploit-based attacks work — and how to protect your endpoints

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

The Metasploit Framework is a legitimate, widely used penetration-testing platform maintained by Rapid7. Security professionals use it — with authorization — to verify that defenses actually work. But the same framework is routinely repurposed by attackers, and understanding its attack chain at a high level is exactly what defenders need to build protections that hold up against it. This rewrite describes the attack only at the level of abstraction useful for defense: what the attacker is trying to achieve, what your telemetry should show, and how to stop it.

The anatomy of a Metasploit-based attack

A typical endpoint compromise follows a familiar chain. First, the attacker sets up infrastructure that serves exploit code — often a web page hosting browser or plugin exploits. Second, the victim is lured to that page, usually through phishing: a convincing email, message, or ad. Third, if the victim's browser or a plugin has an unpatched vulnerability, the exploit code runs and delivers a payload — a small program whose job is to connect back to the attacker and hand over control of the machine.

From the defender's perspective, the details of any single exploit module matter less than the pattern: unpatched software + social engineering + a callback to attacker infrastructure = compromise. Defenses that break any link in that chain defeat the attack regardless of which module is used.

What your telemetry should show

Modern endpoint and network monitoring can catch this attack chain at multiple stages. Look for:

• Phishing delivery: suspicious links or attachments in email, flagged by your email security gateway; users reporting unexpected messages.
• Exploitation: browser or application crashes followed by unusual child processes, process injection into legitimate applications, or memory-protection alerts from EDR.
• Callback (command and control): new outbound connections to unknown hosts on unusual ports, beaconing patterns (regular intervals), or DNS requests to recently registered domains.
• Post-exploitation: credential dumping attempts, lateral movement to other hosts, or disabled security tooling — all classic EDR alert categories.

The single most valuable investment here is a well-tuned EDR/XDR platform with alerts that someone actually reviews, backed by centralized logging so you can trace the chain end to end.

Hardening that defeats the attack chain

• Patch aggressively: operating systems, browsers, and plugins. Most Metasploit modules target known, patched vulnerabilities — timely patching removes the foothold entirely.
• Deploy EDR on every endpoint and keep it updated; pair it with application allowlisting on high-value systems.
• Practice least privilege: users should not run as local administrators day to day, which limits what a payload can do even if it lands.
• Filter email and web traffic: block malicious attachments and URLs before they reach users, and use DNS filtering to cut off callback infrastructure.
• Train users on phishing: the lures are the delivery mechanism; a workforce that reports suspicious messages shrinks the attack surface dramatically.
• Segment the network so a single compromised endpoint cannot reach everything else.

Testing your own defenses

If you want hands-on experience with these attack patterns, do it in an isolated lab: virtual machines you own, with no connection to production systems. Frameworks like Metasploit exist so defenders can validate that patching, EDR, and hardening actually stop real techniques — use them that way.

Authorization reminder

All security testing must only be performed on systems you own or are explicitly authorized to assess. Deploying exploit infrastructure or payloads against anyone else's systems without permission is illegal in most jurisdictions.

How "free laptop" giveaway scams work and how to spot them

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

The anatomy of a "free laptop" scam

"Get a free laptop with this one secret trick" is one of the oldest lures on the internet, and it still works. The formula is simple: the scammer promises something expensive for free, then uses your excitement to bypass your skepticism. Variants include fake giveaways, "secret loophole" warranty fraud schemes, referral pyramids where you must recruit others to "unlock" the prize, and survey-farming pages that harvest your personal data and never deliver anything.

Some schemes go further into outright fraud — for example, coaching victims to lie to a manufacturer to get replacement hardware shipped under warranty, sometimes using someone else's purchase information. That's not a loophole; it's fraud, and participating can mean civil liability or criminal charges.

What scammers are actually after

• Your personal information — names, addresses, phone numbers, and emails that get sold or used in identity theft.
• Your money — "shipping fees," "processing charges," or fake verification payments for a prize that doesn't exist.
• Your contacts — referral schemes turn you into the distributor, lending the scam your credibility with friends.
• Malware delivery — "download this app to claim your prize" often installs spyware or adware.

Red flags to watch for

• An offer that seems too good to be true — no legitimate company gives away high-end laptops through blog comments or random links.
• Pressure to act fast, recruit friends, or share the post before the "loophole closes."
• Requests for payment of any kind to receive a "free" item.
• Instructions to lie, impersonate, or misuse someone else's information — that's fraud, not a clever trick.
• Claims of a "secret" the company doesn't want you to know — classic social-engineering framing.
• URLs that don't match the real company's domain, or pages with no contact details, privacy policy, or verifiable terms.

How to protect yourself and others

• Verify giveaways through the company's official channels — real promotions appear on official websites and verified social accounts, not anonymous blog posts.
• Never pay to receive a prize. Legitimate giveaways don't charge "fees."
• Never provide someone else's personal information to support, warranty, or payment systems.
• Report the scam — report fraudulent pages to the hosting platform and, for fraud involving real companies, to that company's fraud/abuse team.
• Warn the people around you, especially less tech-savvy friends and family, who are the most common targets.

Authorization disclaimer

All security awareness content on this blog is for defensive education only. Participating in warranty fraud, impersonation, or other schemes to obtain goods under false pretenses is illegal — no "loophole" makes it legitimate.

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.

Google dorks for defenders: finding your exposed assets before attackers do

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

The original post taught "Google hacking" — using advanced search operators to find exposed cameras, confidential documents, and login pages, with examples tuned for snooping on strangers' infrastructure. The technique itself isn't criminal, but the direction matters. This rewrite points the same search power at the only legitimate target: your own organization's exposure.

What Google dorks are (and why defenders should know them)

Attackers routinely use operators like site:, filetype:, intitle:, and inurl: to locate misconfigured assets indexed by search engines: exposed admin panels, backup files, unprotected documents, even open webcams. If it's indexed, assume attackers have already searched for it. Defenders should run these same queries against their own domains to see what the internet sees.

A defensive dork audit for your own domain

Run these against domains you own or are authorized to assess, then fix whatever turns up:

• site:yourdomain.com filetype:pdf confidential — internal documents that leaked into the index.
• site:yourdomain.com intitle:"index of" — directory listings exposing file trees.
• site:yourdomain.com inurl:admin — admin and login interfaces visible to the public.
• site:yourdomain.com filetype:sql OR filetype:bak OR filetype:env — database dumps, backups, and config files that should never be web-accessible.
• site:yourdomain.com inurl:webcam OR intitle:"live view" — cameras or monitoring pages accidentally exposed.

What to do with what you find

• Remove or restrict it: take down exposed files, require authentication, and block directory listings.
• De-index it: use robots.txt, noindex meta tags, and Google's removal tools so the exposure doesn't persist in the cache.
• Check access logs to see whether anyone retrieved the exposed content before you closed it — that determines whether this is a cleanup or an incident.
• Automate the audit: schedule recurring external-attack-surface scans so new exposures get caught at deployment time, not months later.

Where the line is

Searching your own assets is good hygiene. Running the same operators against someone else's infrastructure to find exploitable openings is reconnaissance — and acting on it without authorization is illegal. The 2013 version of this post blurred that line with its examples; this one draws it clearly.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Use dorking to audit your own exposure; never use it to map or probe someone else's.

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.