Anatomy of a cross-site scripting flaw in the Telerik reporting module.

Author:Runkle, Matt

One of the interesting aspects of working as a Veracode Application Security Consultant is seeing the wide range of code across many business sectors. On an average day, I could look at some COBOL code twice my age in the morning, and by lunch I'm exploring a large .NET MVC app, before transitioning to review a self-deploying microservices package comprised of Java, node.js, and a little PHP for good measure. Besides just helping Veracode customers to secure their apps, I really enjoy learning the new trends, frameworks, and creative ways people use software to solve problems.

Occasionally, during a consultation, I'll see something suspicious in the static or dynamic scan results that sticks out more than I'd expect for the type of application evaluated. In one particularly interesting case, I was working recently with a client who was pursuing a VerAfied seal--a rigorous process that provides high assurances about the application security posture of an application.

The customer was building a web application on a .NET stack that, among other things, generated various printable reports. To accomplish that task, the developers were using the popular Telerik Reporting project, built by Progress. While I've seen many Telerik components used in other applications, this was my first time coming across the Reporting module in a web context, so I was surprised to discover a reflective cross-site scripting (XSS) vulnerability within the Reporting component.

I reported the vulnerability (tracked as CVE-20I7-9I40) via email to the Progress team, who created a patch during their next update cycle. Now that the vulnerability has been properly fixed, I can safely share details of what I discovered and how to prevent and mitigate flaws of this type.

Details of the XSS Vulnerability

Reflective XSS occurs when applications mix untrusted data provided in an HTTP request with HTTP response content that is rendered without proper encoding. Unlike stored XSS attacks, which can affect many users of a service, reflective XSS requires that an attacker manipulate data within a request through some means or trick a user into clicking a malicious link containing an XSS payload.

In this case, our exploitation vector leverages an exposed parameter within the WebForms ReportViewer component. The default use is sufficient in this case. The ReportViewer is a simple web control used to view generated reports by adding a one-line snippet to any .aspx page, as such:


To continue reading