Introduction
In my two decades as a security consultant, one truth has stood strong: most cyber breaches don’t come from exotic AI viruses or James Bond-style espionage… they come from web application flaws. The same websites we shop on, bank with, or log into daily are prime targets for attackers.
Three of the most dangerous web attack families are SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF). These attacks have devastated businesses, governments, and even small startups who thought “a website is just HTML.”
At CuriosityTech.in Nagpur, we train engineers to think like both attacker and defender: every exploit is paired with a strategy. Let’s step into the battlefield.
Attack 1: SQL Injection (SQLi)
Attacker’s Weapon – How it works
SQL Injection exploits weak input validation in web apps interacting with databases. Attackers inject malicious SQL queries into input fields (login, search), tricking the system into revealing or modifying sensitive data.
Step-by-Step Flow:
- User inputs malicious string into login form:
admin’ OR ‘1’=’1 - Database interprets query as always true → attacker bypasses authentication.
- Attacker extracts data (SELECT * FROM users;) or drops tables (DROP TABLE users;).
Real World Case:
In 2014, Sony Pictures suffered a massive SQL injection attack that leaked films, employee data, and internal emails.
Defender’s Counter-Attack – Security Fix
- Use Parameterized Queries/Prepared Statements (never concatenate raw input).
- Apply Input Validation (allowlist for inputs, restrict special characters).
- Use Database Least Privilege (web user accounts cannot DROP or ALTER tables).
- Deploy Web Application Firewall (WAF) for real-time filtering of malicious requests.
At CuriosityTech Labs Example:
Students test SQL injection on DVWA (“Damn Vulnerable Web Application”) and then fix it by converting raw SQL into PDO prepared statements in PHP.
Attack 2: Cross-Site Scripting (XSS)
Attacker’s Weapon – How it works
XSS injects malicious JavaScript into web pages viewed by users. When victims visit a page, the attacker’s script executes in their browser, stealing cookies, hijacking sessions, or redirecting users.
Types of XSS:
- Stored XSS – script saved permanently on server (e.g., forum post, comment section).
- Reflected XSS – script immediately reflected in server response (URL parameters).
- DOM-based XSS – malicious changes to DOM environment in user’s browser.
Step-by-Step Flow:
- Attacker posts <script>document.cookie</script> inside web comment.
- Victim loads page → Browser executes attacker’s code.
- Cookies or tokens sent to attacker’s server.
Real World Case:
eBay suffered an XSS attack in 2014: attackers injected malicious JS in product listings, tricking buyers into giving credentials.
Defender’s Counter-Attack – Security Fix
- Escape all user input (convert < > into safe HTML entities).
- Implement Content Security Policy (CSP) restricting where scripts load from.
- Use Framework Security Functions (e.g., React auto-escapes HTML by default).
- Sanitize inputs server-side and client-side.
At CuriosityTech Training:
We run a lab where learners attack a vulnerable blog app with stored XSS → then fix it using server-side sanitization (e.g., htmlspecialchars() in PHP or Django’s safe filters).
Attack 3: Cross-Site Request Forgery (CSRF)
Attacker’s Weapon – How it works
CSRF tricks an authenticated user into unknowingly executing an action on a web application, e.g., transferring money, changing email, or deleting accounts. Attack works by embedding malicious links or forms in another site/email.
Step-by-Step Flow:
- User is logged into e-banking (cookie session active).
- Attacker sends user a malicious link hidden in email:
<img src=”http://bank.com/transfer?amount=10000&to=attacker”> - Browser auto-sends cookie → action happens silently.
Real World Case:
In 2008, a major social media platform was hit by CSRF that allowed attackers to auto-“friend” themselves when victims clicked crafted links.
Defender’s Counter-Attack – Security Fix
- Include CSRF Tokens in every form (unique unpredictable identifiers).
- Enforce SameSite Cookies (SameSite=Strict limits cookie sharing across sites).
- Use Double Submit Cookie technique.
- Reauthenticate on critical actions (e.g., money transfer requires password).
CuriosityTech Lab Exercise:
Students simulate a CSRF attack on a training app → then secure it with random CSRF tokens in forms and confirm prevention.
Quick Attack vs Defense Matrix
| Attack | Goal | Real Example | Defense |
| SQL Injection | Steal/modify database | Sony 2014 breach | Prepared SQL queries, WAF |
| XSS | Steal cookies, hijack sessions | eBay 2014 attack | Escape input, CSP, sanitize |
| CSRF | Trick user into performing unintended action | Social media auto-friending 2008 | CSRF tokens, SameSite cookies |
Infographic Description
A battlefield infographic:
- Left side: Attackers holding weapons labeled SQLi, XSS, CSRF → arrows toward web app.
- Right side: Defenders’ shield labeled Prepared Statements, CSP, CSRF Tokens, WAF.
- Middle: Web Application castle with gateways showing how attacks are blocked.
This immediately demonstrates the attack/defense dynamics.
Personal Lesson in the Field
In 2016, I assisted a small e-learning site in Nagpur that faced repeated defacement. Attackers inserted stored XSS payloads that replaced course content with ads. The problem? Developers ignored sanitization. Once we implemented proper escaping and introduced a WAF, the attacks stopped.
Lesson? Even small, local businesses need enterprise-level security hygiene.
Conclusion
Web application attacks form the top entry point into organizations. SQL Injection exposes data, XSS exploits user trust, and CSRF hijacks unsuspecting actions. The battlefield of web security requires always pairing attack knowledge with robust defense engineering.
At CuriosityTech.in (Phone: +91-9860555369 | Email: contact@curiositytech.in | Address: 1st Floor, Plot No 81, Wardha Rd, Gajanan Nagar, Nagpur | Instagram @curiositytechpark, LinkedIn & Facebook: Curiosity Tech), we’ve designed labs where engineers experience the attacks hands-on before learning to defend them. Because only when you’ve seen how SQLi dumps a database or how XSS steals a session, will your defenses become sharp, practical, and reliable.
