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 Core PHP
Code examples
The following code is vulnerable to cross-site scripting because it returns an HTML response that contains user input.
User input embedded in HTML code should be HTML-encoded to prevent the injection of additional code. PHP provides the built-in function
htmlspecialchars to do this.
Noncompliant code example
echo '<h1>' . $input . '</h1>';
Compliant solution
echo '<h1>' . htmlspecialchars($input) . '</h1>';
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 with the
content-type header.
For example, setting the content-type to text/plain using the built-in header function allows to safely reflect user
input since browsers will not try to parse and execute the response.
Noncompliant code example
echo $input;
Compliant solution
header('Content-Type: text/plain');
echo $input;
How does this work?
Encode data according to the HTML context
The best approach to protect against XSS is to systematically encode data that is written to HTML documents. The goal is to leave the data intact
from the end user’s point of view but make it uninterpretable by web browsers.
XSS exploitation techniques vary depending on the HTML context where malicious input is injected. For each HTML context, there is a specific
encoding to prevent JavaScript code from being interpreted. The following table summarizes the encoding to apply for each HTML context.
| Context |
Code example |
Exploit example |
Encoding |
| Inbetween tags |
<!doctype html>
<div>
{ data }
</div>
|
<!doctype html>
<div>
<script>
alert(1)
</script>
</div>
|
HTML entity encoding: replace the following characters by HTML-safe sequences.
- & → &
- < → <
- > → >
- " → "
- ' → '
|
| In an attribute surrounded with single or double quotes |
<!doctype html>
<div tag="{ data }">
...
</div>
|
<!doctype html>
<div tag=""
onmouseover="alert(1)">
...
</div>
|
HTML entity encoding: replace the following characters with HTML-safe sequences.
- & → &
- < → <
- > → >
- " → "
- ' → '
|
| In an unquoted attribute |
<!doctype html>
<div tag={ data }>
...
</div>
|
<!doctype html>
<div tag=foo
onmouseover=alert(1)>
...
</div>
|
Dangerous context: HTML output encoding will not prevent XSS fully. |
| In a URL attribute |
<!doctype html>
<a href="{ data }">
...
</a>
|
<!doctype html>
<a href="javascript:alert(1)">
...
</a>
|
Validate the URL by parsing the data. Make sure relative URLs start with a / and that absolute URLs use https
as a scheme. |
| In a script block |
<!doctype html>
<script>
{ data }
</script>
|
<!doctype html>
<script>
alert(1)
</script>
|
Dangerous context: HTML output encoding will not prevent XSS fully. To pass values to a JavaScript context, the recommended way is to use a data attribute:
<!doctype html>
<script data="{ data }">
...
</script>
|
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
Single quoted variables in attributes
By default, htmlspecialchars does not encode single quotes, so if $input is untrusted, JavaScript code can be
injected.
Make sure to set the option ENT_QUOTES to encode single quotes.
Noncompliant code example
echo "<img src='" . htmlspecialchars($input) . "'>";
Compliant solution
echo "<img src='" . htmlspecialchars($input, ENT_QUOTES) . "'>";
Headers and output
If the HTTP body is sent before header is called, no headers will be sent to the client.
To fix this issue, send the headers before any output.
Noncompliant code example
echo 'No more headers at this point';
header('Content-Type: text/plain');
echo $input;
Compliant solution
header('Content-Type: text/plain');
echo $input;
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.
How to fix it in Laravel
Code examples
The following code is vulnerable to cross-site scripting because it returns an HTML response that contains 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 json method of the Response class to safely return JSON messages.
Noncompliant code example
$response = response(json_encode(['data' => $input]), 200);
Compliant solution
$response = response()->json(['data' => $input]);
It is also possible to set the content-type header manually using the header method of the Response class.
Noncompliant code example
$response = response($input, 200);
Compliant solution
$response = response($input, 200)->header('Content-Type', 'text/plain');
How does this work?
If the HTTP response is HTML code, it is highly recommended to use a template engine like Blade 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 fixed by specifying the type of data returned in the response 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 response is not vulnerable to reflected cross-site scripting.
For example, setting the content-type 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
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.
How to fix it in Symfony
Code examples
The following code is vulnerable to cross-site scripting because it returns an HTML response that contains 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 class JsonResponse to return JSON messages safely.
Noncompliant code example
use Symfony\Component\HttpFoundation\Response;
$response = new Response();
$response->setContent(json_encode(['data' => $input]));
Compliant solution
use Symfony\Component\HttpFoundation\JsonResponse;
$response = new JsonResponse(['data' => $input]);
It is also possible to set the content-type manually using the headers attribute.
Noncompliant code example
use Symfony\Component\HttpFoundation\Response;
$response = new Response();
$response->setContent($input);
Compliant solution
use Symfony\Component\HttpFoundation\Response;
$response = new Response();
$response->headers->set('Content-Type', 'text/plain');
$response->setContent($input);
How does this work?
If the HTTP response is HTML code, it is highly recommended to use a template engine like Twig 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 fixed by specifying the type of data returned in the response 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 response is not vulnerable to reflected cross-site scripting.
For example, setting the content-type 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
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
