Blind Cross-Site Scripting in Zendesk Chat worth of $2000

Way back in 2016 I participated in Zendesk 2016 holiday promotion in Hackerone, then I reported a Cross-Site Scripting Issue in the Zendesk platform Affecting the Zendesk Chat product and they fixed it immediately.

Now let's talk about how I found it, upon testing the Chat product I embedded the Web Widget in my Blog Site. Thinking out of the box "What will happen if Someone will Insert a malicious Code in the Chat and Sends it to me?" pretty simple idea right?😅.

Now I executed the test, Inserted a generic XSS payload on the web widget chat, observing what will happen in the Agent end? where is the chat being saved? and finally, I got an execution on the code inserted in widget chat at https://(yoursubdomainname).zendesk.com/agent/chat.

As soon as I notice the bug I filed a bug report on Hackerone.

Let's talk about, What is the security impact of the bug I reported? It could potentially be used to steal Agent's Session Cookies and the severity is High Because it is easy to be exploited, a malicious user doesn't need to be authenticated to execute an attack, Only insert a malicious code on the public widget chat and wait for the code to execute on Agent end.

When the bug got validated and being triaged I felt so happy that time🙂, Knowing that it is unknown to them, I am the first one to report it and I contributed to their Security.

This is my Original Report at Hackerone.

What is XSS (Cross-Site Scripting) BTW?

According to Owasp.org

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

What are the Types of Cross-Site scripting?

According to Acunetix.com

Stored XSS (Persistent XSS)

The most damaging type of XSS is Stored XSS (Persistent XSS). An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database. For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post.

When a victim opens the affected web page in a browser, the XSS attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment would). This means that victims will end up executing the malicious script once the page is viewed in their browser.

Reflected XSS (Non-Persistent)

The second and the most common type of XSS is Reflected XSS (Non-persistent XSS). In this case, the attacker’s payload has to be a part of the request that is sent to the web server. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links, phishing emails, and other social engineering techniques to lure the victim into making a request to the server. The reflected XSS payload is then executed in the user’s browser.

Reflected XSS is not a persistent attack, so the attacker needs to deliver the payload to each victim. These attacks are often made using social networks.

DOM Based XSS

DOM-based XSS is an advanced XSS attack. It is possible if the web application’s client-side scripts write data provided by the user to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.

A DOM-based XSS attack is often a client-side attack and the malicious payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers who analyze server logs because they will never even see the attack. DOM objects that are most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the Referrer (document.referrer).

So what is Blind XSS that you have found above?. In my opinion, BXSS is a kind of Stored XSS that the code inserted is being saved and executed in admin or agent Dashboard.

How to prevent XSS attacks

According to Portswigger.net

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

Filter input on arrival

At the point where user input is received, filter as strictly as possible based on what is expected or valid input.

Encode data on output

At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

Use appropriate response headers

To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

Content Security Policy

As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Thanks for Reading🥰🥰🥰!!!