This vulnerability makes it possible to temporarily execute JavaScript code in the context of the application, granting access to the session of
the victim. This is possible because user-provided data, such as URL parameters, are copied into the HTML body of the HTTP response that is sent back
to the user.
Why is this an issue?
Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data like parameters or headers from an incoming
HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters.
When well-intentioned users open a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own
browser.
A user with malicious intent carefully crafts the link beforehand.
After creating this link, the attacker must use phishing techniques to ensure that his target users click on the link.
What is the potential impact?
A well-intentioned user opens a malicious link that injects data into the web application. This data can be text, but it can also be arbitrary code
that can be interpreted by the target user’s browser, such as HTML, CSS, or JavaScript.
Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.
Vandalism on the front-end website
The malicious link defaces the target web application from the perspective of the user who is the victim. This may result in loss of integrity and
theft of the benevolent user’s data.
Identity spoofing
The forged link injects malicious code into the web application. The code enables identity spoofing thanks to cookie theft.
Record user activity
The forged link injects malicious code into the web application. To leak confidential information, attackers can inject code that records keyboard
activity (keylogger) and even requests access to other devices, such as the camera or microphone.
Chaining XSS with other vulnerabilities
In many cases, bug hunters and attackers chain cross-site scripting vulnerabilities with other vulnerabilities to maximize their impact.
For
example, an XSS can be used as the first step to exploit more dangerous vulnerabilities or features that require higher privileges, such as a code
injection vulnerability in the admin control panel of a web application.
How to fix it in Express.js
Code examples
The following code is vulnerable to cross-site scripting because it returns an HTML response that contains unsanitized user input.
If you do not intend to send HTML code to clients, the vulnerability can be fixed by specifying the type of data returned in the response. For
example, you can use the JsonResponse class to safely return JSON messages.
Noncompliant code example
function (req, res) {
json = JSON.stringify({ "data": req.query.input });
res.send(json);
};
Compliant solution
function (req, res) {
res.json({ "data": req.query.input });
};
It is also possible to set the content-type header manually using the content_type parameter when creating an
HttpResponse object.
Noncompliant code example
function (req, res) {
res.send(req.query.input);
};
Compliant solution
function (req, res) {
res.set('Content-Type', 'text/plain');
res.send(req.query.input);
};
How does this work?
In case the response consists of HTML code, it is highly recommended to use a template engine like ejs to generate
it. This template engine separates the view from the business logic and automatically encodes the output of variables, drastically reducing the risk
of cross-site scripting vulnerabilities.
If you do not intend to send HTML code to clients, the vulnerability can be resolved by telling them what data they are receiving with the
content-type HTTP header. This header tells the browser that the response does not contain HTML code and should not be parsed and
interpreted as HTML. Thus, the HTTP response is not vulnerable to reflected Cross-Site Scripting.
For example, setting the content-type header to text/plain allows to safely reflect user input since browsers will not try to parse
and execute the response.
Pitfalls
Content-types
Be aware that there are more content-types than text/html that allow to execute JavaScript code in a browser and thus are prone to
cross-site scripting vulnerabilities.
The following content-types are known to be affected:
- application/mathml+xml
- application/rdf+xml
- application/vnd.wap.xhtml+xml
- application/xhtml+xml
- application/xml
- image/svg+xml
- multipart/x-mixed-replace
- text/html
- text/rdf
- text/xml
- text/xsl
The limits of validation
Validation of user inputs is a good practice to protect against various injection attacks. But for XSS, validation on its own is not the
recommended approach.
As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is
sometimes used by web application firewalls. It is only a matter of time for malicious users to find the exploitation payload that will defeat the
filters.
Another example is applications that allow users or third-party services to send HTML content to be used by the application. A common approach is
trying to parse HTML and strip sensitive HTML tags. Again, this deny-list approach is vulnerable by design: maintaining a list of sensitive HTML tags,
in the long run, is very difficult.
A preferred option is to use Markdown in conjunction with a parser that removes embedded HTML and restricts the use of "javascript:" URI.
Going the extra mile
Content Security Policy (CSP) Header
With a defense-in-depth security approach, the CSP response header can be added to instruct client browsers to
block loading data that does not meet the application’s security requirements. If configured correctly, this can prevent any attempt
to exploit XSS in the application.
Learn more here.
Resources
Documentation
Articles & blog posts
Conference presentations
Standards
