Lab3.

md 2024-04-28

Lab 3
Login Jim
For this challenge, we explored a flaw in the way that the application handles user input. The application is
vulnerable to a SQL injection attack, which allows us to login as admin.

Basically, we close the SQL query with a single quote use a OR 1=1 to always return true and comment out
the rest of the query. This will allow us to login as admin.

/
Lab3.md 2024-04-28

To log with Jim account, we need his email. So we observed the email of the admin account and tried different
combinations to find Jim's email. We found that Jim's email is jim@juice-sh.op. With this information, we login
as "jim@juice-sh.op'--", this will comment out the rest of the query and allow us to login as Jim.

User Credentials
/
Lab3.md 2024-04-28

To begin the challenge, we begin to understand how can we make a search in the database. we search for
carrot, and the search is "search?q=carrot". We can see that the search is a GET request and the query is in
the URL.

Now, we need to understand how the query is being made. We use BurpSuite to intercept the request and
see how the query is being made.

We try to search for "carrot'" and we get an error. This error is very useful to understand how the query is
being made.

Now that we can see the query, we can try manipulate that, for example, using using ' for end the search
campus, )) to close the query and "--" to comment out the rest of the query, we obtain a successful GET
request.

/
Lab3.md 2024-04-28

Now that we can make the request that we want and we know that we are workin with SQLite, eu can search
ways to explore this.

After seraching, we discorver that exists a table called "sqlite_master" that contains the name of all the tables
in the database. We can use this to find the name of the table that contains the user credentials.

We use the query search?q=carrot'))UNION SELECT sql FROM sqlite_master-- to obtain the
name of the tables. We notice that using UNION, we need to select the same number of collumns in each
side of the UNION.

Note that we need to use %20 to represent the space in the request.

After trying different number of collumns, we found that the number is 9 and we can see all the tables in the
database. Including the table "Users", that contains the user credentials, and sohow us that we have 2
important parameters in the table, "email" and "password".

/
Lab3.md 2024-04-28

Now that we know the name of the table, we can try to obtain the user credentials. We use the query
search?q=carrot'))UNION SELECT username, email, password,4,5,6,7,8,9 FROM Users-
- to obtain the user credentials.

SQL Injection Vulnerability

Description

SQL injection occurs when an application fails to properly sanitize user-supplied input used in SQL queries.
Attackers can manipulate the input to inject malicious SQL code, allowing them to execute arbitrary SQL
commands against the application's database. In this case, the application's login functionality is vulnerable to
SQL injection, allowing attackers to bypass authentication and gain unauthorized access to the system.

Relevant CWEs (Common Weakness Enumeration)

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

/
Lab3.md 2024-04-28

CWE-20: Improper Input Validation

CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component
('Injection')

Mitigation and Fixing Strategies

1. Use Prepared Statements/Parameterized Queries: Instead of dynamically constructing SQL queries

by concatenating strings with user input, use parameterized queries or prepared statements provided
by the database API. This approach separates SQL logic from user input, preventing injection attacks.

2. Input Validation and Sanitization: Validate and sanitize all user input before using it in SQL queries.
Ensure that input adheres to expected formats and does not contain any malicious characters or SQL
syntax.

3. Least Privilege Principle: Implement least privilege access controls to limit the capabilities of
database accounts and ensure they only have access to the necessary resources and operations.

4. Database Firewall and WAF: Implement database firewalls and web application firewalls (WAFs) to
monitor and filter incoming SQL queries for malicious patterns.

5. Regular Security Audits and Penetration Testing: Conduct regular security audits and penetration
testing to identify and remediate vulnerabilities, including SQL injection vulnerabilities, before they can
be exploited by attackers.

Which lines of which code files were responsible for the vulnerabilities?
There were vulnerabilities but, despise the fact that we have the code, we can not see the lines of code that
are responsible for the vulnerabilities. The angular project is very complex and search for the lines of code
that are responsible for the vulnerabilities is very difficult and exhaustive. We can see the query that is sent to
de sqlite database, but we can not see the code that generates this query.

How can the code that led to these vulnerabilities be fixed?

Even though we can not see the code, the code certainly uses string concatenation to build SQL queries,
which is a common cause of SQL injection vulnerabilities.

Were the vulnerabilities detected by the automated (static or dynamic)

analysers? why do you think that is the case?
Yes, they were detected by the automated analyzers. The analyzers are designed to identify common security
vulnerabilities, including SQL injection, by analyzing the code for patterns and behaviors that indicate
potential weaknesses. In this case, the analyzers likely detected the vulnerabilities by identifying the use of
unsanitized user input in SQL queries, which is a common indicator of SQL injection vulnerabilities. The
analyzers can recognize these patterns and provide alerts or warnings to developers, prompting them to
review and fix the vulnerable code.

/
Lab3.md 2024-04-28

You may patch the code and rerun the analyses. would the analysers no
longer report the fixed code as vulnerabilities? why do you think that is
the case?
If we fix the code by using prepared statements or parameterized queries, the SQL injection vulnerability
would be mitigated, and the automated analyzers would no longer report the issue as a vulnerability. This is
because prepared statements separate SQL logic from user input, preventing attackers from injecting
malicious SQL code into the queries. The analyzers would not detect the vulnerability because the code is
now secure and resistant to SQL injection attacks.