Hi,
In the burp scan analysis report we found *Cross-site scripting
(reflected) *vulnerability for the Alertmanager and Prometheus server.
Please provide the solution to solve/remove this vulnerability.
Please find the attached files for more information.
Regards,
Veena
--
You received this message because you are subscribed to the Google Groups
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-users/68a949dd-bc8a-4814-8206-773ba1c0320a%40googlegroups.com.
4. Cross-site scripting (reflected)
There are 2 instances of this issue:
/alertmanager [state parameter]
/prometheus [state parameter]
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 (< > 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.
References
Cross-site scripting
Reflected cross-site scripting
Using Burp to Find XSS issues
Vulnerability classifications
CWE-79: Improper Neutralization of Input During Web Page Generation
('Cross-site Scripting')
CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page
(Basic XSS)
CWE-116: Improper Encoding or Escaping of Output
CWE-159: Failure to Sanitize Special Element
4.1. https://x.x.x.x/alertmanager [state parameter]
Previous Next
Summary
Severity: High
Confidence: Certain
Host: https://x.x.x.x
Path: /alertmanager
Issue detail
The value of the state request parameter is copied into the HTML document as
plain text between tags. The payload yeyj4<script>alert(1)</script>zurg7 was
submitted in the state 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.
The response does not state that the content type is HTML. The issue is only
directly exploitable if a browser can be made to interpret the response as
HTML. The following browsers may interpret the response as HTML:
Internet Explorer 11 (Compatibility Mode)
Request 1
GET
/alertmanager?state=12f3ff2901d2ff2fd1440f7fadb0e65byeyj4%3cscript%3ealert(1)%3c%2fscript%3ezurg7&session_state=3256ba76-832e-4a32-9e9b-fe989bfafa57&code=c060d6d4-8522-46aa-812c-195d03b5c782.3256ba76-832e-4a32-9e9b-fe989bfafa57.a9e61b32-81b3-49eb-8587-21b237c74e13
HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://x.x.x.x/csdHome/
Connection: close
Response 1
HTTP/1.1 401 Unauthorized
Date: Mon, 27 Apr 2020 13:15:10 GMT
Content-Type: text/plain; charset=UTF-8
Connection: close
Strict-Transport-Security: max-age=15724800; includeSubDomains
Content-Length: 166
state from argument:
12f3ff2901d2ff2fd1440f7fadb0e65byeyj4<script>alert(1)</script>zurg7 does not
match state restored from session: 12f3ff2901d2ff2fd1440f7fadb0e65b
4.2. https://x.x.x.x/prometheus [state parameter]
Previous Next
Summary
Severity: High
Confidence: Certain
Host: https://x.x.x.x
Path: /prometheus
Issue detail
The value of the state request parameter is copied into the HTML document as
plain text between tags. The payload mc2m6<script>alert(1)</script>yrb38 was
submitted in the state 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.
The response does not state that the content type is HTML. The issue is only
directly exploitable if a browser can be made to interpret the response as
HTML. The following browsers may interpret the response as HTML:
Internet Explorer 11 (Compatibility Mode)
Request 1
GET
/prometheus?state=2cf6995b0a841d6842ca0dfad6141e46mc2m6%3cscript%3ealert(1)%3c%2fscript%3eyrb38&session_state=3256ba76-832e-4a32-9e9b-fe989bfafa57&code=18870508-634f-4d4a-81b5-e49c3f8eaac6.3256ba76-832e-4a32-9e9b-fe989bfafa57.a9e61b32-81b3-49eb-8587-21b237c74e13
HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://x.x.x.x/csdHome/
Connection: close
Response 1
HTTP/1.1 401 Unauthorized
Date: Mon, 27 Apr 2020 13:02:14 GMT
Content-Type: text/plain; charset=UTF-8
Connection: close
Strict-Transport-Security: max-age=15724800; includeSubDomains
Content-Length: 166
state from argument:
2cf6995b0a841d6842ca0dfad6141e46mc2m6<script>alert(1)</script>yrb38 does not
match state restored from session: 2cf6995b0a841d6842ca0dfad6141e46
