Elvis Wiki - User contributions [en]

Cross-Site Scripting (XSS)

2024-12-18T17:53:59Z

MVucinic: /* References */

[[Category:Basic]]
== Cross-Site Scripting (XSS) ==

[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of the application. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The different types are listed below. It is also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
DOM-based Cross-Site Scripting (XSS) is a type of XSS attack that occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks can occur when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is then sent to a user's browser, where it is executed. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

==Demonstrations==

This section demonstrates the three Cross-Site Scripting (XSS) attacks using the intentionally vulnerable OWASP Mutillidae II platform. These demonstrations include Stored XSS, Reflected XSS, and DOM-based XSS attacks, showcasing how vulnerabilities can be exploited to steal sensitive information in real-world scenarios. Specifically, these examples focus on stealing the victim's cookies.

If you want to recreate these attacks, refer to this article: https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021) for detailed instructions on installing and using OWASP Mutillidae II.

===Preparation Steps===
Before demonstrating the attacks, it's essential to understand the groundwork required for successful execution. This includes identifying vulnerabilities, inspecting cookies, and preparing the necessary scripts and files for the exploitation process.

====Searching for Exploits====

Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:

* Analyzing the Page Source: Review the HTML and JavaScript code for insecure functions like innerHTML, document.write, or unescaped user inputs. These functions often process user-supplied data without proper sanitization, creating potential attack vectors.
* Testing Input Fields: Use simple script tags to test input validation. For example, <script>alert("Yooooooo")</script> can reveal whether the application sanitizes or escapes user input. If the alert box appears, it indicates the input field is vulnerable.
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:
* Check the "Application" tab for cookies or local storage.
Inspect server responses and client-side behavior to understand how data flows between them.

[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]

Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.

====Inspecting Cookies====

Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:

* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."
* Check for Security Flags: Look for cookies missing protective flags such as HttpOnly (prevents client-side access), Secure (ensures transmission over HTTPS), or SameSite (restricts third-party context usage).
* Use the Console: Enter document.cookie in the browser console to see if cookies are accessible. If cookies are displayed, they are vulnerable to theft.

[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]

Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.

====Required Files====

To execute the XSS demonstrations successfully, the following files and scripts are essential:

* Cookie Logger Script (cookie-logger.php): A PHP script hosted on the attacker’s server to log cookies sent by the malicious payload. It listens for a cookies parameter in the URL, extracts its value, and writes it to the stolen-cookies.txt file along with a timestamp.
* Stolen Cookies File (stolen-cookies.txt): A plain text file used to store intercepted cookies. Each entry includes the captured cookie data and the timestamp of when it was received.
* Malicious Script: A custom JavaScript payload crafted to exploit the identified vulnerabilities. This script retrieves cookies using document.cookie and sends them to the attacker’s cookie-logger.php script.

[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]

These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.

====Demonstrations====
=====Stored XSS=====
Stored XSS involves injecting malicious scripts that are permanently stored on the server, such as in a database or a comment field. These scripts execute whenever a victim accesses the vulnerable page. I used the ”Add to your blog” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/Persistent (Second Order) in Mutillidae II.

This is the script we then send to the database to essentally "poison" the website:

[[File:Stored-script.PNG]]

Once this is uploaded one can check if its properly working by visiting this website from another device and also ckecking the stolen-cookies.txt file. If, after visiting the site, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a Stored XSS attack.

=====Reflected XSS Attack=====

Reflected XSS uses a crafted URL that directly includes the malicious payload, which is reflected back in the server's response. This attack relies on tricking the victim into clicking the URL. I used the ”DNS Lookup” found underOWASP 2017/A7 - Cross-Site Scripting (XSS)/Reflected (First Order) in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a ReflectedXSS attack. Note:the second and thrid IP should be the attackers servers IP.

=====DOM based XSS=====

DOM-based XSS manipulates the client-side Document Object Model (DOM) without server interaction. The attack occurs entirely in the victim's browser. I used the ”Password Generator” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/DOM-Based in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a DOM based XSS attack. ote:the second and thrid IP should be the attackers servers IP.

These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.

== XSS attack consequences ==

A Cross-Site Scripting (XSS) attack can have various severe consequences, including:

'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.

'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.

'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.

'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.

'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.

'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.

'''Reputation Damage''': Cross-Site Scripting (XSS) attacks have the potential to damage user confidence in a website or application, particularly in cases where personal information is exposed.
== Prevention==

The prevention of these vulnerabilities is the responsibility of the programmer. Programmers should adopt secure programming practices, such as context-sensitive server-side output encoding, to ensure the prevention of malicious script injections through incorrect or unchecked entries.

Effective prevention measures include:

'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.

'''Output encoding''': Encoding all output data (using HTML entities) is another effective measure to prevent cross-site scripting. This ensures proper display in the user's browser.

'''Content Security Policy (CSP)''': Implementing a Content Security Policy defines rules for the types of content a website can load, contributing to preventing cross-site scripting attacks.

'''Use of tokens''': Employing random character strings (tokens) to identify users can help prevent cross-site scripting attacks, ensuring that only authorized users access the website.

'''Disabling script execution''': While disabling script execution on the server, especially for certain scripting languages like JavaScript or VBScript, can help prevent cross-site scripting, it is rarely used due to the widespread use of JavaScript.

'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.

'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.

'''Security Patching''': Ensuring that all software, including web servers, databases and frameworks, are kept up to date with the latest security patches. Regular updates and patches should be applied to fix known vulnerabilities in the system.

'''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
* https://portswigger.net/web-security/cross-site-scripting
* https://www.sans.org/white-papers/988/
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)

Cross-Site Scripting (XSS)

2024-12-18T17:53:47Z

MVucinic: /* Demonstrations */

Cross-Site Scripting (XSS)

2024-12-18T17:52:59Z

MVucinic: /* Demonstrations */

[[Category:Basic]]
== Cross-Site Scripting (XSS) ==

[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of the application. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The different types are listed below. It is also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
DOM-based Cross-Site Scripting (XSS) is a type of XSS attack that occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks can occur when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is then sent to a user's browser, where it is executed. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

==Demonstrations==

This section demonstrates the three Cross-Site Scripting (XSS) attacks using the intentionally vulnerable OWASP Mutillidae II platform. These demonstrations include Stored XSS, Reflected XSS, and DOM-based XSS attacks, showcasing how vulnerabilities can be exploited to steal sensitive information in real-world scenarios. Specifically, these examples focus on stealing the victim's cookies.

If you want to recreate these attacks, refer to this article: OWASP Mutillidae (2021) for detailed instructions on installing and using OWASP Mutillidae II.

===Preparation Steps===
Before demonstrating the attacks, it's essential to understand the groundwork required for successful execution. This includes identifying vulnerabilities, inspecting cookies, and preparing the necessary scripts and files for the exploitation process.

====Searching for Exploits====

Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:

* Analyzing the Page Source: Review the HTML and JavaScript code for insecure functions like innerHTML, document.write, or unescaped user inputs. These functions often process user-supplied data without proper sanitization, creating potential attack vectors.
* Testing Input Fields: Use simple script tags to test input validation. For example, <script>alert("Yooooooo")</script> can reveal whether the application sanitizes or escapes user input. If the alert box appears, it indicates the input field is vulnerable.
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:
* Check the "Application" tab for cookies or local storage.
Inspect server responses and client-side behavior to understand how data flows between them.

[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]

Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.

====Inspecting Cookies====

Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:

* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."
* Check for Security Flags: Look for cookies missing protective flags such as HttpOnly (prevents client-side access), Secure (ensures transmission over HTTPS), or SameSite (restricts third-party context usage).
* Use the Console: Enter document.cookie in the browser console to see if cookies are accessible. If cookies are displayed, they are vulnerable to theft.

[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]

Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.

====Required Files====

To execute the XSS demonstrations successfully, the following files and scripts are essential:

* Cookie Logger Script (cookie-logger.php): A PHP script hosted on the attacker’s server to log cookies sent by the malicious payload. It listens for a cookies parameter in the URL, extracts its value, and writes it to the stolen-cookies.txt file along with a timestamp.
* Stolen Cookies File (stolen-cookies.txt): A plain text file used to store intercepted cookies. Each entry includes the captured cookie data and the timestamp of when it was received.
* Malicious Script: A custom JavaScript payload crafted to exploit the identified vulnerabilities. This script retrieves cookies using document.cookie and sends them to the attacker’s cookie-logger.php script.

[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]

These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.

====Demonstrations====
=====Stored XSS=====
Stored XSS involves injecting malicious scripts that are permanently stored on the server, such as in a database or a comment field. These scripts execute whenever a victim accesses the vulnerable page. I used the ”Add to your blog” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/Persistent (Second Order) in Mutillidae II.

This is the script we then send to the database to essentally "poison" the website:

[[File:Stored-script.PNG]]

Once this is uploaded one can check if its properly working by visiting this website from another device and also ckecking the stolen-cookies.txt file. If, after visiting the site, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a Stored XSS attack.

=====Reflected XSS Attack=====

Reflected XSS uses a crafted URL that directly includes the malicious payload, which is reflected back in the server's response. This attack relies on tricking the victim into clicking the URL. I used the ”DNS Lookup” found underOWASP 2017/A7 - Cross-Site Scripting (XSS)/Reflected (First Order) in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a ReflectedXSS attack. Note:the second and thrid IP should be the attackers servers IP.

=====DOM based XSS=====

DOM-based XSS manipulates the client-side Document Object Model (DOM) without server interaction. The attack occurs entirely in the victim's browser. I used the ”Password Generator” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/DOM-Based in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a DOM based XSS attack. ote:the second and thrid IP should be the attackers servers IP.

These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.

== XSS attack consequences ==

A Cross-Site Scripting (XSS) attack can have various severe consequences, including:

'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.

'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.

'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.

'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.

'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.

'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.

'''Reputation Damage''': Cross-Site Scripting (XSS) attacks have the potential to damage user confidence in a website or application, particularly in cases where personal information is exposed.
== Prevention==

The prevention of these vulnerabilities is the responsibility of the programmer. Programmers should adopt secure programming practices, such as context-sensitive server-side output encoding, to ensure the prevention of malicious script injections through incorrect or unchecked entries.

Effective prevention measures include:

'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.

'''Output encoding''': Encoding all output data (using HTML entities) is another effective measure to prevent cross-site scripting. This ensures proper display in the user's browser.

'''Content Security Policy (CSP)''': Implementing a Content Security Policy defines rules for the types of content a website can load, contributing to preventing cross-site scripting attacks.

'''Use of tokens''': Employing random character strings (tokens) to identify users can help prevent cross-site scripting attacks, ensuring that only authorized users access the website.

'''Disabling script execution''': While disabling script execution on the server, especially for certain scripting languages like JavaScript or VBScript, can help prevent cross-site scripting, it is rarely used due to the widespread use of JavaScript.

'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.

'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.

'''Security Patching''': Ensuring that all software, including web servers, databases and frameworks, are kept up to date with the latest security patches. Regular updates and patches should be applied to fix known vulnerabilities in the system.

'''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
* https://portswigger.net/web-security/cross-site-scripting
* https://www.sans.org/white-papers/988/
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp

Cross-Site Scripting (XSS)

2024-12-18T17:51:37Z

MVucinic: /* Reflected XSS Attack */

[[Category:Basic]]
== Cross-Site Scripting (XSS) ==

[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of the application. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The different types are listed below. It is also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
DOM-based Cross-Site Scripting (XSS) is a type of XSS attack that occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks can occur when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is then sent to a user's browser, where it is executed. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

==Demonstrations==

This section demonstrates three Cross-Site Scripting (XSS) attacks using the intentionally vulnerable OWASP Mutillidae II platform. These demonstrations include Stored XSS, Reflected XSS, and DOM-based XSS attacks, showcasing how vulnerabilities can be exploited to steal sensitive information in real-world scenarios. Specifically, these examples focus on stealing the victim's cookies.

If you want to recreate these attacks, refer to this article: OWASP Mutillidae (2021) for detailed instructions on installing and using OWASP Mutillidae II.

===Preparation Steps===
Before demonstrating the attacks, it's essential to understand the groundwork required for successful execution. This includes identifying vulnerabilities, inspecting cookies, and preparing the necessary scripts and files for the exploitation process.

====Searching for Exploits====

Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:

* Analyzing the Page Source: Review the HTML and JavaScript code for insecure functions like innerHTML, document.write, or unescaped user inputs. These functions often process user-supplied data without proper sanitization, creating potential attack vectors.
* Testing Input Fields: Use simple script tags to test input validation. For example, <script>alert("Yooooooo")</script> can reveal whether the application sanitizes or escapes user input. If the alert box appears, it indicates the input field is vulnerable.
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:
* Check the "Application" tab for cookies or local storage.
Inspect server responses and client-side behavior to understand how data flows between them.

[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]

Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.

====Inspecting Cookies====

Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:

* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."
* Check for Security Flags: Look for cookies missing protective flags such as HttpOnly (prevents client-side access), Secure (ensures transmission over HTTPS), or SameSite (restricts third-party context usage).
* Use the Console: Enter document.cookie in the browser console to see if cookies are accessible. If cookies are displayed, they are vulnerable to theft.

[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]

Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.

====Required Files====

To execute the XSS demonstrations successfully, the following files and scripts are essential:

* Cookie Logger Script (cookie-logger.php): A PHP script hosted on the attacker’s server to log cookies sent by the malicious payload. It listens for a cookies parameter in the URL, extracts its value, and writes it to the stolen-cookies.txt file along with a timestamp.
* Stolen Cookies File (stolen-cookies.txt): A plain text file used to store intercepted cookies. Each entry includes the captured cookie data and the timestamp of when it was received.
* Malicious Script: A custom JavaScript payload crafted to exploit the identified vulnerabilities. This script retrieves cookies using document.cookie and sends them to the attacker’s cookie-logger.php script.

[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]

These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.

====Demonstrations====
=====Stored XSS=====
Stored XSS involves injecting malicious scripts that are permanently stored on the server, such as in a database or a comment field. These scripts execute whenever a victim accesses the vulnerable page. I used the ”Add to your blog” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/Persistent (Second Order) in Mutillidae II.

This is the script we then send to the database to essentally "poison" the website:

[[File:Stored-script.PNG]]

Once this is uploaded one can check if its properly working by visiting this website from another device and also ckecking the stolen-cookies.txt file. If, after visiting the site, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a Stored XSS attack.

=====Reflected XSS Attack=====

Reflected XSS uses a crafted URL that directly includes the malicious payload, which is reflected back in the server's response. This attack relies on tricking the victim into clicking the URL. I used the ”DNS Lookup” found underOWASP 2017/A7 - Cross-Site Scripting (XSS)/Reflected (First Order) in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a ReflectedXSS attack. Note:the second and thrid IP should be the attackers servers IP.

=====DOM based XSS=====

DOM-based XSS manipulates the client-side Document Object Model (DOM) without server interaction. The attack occurs entirely in the victim's browser. I used the ”Password Generator” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/DOM-Based in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a DOM based XSS attack. ote:the second and thrid IP should be the attackers servers IP.

These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.

== XSS attack consequences ==

A Cross-Site Scripting (XSS) attack can have various severe consequences, including:

'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.

'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.

'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.

'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.

'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.

'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.

'''Reputation Damage''': Cross-Site Scripting (XSS) attacks have the potential to damage user confidence in a website or application, particularly in cases where personal information is exposed.
== Prevention==

The prevention of these vulnerabilities is the responsibility of the programmer. Programmers should adopt secure programming practices, such as context-sensitive server-side output encoding, to ensure the prevention of malicious script injections through incorrect or unchecked entries.

Effective prevention measures include:

'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.

'''Output encoding''': Encoding all output data (using HTML entities) is another effective measure to prevent cross-site scripting. This ensures proper display in the user's browser.

'''Content Security Policy (CSP)''': Implementing a Content Security Policy defines rules for the types of content a website can load, contributing to preventing cross-site scripting attacks.

'''Use of tokens''': Employing random character strings (tokens) to identify users can help prevent cross-site scripting attacks, ensuring that only authorized users access the website.

'''Disabling script execution''': While disabling script execution on the server, especially for certain scripting languages like JavaScript or VBScript, can help prevent cross-site scripting, it is rarely used due to the widespread use of JavaScript.

'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.

'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.

'''Security Patching''': Ensuring that all software, including web servers, databases and frameworks, are kept up to date with the latest security patches. Regular updates and patches should be applied to fix known vulnerabilities in the system.

'''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
* https://portswigger.net/web-security/cross-site-scripting
* https://www.sans.org/white-papers/988/
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp

Cross-Site Scripting (XSS)

2024-12-18T17:50:55Z

MVucinic: /* Types */

[[Category:Basic]]
== Cross-Site Scripting (XSS) ==

[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of the application. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The different types are listed below. It is also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
DOM-based Cross-Site Scripting (XSS) is a type of XSS attack that occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks can occur when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is then sent to a user's browser, where it is executed. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

==Demonstrations==

This section demonstrates three Cross-Site Scripting (XSS) attacks using the intentionally vulnerable OWASP Mutillidae II platform. These demonstrations include Stored XSS, Reflected XSS, and DOM-based XSS attacks, showcasing how vulnerabilities can be exploited to steal sensitive information in real-world scenarios. Specifically, these examples focus on stealing the victim's cookies.

If you want to recreate these attacks, refer to this article: OWASP Mutillidae (2021) for detailed instructions on installing and using OWASP Mutillidae II.

===Preparation Steps===
Before demonstrating the attacks, it's essential to understand the groundwork required for successful execution. This includes identifying vulnerabilities, inspecting cookies, and preparing the necessary scripts and files for the exploitation process.

====Searching for Exploits====

Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:

* Analyzing the Page Source: Review the HTML and JavaScript code for insecure functions like innerHTML, document.write, or unescaped user inputs. These functions often process user-supplied data without proper sanitization, creating potential attack vectors.
* Testing Input Fields: Use simple script tags to test input validation. For example, <script>alert("Yooooooo")</script> can reveal whether the application sanitizes or escapes user input. If the alert box appears, it indicates the input field is vulnerable.
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:
* Check the "Application" tab for cookies or local storage.
Inspect server responses and client-side behavior to understand how data flows between them.

[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]

Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.

====Inspecting Cookies====

Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:

* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."
* Check for Security Flags: Look for cookies missing protective flags such as HttpOnly (prevents client-side access), Secure (ensures transmission over HTTPS), or SameSite (restricts third-party context usage).
* Use the Console: Enter document.cookie in the browser console to see if cookies are accessible. If cookies are displayed, they are vulnerable to theft.

[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]

Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.

====Required Files====

To execute the XSS demonstrations successfully, the following files and scripts are essential:

* Cookie Logger Script (cookie-logger.php): A PHP script hosted on the attacker’s server to log cookies sent by the malicious payload. It listens for a cookies parameter in the URL, extracts its value, and writes it to the stolen-cookies.txt file along with a timestamp.
* Stolen Cookies File (stolen-cookies.txt): A plain text file used to store intercepted cookies. Each entry includes the captured cookie data and the timestamp of when it was received.
* Malicious Script: A custom JavaScript payload crafted to exploit the identified vulnerabilities. This script retrieves cookies using document.cookie and sends them to the attacker’s cookie-logger.php script.

[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]

These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.

====Demonstrations====
=====Stored XSS=====
Stored XSS involves injecting malicious scripts that are permanently stored on the server, such as in a database or a comment field. These scripts execute whenever a victim accesses the vulnerable page. I used the ”Add to your blog” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/Persistent (Second Order) in Mutillidae II.

This is the script we then send to the database to essentally "poison" the website:

[[File:Stored-script.PNG]]

Once this is uploaded one can check if its properly working by visiting this website from another device and also ckecking the stolen-cookies.txt file. If, after visiting the site, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a Stored XSS attack.

=====Reflected XSS Attack=====

Reflected XSS uses a crafted URL that directly includes the malicious payload, which is reflected back in the server's response. This attack relies on tricking the victim into clicking the URL. I used the ”DNS Lookup” found underOWASP 2017/A7 - Cross-Site Scripting (XSS)/Reflected (First Order) in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a ReflectedXSS attack. Note:the second and thrid IP should be the attackers servers IP

=====DOM based XSS=====

DOM-based XSS manipulates the client-side Document Object Model (DOM) without server interaction. The attack occurs entirely in the victim's browser. I used the ”Password Generator” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/DOM-Based in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a DOM based XSS attack. ote:the second and thrid IP should be the attackers servers IP.

These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.

== XSS attack consequences ==

A Cross-Site Scripting (XSS) attack can have various severe consequences, including:

'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.

'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.

'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.

'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.

'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.

'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.

'''Reputation Damage''': Cross-Site Scripting (XSS) attacks have the potential to damage user confidence in a website or application, particularly in cases where personal information is exposed.
== Prevention==

The prevention of these vulnerabilities is the responsibility of the programmer. Programmers should adopt secure programming practices, such as context-sensitive server-side output encoding, to ensure the prevention of malicious script injections through incorrect or unchecked entries.

Effective prevention measures include:

'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.

'''Output encoding''': Encoding all output data (using HTML entities) is another effective measure to prevent cross-site scripting. This ensures proper display in the user's browser.

'''Content Security Policy (CSP)''': Implementing a Content Security Policy defines rules for the types of content a website can load, contributing to preventing cross-site scripting attacks.

'''Use of tokens''': Employing random character strings (tokens) to identify users can help prevent cross-site scripting attacks, ensuring that only authorized users access the website.

'''Disabling script execution''': While disabling script execution on the server, especially for certain scripting languages like JavaScript or VBScript, can help prevent cross-site scripting, it is rarely used due to the widespread use of JavaScript.

'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.

'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.

'''Security Patching''': Ensuring that all software, including web servers, databases and frameworks, are kept up to date with the latest security patches. Regular updates and patches should be applied to fix known vulnerabilities in the system.

'''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
* https://portswigger.net/web-security/cross-site-scripting
* https://www.sans.org/white-papers/988/
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp

OWASP Mutillidae (2021)

2024-12-18T17:42:41Z

MVucinic: /* References */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===
This section provides a detailed installation guide for OWASP Mutillidae II. The only prerequisite for this guide is a functioning Ubuntu server (or a similar Linux-based environment).

====Apache Webserver====

The first thing to install is the Apache Webserver. Run the following command:

* ''sudo apt install apache2 -y''

After installation, allow URL Rewrites:

* ''sudo a2enmod rewrite''

Restart the Apache server:

* ''sudo systemctl restart apache2''

Next, edit the apache2.conf file to enable AllowOverride All:.

* ''sudo nano /etc/apache2/apache2.conf''

[[File:Conf-file.PNG]]

Afterwards restart the server again and with http://ip-address-of-your-server this page should be seen.

[[File:Apache2-page.PNG]]
====PHP====

If the Apache2 page is visible, Apache has been successfully installed. Now, install PHP with this command:

* ''sudo apt install php libapache2-mod-php -y''

To test PHP, create an index.php file:

* ''sudo nano /var/www/html/index.php''

Add the following content:

* ''<?php echo "Hello, PHP!"; ?>''

Save the file and visit http://ip-address-of-your-server/index.php. You should see this result:

[[file:Index-php.PNG]]
====MySQL Server====

Next, install the MySQL Server and the PHP-MySQL plugin with this command:

* ''sudo apt install mysql-server php-mysql -y''
====Change root password====

Mutillidae II uses the root user with the password mutillidae. To ensure it works properly, set the root password as follows:

1) Access the MySQL database as root:
* ''sudo mysql -u root''

2) Once on it use this command to make changes in the database:

* ''sudo mysql;''

3) In the MySQL shell, update the root password:

* ''ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mutillidae';''

Once done, flush the old privilages with:

* ''FLUSH PRIVILEGES;''

Then write EXIT; to exit the database.
====PHP Libraries====

With these steps done, we can now go and install the three PHP libraries. The first one will be the PHP XML Library.
Run these commands:

This in order to know which PHP Verion one has:
* ''php --version (to now which version of PHP one has)''

After having figured out whcih version of PHP is installed run this:
* ''sudo apt-get install php8.1-xml'' (my verison is 8.1, yours could be different)

After the XML Library, the Curl Library will be installed next:

* ''sudo apt-get install php8.1-curl''

The last Library will be the mbstring Library.

* ''sudo apt-get install php8.1-mbstring''

====Git====

Install Git to download the OWASP Mutillidae II repository:

* ''sudo apt install git -y''

====Final step====

Finally, install OWASP Mutillidae II:

1) Move to the Apache webserver folder:

* ''cd /var/www/html''

2) Clone the repository:

* ''sudo git clone https://github.com/webpwnized/mutillidae.git''

After its done cloning, visit http://ip-address-of-your-server/mutillidae/src. There, if everythin worked, you should be greeted by this site:

[[file:Owasp-page.PNG]]

On the page, press Reset DB. If everything worked correctly, the installation is successful.

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae.git
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

File:Decoded-dom-based.PNG

2024-12-18T17:37:00Z

MVucinic:

File:Dom-xss-coded.PNG

2024-12-18T17:36:44Z

MVucinic:

File:Decoded-reflected.PNG

2024-12-18T17:30:10Z

MVucinic:

File:Coded-reflected.PNG

2024-12-18T17:29:25Z

MVucinic:

File:Stored-script.PNG

2024-12-18T17:21:35Z

MVucinic:

File:Stolen-cookies.PNG

2024-12-18T16:38:48Z

MVucinic:

File:Php-script.PNG

2024-12-18T16:37:28Z

MVucinic:

File:Test-script.PNG

2024-12-18T16:34:22Z

MVucinic:

File:Innerhtml.PNG

2024-12-18T16:30:18Z

MVucinic:

File:Httponly-no.PNG

2024-12-18T16:28:54Z

MVucinic:

File:Document-cookies.PNG

2024-12-18T16:28:02Z

MVucinic: MVucinic uploaded a new version of File:Document-cookies.PNG

File:Document-cookies.PNG

2024-12-18T16:26:37Z

MVucinic:

OWASP Mutillidae (2021)

2024-12-18T15:52:22Z

MVucinic: /* Installing Mutillidae */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===
This section provides a detailed installation guide for OWASP Mutillidae II. The only prerequisite for this guide is a functioning Ubuntu server (or a similar Linux-based environment).

====Apache Webserver====

The first thing to install is the Apache Webserver. Run the following command:

* ''sudo apt install apache2 -y''

After installation, allow URL Rewrites:

* ''sudo a2enmod rewrite''

Restart the Apache server:

* ''sudo systemctl restart apache2''

Next, edit the apache2.conf file to enable AllowOverride All:.

* ''sudo nano /etc/apache2/apache2.conf''

[[File:Conf-file.PNG]]

Afterwards restart the server again and with http://ip-address-of-your-server this page should be seen.

[[File:Apache2-page.PNG]]
====PHP====

If the Apache2 page is visible, Apache has been successfully installed. Now, install PHP with this command:

* ''sudo apt install php libapache2-mod-php -y''

To test PHP, create an index.php file:

* ''sudo nano /var/www/html/index.php''

Add the following content:

* ''<?php echo "Hello, PHP!"; ?>''

Save the file and visit http://ip-address-of-your-server/index.php. You should see this result:

[[file:Index-php.PNG]]
====MySQL Server====

Next, install the MySQL Server and the PHP-MySQL plugin with this command:

* ''sudo apt install mysql-server php-mysql -y''
====Change root password====

Mutillidae II uses the root user with the password mutillidae. To ensure it works properly, set the root password as follows:

1) Access the MySQL database as root:
* ''sudo mysql -u root''

2) Once on it use this command to make changes in the database:

* ''sudo mysql;''

3) In the MySQL shell, update the root password:

* ''ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mutillidae';''

Once done, flush the old privilages with:

* ''FLUSH PRIVILEGES;''

Then write EXIT; to exit the database.
====PHP Libraries====

With these steps done, we can now go and install the three PHP libraries. The first one will be the PHP XML Library.
Run these commands:

This in order to know which PHP Verion one has:
* ''php --version (to now which version of PHP one has)''

After having figured out whcih version of PHP is installed run this:
* ''sudo apt-get install php8.1-xml'' (my verison is 8.1, yours could be different)

After the XML Library, the Curl Library will be installed next:

* ''sudo apt-get install php8.1-curl''

The last Library will be the mbstring Library.

* ''sudo apt-get install php8.1-mbstring''

====Git====

Install Git to download the OWASP Mutillidae II repository:

* ''sudo apt install git -y''

====Final step====

Finally, install OWASP Mutillidae II:

1) Move to the Apache webserver folder:

* ''cd /var/www/html''

2) Clone the repository:

* ''sudo git clone https://github.com/webpwnized/mutillidae.git''

After its done cloning, visit http://ip-address-of-your-server/mutillidae/src. There, if everythin worked, you should be greeted by this site:

[[file:Owasp-page.PNG]]

On the page, press Reset DB. If everything worked correctly, the installation is successful.

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

OWASP Mutillidae (2021)

2024-12-18T15:52:10Z

MVucinic: /* Installing Mutillidae */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===
This document provides a detailed installation guide for OWASP Mutillidae II. The only prerequisite for this guide is a functioning Ubuntu server (or a similar Linux-based environment).

====Apache Webserver====

The first thing to install is the Apache Webserver. Run the following command:

* ''sudo apt install apache2 -y''

After installation, allow URL Rewrites:

* ''sudo a2enmod rewrite''

Restart the Apache server:

* ''sudo systemctl restart apache2''

Next, edit the apache2.conf file to enable AllowOverride All:.

* ''sudo nano /etc/apache2/apache2.conf''

[[File:Conf-file.PNG]]

Afterwards restart the server again and with http://ip-address-of-your-server this page should be seen.

[[File:Apache2-page.PNG]]
====PHP====

If the Apache2 page is visible, Apache has been successfully installed. Now, install PHP with this command:

* ''sudo apt install php libapache2-mod-php -y''

To test PHP, create an index.php file:

* ''sudo nano /var/www/html/index.php''

Add the following content:

* ''<?php echo "Hello, PHP!"; ?>''

Save the file and visit http://ip-address-of-your-server/index.php. You should see this result:

[[file:Index-php.PNG]]
====MySQL Server====

Next, install the MySQL Server and the PHP-MySQL plugin with this command:

* ''sudo apt install mysql-server php-mysql -y''
====Change root password====

Mutillidae II uses the root user with the password mutillidae. To ensure it works properly, set the root password as follows:

1) Access the MySQL database as root:
* ''sudo mysql -u root''

2) Once on it use this command to make changes in the database:

* ''sudo mysql;''

3) In the MySQL shell, update the root password:

* ''ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mutillidae';''

Once done, flush the old privilages with:

* ''FLUSH PRIVILEGES;''

Then write EXIT; to exit the database.
====PHP Libraries====

With these steps done, we can now go and install the three PHP libraries. The first one will be the PHP XML Library.
Run these commands:

This in order to know which PHP Verion one has:
* ''php --version (to now which version of PHP one has)''

After having figured out whcih version of PHP is installed run this:
* ''sudo apt-get install php8.1-xml'' (my verison is 8.1, yours could be different)

After the XML Library, the Curl Library will be installed next:

* ''sudo apt-get install php8.1-curl''

The last Library will be the mbstring Library.

* ''sudo apt-get install php8.1-mbstring''

====Git====

Install Git to download the OWASP Mutillidae II repository:

* ''sudo apt install git -y''

====Final step====

Finally, install OWASP Mutillidae II:

1) Move to the Apache webserver folder:

* ''cd /var/www/html''

2) Clone the repository:

* ''sudo git clone https://github.com/webpwnized/mutillidae.git''

After its done cloning, visit http://ip-address-of-your-server/mutillidae/src. There, if everythin worked, you should be greeted by this site:

[[file:Owasp-page.PNG]]

On the page, press Reset DB. If everything worked correctly, the installation is successful.

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

OWASP Mutillidae (2021)

2024-12-17T21:25:18Z

MVucinic: /* Installation */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===
====Apache Webserver====

The first thing to install is the Apache Webserver. Run the following command:

* ''sudo apt install apache2 -y''

After installation, allow URL Rewrites:

* ''sudo a2enmod rewrite''

Restart the Apache server:

* ''sudo systemctl restart apache2''

Next, edit the apache2.conf file to enable AllowOverride All:.

* ''sudo nano /etc/apache2/apache2.conf''

[[File:Conf-file.PNG]]

Afterwards restart the server again and with http://ip-address-of-your-server this page should be seen.

[[File:Apache2-page.PNG]]
====PHP====

If the Apache2 page is visible, Apache has been successfully installed. Now, install PHP with this command:

* ''sudo apt install php libapache2-mod-php -y''

To test PHP, create an index.php file:

* ''sudo nano /var/www/html/index.php''

Add the following content:

* ''<?php echo "Hello, PHP!"; ?>''

Save the file and visit http://ip-address-of-your-server/index.php. You should see this result:

[[file:Index-php.PNG]]
====MySQL Server====

Next, install the MySQL Server and the PHP-MySQL plugin with this command:

* ''sudo apt install mysql-server php-mysql -y''
====Change root password====

Mutillidae II uses the root user with the password mutillidae. To ensure it works properly, set the root password as follows:

1) Access the MySQL database as root:
* ''sudo mysql -u root''

2) Once on it use this command to make changes in the database:

* ''sudo mysql;''

3) In the MySQL shell, update the root password:

* ''ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mutillidae';''

Once done, flush the old privilages with:

* ''FLUSH PRIVILEGES;''

Then write EXIT; to exit the database.
====PHP Libraries====

With these steps done, we can now go and install the three PHP libraries. The first one will be the PHP XML Library.
Run these commands:

This in order to know which PHP Verion one has:
* ''php --version (to now which version of PHP one has)''

After having figured out whcih version of PHP is installed run this:
* ''sudo apt-get install php8.1-xml'' (my verison is 8.1, yours could be different)

After the XML Library, the Curl Library will be installed next:

* ''sudo apt-get install php8.1-curl''

The last Library will be the mbstring Library.

* ''sudo apt-get install php8.1-mbstring''

====Git====

Install Git to download the OWASP Mutillidae II repository:

* ''sudo apt install git -y''

====Final step====

Finally, install OWASP Mutillidae II:

1) Move to the Apache webserver folder:

* ''cd /var/www/html''

2) Clone the repository:

* ''sudo git clone https://github.com/webpwnized/mutillidae.git''

After its done cloning, visit http://ip-address-of-your-server/mutillidae/src. There, if everythin worked, you should be greeted by this site:

[[file:Owasp-page.PNG]]

On the page, press Reset DB. If everything worked correctly, the installation is successful.

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

File:Owasp-page.PNG

2024-12-17T21:00:59Z

MVucinic:

OWASP Mutillidae (2021)

2024-12-17T20:51:32Z

MVucinic: /* Installation */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===

The first thing that will be installed, is an Apache Webserver. In oder to do that, run this command:

* sudo apt install apache2 -y

Afterwards run this command, in order to allow URL_Rewrites.

* sudo a2enmod rewrite

Restart the server then.

* sudo systemctl restart apache2

After the restart, go into the apache2.conf and search the <Directory>. When found, change the AllowOverride None -> AllowOverride All.

* sudo nano /etc/apache2/apache2.conf

[[File:Conf-file.PNG]]

Afterwards restart the server and with http://ip-address-of-your-server this page should be seen.

[[File:Apache2-page.PNG]]

If this page comes up, Apache2 has been succsesfully installed. Now PHP needs to be installed with this:

* sudo apt install php libapache2-mod-php -y

Now we can edit the index.php file and can now write something like this:

* sudo nano /var/www/html/index.php

* <?php echo "Hello, PHP!"; ?>

After saving this file and going onto this site http://ip-address-of-your-server/index.php we are greeted with this.

[[file:Index-php.PNG]]

With this out of the way, the next step will be the installation of the MySQL Server. Use this command to install the datasbase and also install the php plugin at the same time.

* sudo apt install mysql-server php-mysql -y

After installing it we need to change the password of root. The reason why we have to do that is, because Mutillidae II uses the root user with the password "mutillidae". If we dont change that, Mutillidae II wont work properly.
Use this command in oder to access the database as root:

* sudo mysql -u root

Once on it use this command to make changes in the database:

* sudo mysql

Afterwards run this command to cahnge the password:

* ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mutillidae';
FLUSH PRIVILEGES;

Once done, flush the old privilages with:

* FLUSH PRIVILEGES;

Then write EXIT; to exit the database.

With these steps done, we can now go and install the three PHP libraries. The first one will be the PHP XML Library.
Run these commands:

* php --version (to now which version of PHP one has)

* sudo apt-get install php8.1-xml (my verison is 8.1, yours could be different)

After the XML Library, the Curl Library will be installed next:

* sudo apt-get install php8.1-curl

The last Library will be the mbstring Library.

* sudo apt-get install php8.1-mbstring

====test====
a

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

File:Index-php.PNG

2024-12-17T20:33:20Z

MVucinic:

File:Conf-file.PNG

2024-12-17T20:25:26Z

MVucinic: MVucinic uploaded a new version of File:Conf-file.PNG

File:Apache2-page.PNG

2024-12-17T20:22:20Z

MVucinic:

OWASP Mutillidae (2021)

2024-12-17T20:20:37Z

MVucinic: /* Installation */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

test
* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===

The first thing that will be installed, is an Apache Webserver. In oder to do that, run this command:

* sudo apt install apache2 -y

Afterwards run this command, in order to allow URL_Rewrites.

* sudo a2enmod rewrite

Restart the server then.

* sudo systemctl restart apache2

After the restart, go into the apache2.conf and search the <Directory>. When found, change the AllowOverride None -> AllowOverride All.

* sudo nano /etc/apache2/apache2.conf

[[File:Conf-file.PNG]]

Afterwards restart the server and with http://ip-address-of-your-server this page should be seen.

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

OWASP Mutillidae (2021)

2024-12-17T20:17:54Z

MVucinic: /* Installation */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

test
* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===

The first thing that will be installed, is an Apache Webserver. In oder to do that, run this command:

* sudo apt install apache2 -y

Afterwards run this command, in order to allow URL_Rewrites.

* sudo a2enmod rewrite

Restart the server then.

* sudo systemctl restart apache2

After the restart, go into the apache2.conf and search the <Directory>. When found, change the AllowOverride None -> AllowOverride All.

* sudo nano /etc/apache2/apache2.conf

[[File:Conf-file.PNG]]

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]

File:Conf-file.PNG

2024-12-17T20:16:20Z

MVucinic:

OWASP Mutillidae (2021)

2024-12-17T20:14:57Z

MVucinic: /* Installation */

== Summary ==

OWASP Mutillidae is a free open source tool created for Pentesting of Web Applications. It is a "Vulnerable Web Application" that offers a Platform where the provided Exploits and Security flaws can be executed within a local environment. With over 40 different vulnerabilities and related training challenges, it provides a platform that shows the most common flaws of the last 15 years of web development. The main goal is to to offer security training for a wide range of uses, from teaching in classrooms to security enthusiasts exploring to functioning as testing ground for vulnerability assessment targets. The vulnerabilities shown in the program are actual vulnerabilities within the application, so the application should only be run in a protected environment - such as a virtual machine. Most of the Vulnerabilities are structured around the OWASP Top Ten List[https://wiki.elvis.science/index.php?title=Thread_Modelling#Top_10_Web_Application_Security_Risks]. The current Version Mutillidae II was created by Jeremy Druin [https://www.youtube.com/c/webpwnized/featured] (pseudonym: webpwnized), who also created the Tutorials for the Challanges and Installation Guides.

== How it Operates ==

Every Vulnerability contained in the application is build in within a Webpage. By selecting the Exploit from a List (e.g. Authentication Bypass) a site with the corresponding explotable Webpage is loaded and ready to get "hacked". Since everything run at your local machine you can not harm anyone. The data such as "User Data" are stored in a Database which you set up when you install the Application (see Installation for more Information).

[[File:Muti-Dropdown.png]]

== A1 SQL Injection Example ==
[[SQL_Injection]]-> SQLi Extract Data

Now here is a short example how one vulnerability exploit could look like. In this case there is a query where user can request their userinformation by providing their credentials.

[[File:Mutillidae-login.png]]

Normally the query should only retrun only on record when correct credentials are entered.

But this website is totally unsecure so we can easily rewrite the SQL query to give us a list of every user in the database. But how can we do this?

===Step 1:===
get an Exception by typing in invalid characters such as (', #, --)

[[File:Mutillidae-Exception.png]]

===Step 2:===

Since we got an error message with the syntax how the sql statement is written we can alter the statement by simply put another statement in the form.

In this case i wrote ’OR 1# in the username fields to alter the query which should be now

SELECT * FROM acccounts where username= ’ ’OR 1# AND password = ’’

1 means true in SQL language and # is a comment so it ignores the password query. So our SQL String says now that it should gives as all datasets for which the condition is true which lead to following output:

[[File:Mutillidae-Extract-Data.png]]

== A5 Cross-Site-Request Forgery Example ==
[[Cross-Site-Request_Forgery_(CSRF)]]-> Cross-Site-Request Forgery
This example can be found in the A5 section from the Owasp Top 10 examples, which is called 'Add to your blog'.
Here we simulating an attack to vote for a security tool but without actually voting for it.
In the screenshot below you can see the site which we are attacking. So this site is basically the good site.

[[File:UserPoll.PNG]]

The evil site is in this case the 'Add to your blog' site. Users can save a blog to a blog table. An attacker can you use this mechanism to manipulate a blog to fire an action.
Instead of a normal blog you can also add a script to the blog table. This script calls a method when you hover over the blog and it redirects to the voting site and votes for a security tool.

[[File:Blogs.PNG]]

The script can be found on the official github website for Mutillidae https://github.com/webpwnized/mutillidae/blob/master/src/labs/lab-files/cross-site-request-forgery-lab-files/vote-for-nmap-onmouseover-csrf.txt
This script creates a form object in the background and sets some specific fields. Those fields are being sent over the URL to the voting site.
Because how the site is constructed, it reads the parameter from the url to decide which security tool should be voted. This means that the form object consists of some input fields and those input fields contain some values.
One input field is responsible for redirecting to the voting site. The other one is setting the value for security tool. A form also should have a submit button which is also set with the input fields.
This whole script is contained in a method. This method gets fired when you hover over the mouse. You basically save a html tag with the name of the blog but this html tag calls the method which is containing the malicious script.

== Features ==

* over 40 vulnerabilities (OWASP Top Ten 2007, 2010, 2013 and 2017[https://owasp.org/www-project-top-ten/])
* Actually Vulnerable
* Simple Intallation and Maintaining
* User can switch between 3 security levels (no security, Client-side Security, Server-side Security)
* Used in web security courses
* Tutorials and Guides included in Application
* Updated frequently

== Interface ==
[[File:Mutillidae-Interface.png]]

By clicking on any Item on the right dropdown menu, you can select any of the OWASP Top Ten Challanges from the last 15 years.

* Hints and Videos - leads you directly to a structured guide how the exercise could be completed.
* Toggle Security - you can choose between 3 Security levels for each exercise
* Reset DB - Clear all user Data
* Labs - Study Questions associated with the Exercises

== Examples of Vulnerabilities ==

* SQL Injections (SQLi)[https://wiki.elvis.science/index.php?title=SQL_Injection]
* Cross-Site-Scripting [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)]
* Sensitive Data Exposure
* other Injection (CSS, HTML, JavaScript)
* and many more...

== Comparable Vulnerable Web Applications ==

* WebGoat [https://wiki.elvis.science/index.php?title=WebGoat]
* bWAPP [https://wiki.elvis.science/index.php?title=BWAPP]

== Requirements ==

* Apache Webserver
* Database (MySQL/MariaDb)
* Packages: Sourcecode from git (https://github.com/webpwnized/mutillidae)

== Installation ==

test
* Install Apache Webserver on your local Machine
* Install PHP on your local Machine
* Install a supported Database (e.g. MySQL, MariaDB) (This installationguide will cover MySQL)
* Install three PHP Libraries (php-xml, php-curl, php-mbstring)
* Install Git

If you have a XAMPP/LAMPP stack set up aleady, you might skip directly to installing Mutillidae. Alternativly you can also use a docker build to run Mutillidae.
There is a Videoseries from the creator which gives a Step-by-Step video tutorialfor the installation.

=== Installing Mutillidae ===

The first thing that will be installed, is an Apache Webserver. In oder to do that, run this command:

* sudo apt install apache2 -y

Afterwards run this command, in order to allow URL_Rewrites.

* sudo a2enmod rewrite

Restart the server then.

* sudo systemctl restart apache2

After the restart, go into the apache2.conf and search the <Directory>. When found, change the AllowOverride None -> AllowOverride All.

* sudo nano /etc/apache2/apache2.conf

=== Installing Mutillidae with Metasploit ===
A different method for installing Mutillidae is to install Metasploit. Metasploit is a penetration testing software which inlcudes everything you need to set up and run Mutillidae.
This means that you don't have to install all the other components you need for example a database, because Metasploit is doing this for.
After installing you can use the credentials msfadmin for the username and password in order to login into Metasploit.
When Metasploit is running Mutillidae is also accessible and for that you use the ip address of the machine where Metasploit is running on.
To look up the ip address you can use the 'ip a' command in the CLI to find the ip address.
Sometimes it happens that Mutillidae cannot access the database. This problem occurs when the database name in the config file is not set.
To fix this problem you have to navigate to this config file which is found in this destination '/var/www/mutillidae/config.inc'.
In this config file you change the value of the variable called '$dbname' to 'owasp10'. After this configuration Mutillidae can access the database.

[[File:Config.PNG]]

== References ==

* https://owasp.org/www-project-top-ten/
* https://github.com/webpwnized/mutillidae
* https://www.youtube.com/c/webpwnized/featured
* https://github.com/webpwnized/mutillidae/blob/master/README-INSTALLATION.md Step-by-Step video tutorial

Internal Links
* https://wiki.elvis.science/index.php?title=SQL_Injection
* https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS)
* https://wiki.elvis.science/index.php?title=SQL_Injection_Examples_on_Known_Vulnerable_Web_Applications

[[Category:Documentation]]