File Inclusion Report

pg. 1
File Inclusion Report

TABLE OF CONTENT
1. Prerequisite................................................................................................3
1.1 Logical Operators in SQL.......................................................................3
1.1.1Multiple AND/OR Operation within single statement........................4
1.1 Important functions used with select....................................................5
2. What is SQL Injection ?...............................................................................5
2.1 Introduction...........................................................................................5
2.2 Types of SQL Injection...........................................................................6
2.3 Impact of SQL Injection.........................................................................7
3. Simple Error-based SQL Injection................................................................8
3.1 Target....................................................................................................8
3.2 Functionality..........................................................................................8
3.3 Beyond Logic.........................................................................................8
3.4 Exploitation...........................................................................................9
3.4.1 Exploiting single normal user (correct username required)...........9
3.4.2 Exploiting all user (username not required)...................................9
4. UNION Injection........................................................................................10
4.1 Identifying the number of columns......................................................11
4.1.1 Using Order by Clause...................................................................11
4.1.2 Using Select clause.......................................................................11
4.2 Location of Injection............................................................................12
4.3 Exploitation.........................................................................................12
4.3.1 Identifying number of columns using ORDER clause.....................12
4.3.2 Identifying number of columns using SELECT clause....................12
4.3.3 Identifying injection point..............................................................13
4.3.4 Using functions to enumerate database........................................14
4.3.5 Identify all databases....................................................................14
4.3.6 Identify Current Database.............................................................15
4.3.7 Identify tables within specific database........................................15
4.3.8 Identify columns within specific tables and database...................16
pg. 2
File Inclusion Report

4.3.9 Fetching data from another tables................................................17

4. Mitigation.................................................................................................17
5. Conclusion................................................................................................19

pg. 3
File Inclusion Report

1. Prerequisite
1.1 Logical Operators in SQL

Execution of Logical Operators

pg. 4
File Inclusion Report

1.1.1Multiple AND/OR Operation within single statement

1.1 Some useful global variables

Important functions used with select

Other functions are:

pg. 5
File Inclusion Report

Useful function to print all rows within single line

2. What is SQL Injection ?

pg. 6
File Inclusion Report

2.1 Introduction
SQL Injection is a web application security vulnerability that occurs when
untrusted user input is improperly incorporated into a Structured Query
Language (SQL) statement, allowing an attacker to alter the intended logic
of database queries.

pg. 7
File Inclusion Report

2.2 Types of SQL Injection

1) In-Band SQL Injection: This type of SQL injection uses the same
communication channel to both deliver the malicious payload and receive
the results.
a) Error-based SQL Injection: Relies on database error messages
generated by malformed queries to extract information about the
database structure, schema, or data.
b) Union-Based SQL Injection: Exploits the SQL UNION operator to
combine the results of a malicious query with a legitimate query,
allowing direct retrieval of database contents.
2) Blind SQL Injection: Occurs when the application does not return
database errors or query results directly, but the attacker can infer
information based on application behavior.
a) Boolean-Based Blind SQL Injection: The attacker determines true
or false outcomes of injected conditions by observing differences in
application responses.
b) Time-Based Blind SQL Injection: The attacker infers information by
measuring response delays caused intentionally by injected timing
functions.
3) Out-of-Band SQL Injection: This type exploits alternative
communication channels to exfiltrate data when direct responses are not
available. It depends on database features that can initiate external
network interactions.
4) Second-Order SQL Injection: In this scenario, malicious input is stored
by the application and later used in a database query without proper
sanitization, triggering the injection at a different execution point.

2.3 Impact of SQL Injection

 Unauthorized access to sensitive data stored in the database, including
user credentials and personal information
 Authentication and authorization bypass, allowing attackers to
impersonate legitimate users or gain administrative access
 Disclosure of database structure, schema details, and application logic
through query manipulation or error leakage
 Modification or deletion of database records, leading to data integrity
loss
 Insertion of malicious or fraudulent data into the database
 Complete compromise of the database server in severe cases,
depending on database privileges

pg. 8
File Inclusion Report

 Escalation of application-level vulnerabilities into full system-level

compromise

3. Simple Error-based SQL Injection

3.1 Target

We’re provided with a simple login form where we can login with the help of
credentials.

3.2 Functionality
Whenever we enter the correct credentials, it fetches the secret string for
the corresponding user. Demo credentials: Thor/Asgard

pg. 9
File Inclusion Report

3.3 Beyond Logic

Thus, the web application server may be running this type of SQL query in
the database server and returning the result of secret for that specific user
as follows:

3.4 Exploitation
3.4.1 Exploiting single normal user (correct username
required)
Understanding the Importance of Space (MySQL Specific)
Payload Used: thor’;-- (in the username field)

3.4.2 Exploiting all user (username not required)

Payload used: whoami’ OR 1=1;--

pg. 10
File Inclusion Report

The web application returned single output due to the logic implemented in
the application server to print result of first record only. Else full query is
executed in the database server of BWAPP.

4. UNION Injection to exploit database

The target and functionality are same as the last lab. We’re provided with a
login form and credentials as Thor/Asgard. Now we’ve to identify various
things on our own. So, let’s begin.
To successfully execute a UNION, query the query must have:
i) Same number of columns (main thing to look at while finding SQLi)
ii) Same (or Compatible) datatype
Explanation of compatible data types:

pg. 11
File Inclusion Report

4.1 Identifying the number of columns

4.1.1 Using Order by Clause
we can start with order by 1, sort by the first column, and succeed, as the
table must have at least one column. Then we will do order by 2 and
then order by 3 until we reach a number that returns an error, or the page
does not show any output, which means that this column number does not
exist. The final successful column we successfully sorted by gives us the
total number of columns.

pg. 12
File Inclusion Report

4.1.2 Using Select clause

The other method is to attempt a Union injection with a different number of
columns until we successfully get the results back. The first method always
returns the results until we hit an error, while this method always gives an
error until we get a success.

4.2 Location of Injection

While a query may return multiple columns, the web application may only
display some of them. So, if we inject our query in a column that is not
printed on the page, we will not get its output. This is why we need to
determine which columns are printed to the page, to determine where to
place our injection.
It can be determined by using the select clause to determine the number of
rows. We’ve seen in the above image that the no. 1,2,3,4 are successfully
returned in the result. Thus we can manipulate queries to return our desired
result as follows:

pg. 13
File Inclusion Report

4.3 Exploitation
4.3.1 Identifying number of columns using ORDER clause
Thus, there are 4 columns as it gives error on 5.

4.3.2 Identifying number of columns using SELECT clause

Thus, there are 4 no. of column as it gives result only on 1,2,3,4.

Actual backend query:

4.3.3 Identifying injection point.

One thing we identified while identifying the number of columns that we’re
only returned with 1 row in the output. Thus, we’ve to use no result first

pg. 14
File Inclusion Report

statement and to show our output and the space for injection as understood
in the location of injection. Let’s see.

Thus, our injection points are 2 and 4.

4.3.4 Using functions to enumerate database

Let’s use this injection points to get our required output. Thus, we
successfully enumerated the username and the version being used.

pg. 15
File Inclusion Report

4.3.5 Identify all databases

Another query: SELECT schema_name FROM

information_schema.schemata;
To retrieve 2nd row, we can add LIMIT 1 OFFSET 2 at the end of the query.
Shown in 4.3.7.

4.3.6 Identify Current Database

pg. 16
File Inclusion Report

We can see the user difference because we’re running MySQL on command-
line as root and web application is using the bwapp user.

4.3.7 Identify tables within specific database

It is due to the application logic of web application it is returning the first row
only. Thus we can use this command to fetch next row:

pg. 17
File Inclusion Report

4.3.8 Identify columns within specific tables and database

pg. 18
File Inclusion Report

4.3.9 Fetching data from another tables

Once the desired target—database name, table name, column name, and
column type—is identified, our missiles are loaded and ready to fire.

Using offset we can fetch rows one by one to reach till last user.

5. Union Injection to exploit Database Server

So far, we understood how we can utilize UNION injection to enumerate and
extract sensitive and required information from the database. Now we’ll try
to utilize UNION injection to exploit Database server. Again, we’ve the same
target of the web application login form which we’ll utilize to exploit the
Database server.

5.1 Checking for required role

We already know that how to find which user is currently executing database
commands in the server using user(). Let’s now check if that user has super

pg. 19
File Inclusion Report

privileges available:

Yes, our user has. Let’s check through the web application.

5.2 Checking for required permission

We can see that we’ve the required FILE privileges to work with local files.

pg. 20
File Inclusion Report

5.3 Reading System files

Payload: ' UNION SELECT 1, LOAD_FILE("/etc/passwd"),3,4;--

pg. 21
File Inclusion Report

5.4 Writing System files

When it comes to writing files to the back-end server, it becomes much
more restricted in modern DBMSes, since we can utilize this to write a web
shell on the remote server, hence getting code execution and taking over
the server.
To be able to write files to the back-end server using a MySQL
database, we require three things:
1. User with FILE privilege enabled
2. MySQL global secure_file_priv variable not enabled
3. Write access to the location we want to write to on the back-end server

5.4.1 Checking required permissions

We already know that the user bwapp has FILE privileges enabled for
himself. Let’s check for the secure_file_priv permissions.

We’ve nothing in that column which means we’re able to read/write all over
the database server.

pg. 22
File Inclusion Report

5.4.2 Writing Files

Even though it showed an error a shell is successfully uploaded.

pg. 23
File Inclusion Report

6 Boolean based blind SQL Injection

6.1 Theoretical Explanation
6.1.1 Tables for understanding purpose

6.1.2 Functionality
User can check whether his username is available in the database or not by
entering his username. It returns no result or even any error of any other
injected queries (UNION/SELECT).
URL: [Link]
Actual backend SQL Query: SELECT * from employees_a WHERE
username=’bob’;

If user is available, it returns his employee id and name and if not then no
result.
pg. 24
File Inclusion Report

Now we want to check the id of employees b who are actually admin

employees but we don’t know their ids. UNION injection is not possible there.
Then how we can check for those things. Or let say we want to check that
for which id what is the username then how we’re goanna check. This can be
done with the help of Boolean based blind SQL injection where we try to
understand the application and exploit it.

6.1.3 Exploitation
Note: We’re assuming that we’ve no knowledge of employees_b table which
we’re extracting with the help of Boolean based blind SQL injection.
Step – 1: We know that BOB is a username present therein. Let’s
understand the Boolean expression first.

Since both statement is true in second query, we successfully get username

and since in third query we’ve a false statement (1=2) it returned empty. In
this way we can determine other things which is not directly visible to us.
Step – 2: After understanding the Boolean things of SQL let’s how many
admin employees are there.

pg. 25
File Inclusion Report

Thus, we can determine there are 4 no. of employees. This can be done in
multiple ways as well.
Step – 3: In the same way we can determine which ids are present there.
Assuming that ids have been checked let’s move forward by checking the
employee names present therein.

This query determines that there is atleast one person with first letter of
emp_name as c.
Step – 4: Similarly, through brute force method we can identify each
character one by one and finally the full name of the user.

This is what the actual scenario behind the Boolean-based blind

SQL injection. Let’s move towards practical.

6.2 Practical Demonstration

6.2.1 Functionality

pg. 26
File Inclusion Report

If a movie exists only a message is displayed that “The movie exists!”.

Nothing else.
If a movie doesn’t exist it simply gives a result that this movie doesn’t exist.
Thus, there is nothing returned from the database at all. But the database
server is checking that whether that movie exists and we can take
advantage of Boolean-based blind SQL injection to exploit that feature.

6.2.2 Identification

Thus, we can determine that an SQL Injection is present therein as when the
query is false it returns another message. We can take advantage of this.

4. Mitigation
1. Replace OS commands with native APIs
Example:
 Use filesystem APIs ([Link], mkdir, open) instead of exec("touch
…")
 Use database or library functions instead of shell utilities
2. Use non-shell execution APIs only
 Prefer execFile() / spawn() with shell: false ([Link])
 Avoid APIs that invoke /bin/sh implicitly
3. Hard-code command and pass arguments as an array
 Command must be static
 Arguments must be passed separately, never as a single string
4. Strict allowlist validation with regex
 Allow only expected characters
 Example: ^[a-zA-Z0-9_-]{1,50}$ for filenames
 Reject input immediately if it fails validation
pg. 27
File Inclusion Report

5. Canonicalize input before validation

 Decode URL encoding, Unicode, or escape sequences before checking
 Prevent bypass using double-encoding tricks
6. Enforce fixed paths and extensions
 Do not allow user-controlled directories
 Append extensions server-side, never accept them from user input
7. Drop privileges before execution
 Run command-executing logic under a low-privileged OS user
 No write/exec permissions outside required directories
8. OS-level controls
 Use AppArmor / SELinux profiles
 Restrict allowed binaries and filesystem access
9. Disable dangerous functions at runtime/config level
 PHP: disable system, exec, shell_exec, popen if not required
 [Link]: block child_process usage via code policy or lint rules
10. Use containers or sandboxed workers
 Execute unavoidable commands inside Docker / sandboxed subprocess
 Read-only filesystem where possible
11. Add command execution guards
 Centralize command execution in one controlled wrapper function
 Reject execution if unexpected arguments or command mismatch
occurs
12. Implement runtime detection
 Alert on metacharacters, long inputs, or repeated failures
 Log full execution context for forensic analysis

pg. 28
File Inclusion Report

5. Conclusion
Command injection is a high-impact and often overlooked vulnerability that
can lead to complete server compromise when user input is improperly
passed to system-level command execution. Because it allows attackers to
execute arbitrary OS commands, a single flaw can result in data theft,
privilege escalation, service disruption, or full takeover of the underlying
infrastructure. This makes command injection one of the most dangerous
classes of vulnerabilities, demanding strict preventive controls and secure
design decisions rather than reactive fixes.

pg. 29
File Inclusion Report

pg. 30