https://elvis.hcw.ac.at/wiki/api.php?action=feedcontributions&feedformat=atom&user=KKerblElvis Wiki - User contributions [en]2026-09-10T18:07:36ZUser contributionsMediaWiki 1.41.5https://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17802Cross-Site Request Forgery (CSRF)2024-12-21T14:25:07Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.<br />
<br />
For a CSRF example, visit [https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net CSRF Practical Example]<br />
<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
=== SameSite Cookies ===<br />
<br />
SameSite halp against CSRF attacks by controling whether cookies should be included in requests that originate from different domains, helping prevent unauthorized actions performed on behalf of an authenticated user.<br />
<br />
When a cookie is set with the SameSite=Strict attribute:<br />
<br />
The cookie is only sent with requests originating from the same site where it was initially set.<br />
Cross-origin requests (requests coming from a different domain) will not include these cookies, even if the user is authenticated.<br />
This behavior ensures that CSRF attacks relying on cross-origin requests to exploit authentication cookies are effectively blocked.<br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17801Cross-Site Request Forgery (CSRF)2024-12-21T14:18:47Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.<br />
<br />
For a CSRF example, visit [https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net CSRF Practical Example]<br />
<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17800Cross-Site Request Forgery (CSRF)2024-12-21T14:17:48Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.<br />
<br />
For a CSRF example, visit [CSRF Practical Example](https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net)<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17799Cross-Site Request Forgery (CSRF)2024-12-21T14:15:56Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.<br />
<br />
For a CSRF example, visit this link: https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17798Cross-Site Request Forgery (CSRF)2024-12-21T14:15:23Z<p>KKerbl: /* Cross-Site-Request Forgery (CSRF) */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.<br />
<br />
For a CSRF example, visit this link: CSRF Example<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17797Cross-Site Request Forgery (CSRF)2024-12-21T14:13:40Z<p>KKerbl: /* Cross-Site-Request Forgery (CSRF) */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=17796Cross-Site Request Forgery (CSRF)2024-12-21T14:09:45Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site-Request Forgery (CSRF) ==<br />
<br />
Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.<br />
<br />
A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.<br />
<br />
The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.<br />
<br />
<br />
== File Inclusion ==<br />
===Local File Inclusion (LFI)===<br />
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.<br />
===Remote File Inclusion (RFI)===<br />
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.<br />
<br />
== Prevention ==<br />
<br />
===CSRF Token===<br />
<br />
To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.<br />
<br />
To prevent CSRF, each input page should contain a CSRF token. The token should be unpredictable, secret and unique for each session, or better for each form, and <br />
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.<br />
<br />
* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying. <br />
<br />
Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks. <br />
<br />
===Same-Origin Policy===<br />
<br />
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/csrf<br />
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET<br />
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17795Cross-Site Scripting (XSS)2024-12-21T14:02:36Z<p>KKerbl: /* Client XSS */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location (e.g., database). Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS happens when untrusted data is used directly to manipulate the DOM (Document Object Model) via unsafe JavaScript methods on the client side.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17794Cross-Site Scripting (XSS)2024-12-21T14:02:02Z<p>KKerbl: /* Server XSS */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location (e.g., database). Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17793Cross-Site Scripting (XSS)2024-12-21T13:58:33Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17792Cross-Site Scripting (XSS)2024-12-21T13:56:55Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17791Cross-Site Scripting (XSS)2024-12-21T13:56:14Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17790Cross-Site Scripting (XSS)2024-12-21T13:53:28Z<p>KKerbl: /* References */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/Types_of_Cross-Site_Scripting<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17789Cross-Site Scripting (XSS)2024-12-21T13:53:06Z<p>KKerbl: /* Types */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
=== Server XSS ===<br />
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.<br />
<br />
=== Client XSS ===<br />
Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17788Cross-Site Scripting (XSS)2024-12-21T13:47:14Z<p>KKerbl: </p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17787Cross-Site Scripting (XSS)2024-12-21T13:41:23Z<p>KKerbl: /* Types */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS (Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS (Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS (Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is like reelected XSS most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17786Cross-Site Scripting (XSS)2024-12-21T13:41:06Z<p>KKerbl: /* Types */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
<br />
=== Reflected XSS(Type I) ===<br />
Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. <br />
<br />
=== Stored XSS(Type II) ===<br />
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.<br />
<br />
=== DOM Based XSS(Type 0) ===<br />
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is like reelected XSS most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerblhttps://elvis.hcw.ac.at/wiki/index.php?title=Cross-Site_Scripting_(XSS)&diff=17785Cross-Site Scripting (XSS)2024-12-21T13:17:05Z<p>KKerbl: /* Cross-Site Scripting (XSS) */</p>
<hr />
<div>[[Category:Basic]]<br />
== Cross-Site Scripting (XSS) ==<br />
<br />
[[Image:xss_diagram.png|300px|thumb| The operational principle of Cross-Site Scripting (XSS)]]<br />
<br />
<br />
Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.<br />
<br />
== Types ==<br />
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.<br />
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]<br />
<br />
=== Stored (Type I) ===<br />
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.<br />
<br />
=== Reflected (Type II) ===<br />
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. <br />
<br />
=== DOM Based (Type 0) ===<br />
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.<br />
<br />
==Demonstrations==<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Preparation Steps=== <br />
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.<br />
<br />
====Searching for Exploits====<br />
<br />
Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:<br />
<br />
* 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.<br />
* 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.<br />
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:<br />
* Check the "Application" tab for cookies or local storage.<br />
Inspect server responses and client-side behavior to understand how data flows between them.<br />
<br />
[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]<br />
<br />
Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.<br />
<br />
====Inspecting Cookies====<br />
<br />
Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:<br />
<br />
* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."<br />
* 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).<br />
* 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.<br />
<br />
[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]<br />
<br />
Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.<br />
<br />
====Required Files====<br />
<br />
To execute the XSS demonstrations successfully, the following files and scripts are essential:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
[[File:Php-script.PNG]] [[File:Stolen-cookies.PNG]]<br />
<br />
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.<br />
<br />
====Demonstrations====<br />
=====Stored XSS=====<br />
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.<br />
<br />
This is the script we then send to the database to essentally "poison" the website:<br />
<br />
[[File:Stored-script.PNG]]<br />
<br />
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.<br />
<br />
=====Reflected XSS Attack=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]<br />
<br />
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.<br />
<br />
=====DOM based XSS=====<br />
<br />
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.<br />
<br />
This is the manipulated URL that one has to send(coded and decoded):<br />
<br />
[[File: Dom-xss-coded.PNG]] [[File:Decoded-dom-based.PNG]]<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== XSS attack consequences ==<br />
<br />
A Cross-Site Scripting (XSS) attack can have various severe consequences, including:<br />
<br />
'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.<br />
<br />
'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.<br />
<br />
'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.<br />
<br />
'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.<br />
<br />
'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.<br />
<br />
'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.<br />
<br />
'''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.<br />
== Prevention==<br />
<br />
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.<br />
<br />
<br />
<br />
Effective prevention measures include:<br />
<br />
'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.<br />
<br />
'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
== References ==<br />
<br />
* https://owasp.org/www-community/attacks/xss/<br />
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html<br />
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)<br />
* https://portswigger.net/web-security/cross-site-scripting<br />
* https://www.sans.org/white-papers/988/<br />
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0<br />
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp<br />
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)</div>KKerbl