Hacking Web Applications

Web applications are programs that run inside a web browser — like your online banking portal, a social media feed, or an e-commerce store. They work by sending data from your browser (called the client) to a server, where the server processes the request and fetches or stores information in a database. The three main parts are the client (your browser), the server (the computer doing the thinking), and the database (the filing cabinet of data).

Attackers target the points where the client talks to the server, and where the server talks to the database. If the application trusts user input without verifying it, an attacker can trick it into doing things the developer never intended.

SQL Injection (SQLi) SQL stands for Structured Query Language — it’s the language used to talk to databases. A SQL injection happens when an attacker inserts malicious SQL commands into an input field (like a username box or search bar). If the application builds its database query by simply pasting the user’s input directly into the query string, the attacker can close the intended command and add their own. For example, a login form might check for a matching username and password with a query like: SELECT * FROM users WHERE username = 'admin' AND password = 'pass'. If an attacker types ' OR 1=1 -- into the password field, the query becomes: SELECT * FROM users WHERE username = 'admin' AND password = '' OR 1=1 —. The double-dash (--) comments out the rest, and 1=1 is always true, so the attacker gains access without a valid password.

Cross-Site Scripting (XSS) XSS is about injecting scripts (usually JavaScript) into a web page that other users will see. This happens when an application takes user input and displays it back without sanitising it. For instance, a comment box on a blog that lets you write '<script>alert('xss')</script>' — if the site shows your comment raw, every visitor’s browser will run that script. There are three types: stored XSS (the script is saved permanently on the server, like in a comment), reflected XSS (the script is reflected back in the immediate response, like a search result page), and DOM-based XSS (the vulnerability exists in the client-side JavaScript code itself). Attackers use XSS to steal cookies (which hold session IDs), redirect users to fake login pages, or deface websites.

Cross-Site Request Forgery (CSRF, pronounced ‘sea-surf’) CSRF tricks an authenticated user into performing actions they didn’t intend. Imagine you’re logged into your bank website. An attacker sends you a link (maybe in a forum or email) to a page with a hidden image tag that makes a request to your bank’s transfer money API. Because your browser holds a valid session cookie for the bank, the bank believes the request came from you. The result: money transferred to the attacker’s account without your knowledge. CSRF attacks exploit the fact that web applications often rely solely on cookies to authenticate requests, and the browser automatically attaches cookies to every request to that domain. The common defence is to include a unique, unpredictable token in each form (called a CSRF token) so the server can verify the request came from your browser, not a third-party page.

Authentication Flaws Authentication flaws are weaknesses in the process of verifying who a user is. This includes poor password policies (like allowing ‘password123’), weak session management (like using predictable session IDs), insecure password recovery flows (where the answer to a security question is easily guessed), and failure to implement multi-factor authentication (MFA). Attackers exploit these by brute-forcing passwords, capturing session tokens through network sniffing or XSS, or simply guessing weak credentials. The exam often tests your ability to pick out which scenario describes a broken authentication mechanism versus a CSRF or XSS attack.

Why do these vulnerabilities exist? Often because developers prioritise speed over security, don’t validate inputs, or rely on outdated coding practices. The OWASP Top 10 is a published list of the most critical web application security risks, published by the Open Web Application Security Project — it’s essential reading for CEH candidates, as the exam references it directly.

Each of these attacks can be prevented by specific countermeasures: parameterised queries (for SQLi), output encoding (for XSS), anti-CSRF tokens, and strong authentication mechanisms like MFA and secure session handling. As an ethical hacker, you need to test for each of these flaws using both automated scanners and manual techniques, then report them so they can be fixed.

An IT security professional, often called a penetration tester or ethical hacker, systematically tests web applications for these vulnerabilities. Here’s a concrete scenario:

You’re hired by ‘BookStore Online’, a company that sells books through a web application. Your job: find vulnerabilities before a real attacker does.

Step 1: Reconnaissance. You start by mapping out the application — you visit every page, fill out every form, and note every place where the application accepts user input: search bars, login fields, feedback forms, profile update pages, and the ‘forgot password’ flow.

Step 2: Automated scanning. You run a web vulnerability scanner (like OWASP ZAP or Burp Suite) that sends thousands of attack payloads to each input point. The scanner flags a potential SQL injection on the product search page — when you enter a single quote ('), the application returns a database error message. That error tells you the application is vulnerable.

Step 3: Manual exploitation. You confirm the SQLi by entering a payload that causes a time delay (like 'waitfor delay '0:0:5' -- on SQL Server). The site slows down by exactly five seconds — confirmed. You now extract data from the database, starting with a simple statement to list the current database name and then enumerate tables. Within an hour, you find a table called ‘users’ containing admin credentials stored in plain text.

Step 4: XSS discovery. While testing the feedback form, you submit '<script>alert('xss')</script>’. When you visit the page that displays feedback (as an admin would), a pop-up appears with ‘xss’. This is a stored XSS vulnerability — an attacker could send a payload that steals the admin’s session cookie and redirect it to an attacker-controlled server.

Step 5: CSRF test. You identify the ‘change email address’ endpoint. You create a simple HTML page with a form that automatically submits to that endpoint. You load the page in a browser where you’re still logged in as a test user — the email changes without any user interaction. You report this as a CSRF flaw.

Step 6: Authentication analysis. You brute-force the login page using a wordlist of common passwords and find that three accounts have the password ‘123456’. The password reset flow emails a reset link to the registered email, but it doesn’t invalidate old sessions — an attacker who gains access to a user’s email inbox can reset the password and hijack the account.

By the end of the engagement, you produce a report listing each vulnerability, its severity, step-by-step reproduction steps, and recommended fixes. The developer team then patches the SQL injection by using parameterised queries, sanitises output to fix XSS, adds CSRF tokens to every state-changing form, and enforces a strict password policy. The professional’s role is to think like an attacker — anticipate every trick — to protect the business from real-world breaches.