Severity: High

Confidence: Certain

Host: https://vulnerable-site.azurewebsites.net

Path: /Xss/Add


Issue Detail
The value of the message request parameter is copied into the HTML document as plain text between tags. The payload yqcnk<script>alert(1)</script>wi5jw was submitted in the message parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.

Issue Background
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site that causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).

The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain that can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk. 


Issue Remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting
attacks can be prevented using two layers of defenses:



- Input should be validated as strictly as possible on arrival, given the kind of content that
it is expected to contain. For example, personal names should consist of alphabetical
and a small range of typographical characters, and be relatively short; a year of birth
should consist of exactly four numerals; email addresses should match a well-defined
regular expression. Input which fails the validation should be rejected, not sanitized.

- User input should be HTML-encoded at any point where it is copied into
application responses. All HTML metacharacters, including < > " ' and =, should be
replaced with the corresponding HTML entities (&lt; &gt; etc).

In cases where the application's functionality allows users to author content using
a restricted subset of HTML tags and attributes (for example, blog comments which
allow limited formatting and linking), it is necessary to parse the supplied HTML to
validate that it does not use any dangerous syntax; this is a non-trivial task.


Evidence
Request:
POST /Xss/Add HTTP/1.1
Host: vulnerable-site.azurewebsites.net
Accept-Encoding: gzip, deflate, br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36
Connection: close
Cache-Control: max-age=0
Cookie: ARRAffinity=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ARRAffinitySameSite=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ai_user=q4Z4s43cdBVPrM6He4fsvm|2024-07-29T19:38:33.867Z; ai_session=R1h2Gldt0rc5sWrB2M5lR7|1722281913984|1722281914890
Origin: https://vulnerable-site.azurewebsites.net
Upgrade-Insecure-Requests: 1
Referer: https://vulnerable-site.azurewebsites.net/Xss
Content-Type: application/x-www-form-urlencoded
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="126", "Chromium";v="126"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 14

message=mmROsvyqcnk%3cscript%3ealert(1)%3c%2fscript%3ewi5jw

Response:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html; charset=utf-8
Date: Mon, 29 Jul 2024 19:38:41 GMT
Server: Microsoft-IIS/10.0
Vary: Accept-Encoding
Strict-Transport-Security: max-age=2592000
Request-Context: appId=cid-v1:db2dc125-2ce4-4691-9701-850cfa4f1565
X-Powered-By: ASP.NET
Content-Length: 7372

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<title>XSS | Vulnerable Site</title>
<link rel="Snip<div>mmROsvyqcnk<script>alert(1)</script>wi5jw</div>Snip



References
	
- Web Security Academy: Cross-site scripting (https://portswigger.net/web-security/cross-site-scripting)

- Web Security Academy: Reflected cross-site scripting (https://portswigger.net/web-security/cross-site-scripting/reflected)

- Using Burp to Find XSS issues (https://support.portswigger.net/customer/portal/articles/1965737-Methodology_XSS.html)



Vulnerability Classifications

- CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (https://cwe.mitre.org/data/definitions/79.html)

- CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) (https://cwe.mitre.org/data/definitions/80.html)

- CWE-116: Improper Encoding or Escaping of Output (https://cwe.mitre.org/data/definitions/116.html)

- CWE-159: Failure to Sanitize Special Element (https://cwe.mitre.org/data/definitions/159.html)

- CAPEC-591: Reflected XSS (https://capec.mitre.org/data/definitions/591.html)



Reported by Dastardly: https://portswigger.net/burp/dastardly/scan-checks

Severity: Info

Confidence: Certain

Host: https://vulnerable-site.azurewebsites.net

Path: /Cors


Issue Detail
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain.

The application allowed access from the requested origin https://npmyhhymesqu.com

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue Background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site  specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to  bypass any IP-based access controls by proxying through users'  browsers.


Issue Remediation
Rather than using a wildcard or programmatically verifying supplied origins, use a whitelist of trusted domains.


Evidence
Request:
GET /Cors HTTP/1.1
Host: vulnerable-site.azurewebsites.net
Accept-Encoding: gzip, deflate, br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36
Connection: close
Cache-Control: max-age=0
Cookie: ARRAffinity=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ARRAffinitySameSite=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ai_user=QkAu6QF/OHfFeZfSl61QQN|2024-07-29T19:38:34.222Z; ai_session=HY1wBJCLHifUneoKC7fEUc|1722281914369|1722281914369
Upgrade-Insecure-Requests: 1
Referer: https://vulnerable-site.azurewebsites.net/
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="126", "Chromium";v="126"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 0
Origin: https://npmyhhymesqu.com



Response:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html; charset=utf-8
Date: Mon, 29 Jul 2024 19:38:40 GMT
Server: Microsoft-IIS/10.0
Access-Control-Allow-Origin: https://npmyhhymesqu.com
Vary: Accept-Encoding
Strict-Transport-Security: max-age=2592000
Request-Context: appId=cid-v1:db2dc125-2ce4-4691-9701-850cfa4f1565
X-Powered-By: ASP.NET
Content-Length: 7137

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<title>Cors | Vulnerable Site</title>
<link rel=Snip



References
  
- Web Security Academy: Cross-origin resource sharing (CORS) (https://portswigger.net/web-security/cors)

-  Exploiting CORS Misconfigurations (https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) 



Vulnerability Classifications

- CWE-942: Overly Permissive Cross-domain Whitelist (https://cwe.mitre.org/data/definitions/942.html)



Reported by Dastardly: https://portswigger.net/burp/dastardly/scan-checks

Severity: Info

Confidence: Certain

Host: https://vulnerable-site.azurewebsites.net

Path: /Cors


Issue Detail
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue Background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.
If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.


Issue Remediation
Any inappropriate domains should be removed from the CORS policy.


Evidence
Request:
GET /Cors HTTP/1.1
Host: vulnerable-site.azurewebsites.net
Accept-Encoding: gzip, deflate, br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36
Connection: close
Cache-Control: max-age=0
Cookie: ARRAffinity=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ARRAffinitySameSite=22a7daa836b64a8ce56c907737553d08297ff2e76cd06a1f52c29956b9a85c17; ai_user=QkAu6QF/OHfFeZfSl61QQN|2024-07-29T19:38:34.222Z; ai_session=HY1wBJCLHifUneoKC7fEUc|1722281914369|1722281914369
Upgrade-Insecure-Requests: 1
Referer: https://vulnerable-site.azurewebsites.net/
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="126", "Chromium";v="126"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 0
Origin: https://vulnerable-site.azurewebsites.net



Response:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html; charset=utf-8
Date: Mon, 29 Jul 2024 19:38:39 GMT
Server: Microsoft-IIS/10.0
Access-Control-Allow-Origin: https://vulnerable-site.azurewebsites.net
Vary: Accept-Encoding
Strict-Transport-Security: max-age=2592000
Request-Context: appId=cid-v1:db2dc125-2ce4-4691-9701-850cfa4f1565
X-Powered-By: ASP.NET
Content-Length: 7137

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<title>Cors | Vulnerable Site</title>
<link rel=Snip



References
  
- Web Security Academy: Cross-origin resource sharing (CORS) (https://portswigger.net/web-security/cors)

-  Exploiting CORS Misconfigurations (https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) 



Vulnerability Classifications

- CWE-942: Overly Permissive Cross-domain Whitelist (https://cwe.mitre.org/data/definitions/942.html)



Reported by Dastardly: https://portswigger.net/burp/dastardly/scan-checks