Cross-Site Scripting (XSS) is a code injection vulnerability that allows attackers to inject malicious client-side scripts (typically JavaScript) into web pages viewed by other users. When a victim's browser loads the compromised page, it executes the malicious script as if it were legitimate code from the trusted website.

Attack Principle:

XSS exploits the browser's trust in data received from a web server. If a web application incorporates user-supplied data into its dynamic pages without proper validation or encoding, an attacker can craft input that, when rendered, is interpreted as executable script by the victim's browser.

Conceptual Example:

Imagine an online bulletin board where users can post comments. An attacker submits a comment that contains:

. If the bulletin board application directly displays this comment to other users without sanitizing the input, anyone viewing that comment will have their browser execute the injected script. This script would then steal their session cookie (document.cookie) and send it to the attacker's server, enabling session hijacking.

Types of XSS (Server-Side Context):

• Reflected XSS (Non-Persistent): The malicious script is not permanently stored on the target server. Instead, it is immediately "reflected" back to the user from the server's response (e.g., in an error message, search result page, or dynamic content based on URL parameters). The attacker typically tricks the victim into clicking a specially crafted URL containing the malicious payload.
• Stored XSS (Persistent): This is generally the more dangerous type. The malicious script is permanently stored on the vulnerable web application's server (e.g., in a database, forum post, comment section, user profile). Whenever a user accesses the page containing the stored malicious content, their browser retrieves and executes the script. This allows for wider, more persistent attacks without requiring individual user interaction with a malicious link.

Cross-Site Request Forgery (CSRF), also known as "one-click attack" or "session riding," tricks a victim's web browser into making an unwanted, authenticated request to a vulnerable web application where the victim is currently logged in. The attack exploits the fact that browsers automatically send cookies (including session cookies) with requests to a domain, regardless of where the request originated.

Attack Principle:

The attacker crafts a malicious request (e.g., a hidden form submission, an image tag, an AJAX request) that performs an action on the victim's behalf (e.g., change password, transfer money, make a purchase). The attacker then embeds this malicious request on a website they control (or through phishing emails). When the victim, who is already authenticated to the target vulnerable application, visits the attacker's malicious site, their browser automatically includes their valid session cookies for the target site with the forged request.

Conceptual Example:

You are logged into your online banking website. An attacker sends you an email with a seemingly innocent image (or a link to a malicious website). Unbeknownst to you, the image URL in the email is . If you open this email while still logged into your bank account, your browser will attempt to load the "image." Because it's a request to yourbank.com, your browser automatically attaches your banking session cookie. The bank's server receives the request, sees your valid cookie, and proceeds to initiate a transfer of 1000 units of currency to the attacker's account, all without any direct interaction from you beyond opening the email.

SQL Injection (SQLi) is a code injection vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This is achieved by inserting malicious SQL code into input fields (e.g., username, password, search boxes, URL parameters) that are directly incorporated into dynamically constructed SQL statements by the application, without proper sanitization or parameterization.

Attack Principle:

The attacker's input is incorrectly treated as part of the SQL query itself, rather than as literal data. This allows the attacker to manipulate the original query's logic, execute arbitrary SQL commands, or retrieve unauthorized data.

Conceptual Example:

Consider a login form where the server constructs a query like: SELECT * FROM Users WHERE Username = ' user_input ' AND Password = ' password_input ';
- Normal Input: If a user enters Alice for username and secret for password, the query becomes SELECT * FROM Users WHERE Username = 'Alice' AND Password = 'secret';
- Attack Input (Bypass Authentication): If an attacker enters admin' OR '1'='1 for the username and anything for the password, the query becomes: SELECT * FROM Users WHERE Username = 'admin' OR '1'='1' AND Password = '...' ; Since '1'='1' is always true, the OR '1'='1' clause makes the entire WHERE condition true, effectively authenticating the attacker as admin (or the first user in the database) without knowing the password.

Command Injection is a vulnerability that occurs when an application executes arbitrary operating system commands as a result of insecurely incorporating user-supplied input into system calls. This happens when an application dynamically constructs shell commands (or other executable commands) using unsanitized user input, and then executes these commands directly on the underlying operating system.

Attack Principle:

The attacker's input includes characters that act as command separators (e.g., ;, &, |, &&, ||, \n) or special shell characters, allowing them to chain additional commands to the one the application intends to execute. The operating system then executes the attacker's injected commands alongside (or instead of) the legitimate command.

Conceptual Example:

Imagine a web application that allows an administrator to "ping" a network host by entering an IP address. The application might internally execute ping user_supplied_ip.
- Normal Input: If the administrator inputs 192.168.1.1, the command executed is ping 192.168.1.1.
- Attack Input: If an attacker (who might gain access to this admin function) enters 127.0.0.1; rm -rf / as the IP address, and the application directly passes this to a shell, the command executed becomes: ping 127.0.0.1; rm -rf /. The semicolon acts as a command separator, causing the rm -rf / (remove all files from the root directory) command to be executed after the ping.