The Dashboard is rendered from a Liquid template, parsed from a file specified in the EyeDP settings:
@template = Liquid::Template.parse(Setting.dashboard_template)
The default Liquid template does not sanitize variables before including them in the resulting HTML output, which is rendered in the user's browser. This results into a stored cross-site scripting vulnerability (XSS).
After a operator or administrator creates or edits a SSO application with a piece of malicious Javascript code in the affected parameters, any user that displays the dashboard will execute the Javascript code in their browser.
Below a snippet of code from the affected Liquid template:
<div class="row">
<h5 class="card-title mx-auto"><a href="{{ application["url"] }}">{{ application['name'] }}</a></h5>
</div>The variables are inserted as-is, without invoking the escape Liquid filter. Affected parameters are all the fields of the SSO applications that are inserted in the dashboard: URL, image URL, name, description.
As a proof of concept, the screenshot below shows the result of creating a OIDC application with the following display name: <script>alert(document.domain)</script>
The resulting HTML code, corresponding to the snippet mentioned above, is:
<div class="row">
<h5 class="card-title mx-auto"><a href="javascript:alert(document.domain)"><script>alert(document.domain)</script></a></h5>
</div>
Likewise, the cross-site scripting vulnerability can be triggered also if the display URL of a SSO application contains the following payload: javascript:alert(document.domain). In this case, the code will execute when the user clicks on the link to browse to the application.
Note: EyeDP supports Liquid templates also for rendering the user's profile, as follows:
@template = Liquid::Template.parse(Setting.registered_home_template) if Setting.registered_home_template.present?
Unlike the Dashboard, there is no default Liquid template for the profile page. However the lack of sanitization by default of the variables in the Liquid template engine makes it relatively easy for a system integrator to inadvertently insert cross-site scripting vulnerabilities when customizing the Liquid templates. Hence, we suggest to perform sanitization of the in-scope variables before passing them to the Liquid template, rather than relying on the sanitization being done in the Liquid template itself. Or use a gem such as liquid-autoescape to do this automatically.
Impact
Privilege escalation from Operator to Admin. Limited by the fact that applications can be added only by high-privileged users such as Operators and Admins.
Patches
This issue is resolved in Pull 392. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory:
The Dashboard is rendered from a Liquid template, parsed from a file specified in the EyeDP settings:
The default Liquid template does not sanitize variables before including them in the resulting HTML output, which is rendered in the user's browser. This results into a stored cross-site scripting vulnerability (XSS).
After a operator or administrator creates or edits a SSO application with a piece of malicious Javascript code in the affected parameters, any user that displays the dashboard will execute the Javascript code in their browser.
Below a snippet of code from the affected Liquid template:
The variables are inserted as-is, without invoking the escape Liquid filter. Affected parameters are all the fields of the SSO applications that are inserted in the dashboard: URL, image URL, name, description.
As a proof of concept, the screenshot below shows the result of creating a OIDC application with the following display name:
<script>alert(document.domain)</script>The resulting HTML code, corresponding to the snippet mentioned above, is:
Likewise, the cross-site scripting vulnerability can be triggered also if the display URL of a SSO application contains the following payload: javascript:alert(document.domain). In this case, the code will execute when the user clicks on the link to browse to the application.
Note: EyeDP supports Liquid templates also for rendering the user's profile, as follows:
Unlike the Dashboard, there is no default Liquid template for the profile page. However the lack of sanitization by default of the variables in the Liquid template engine makes it relatively easy for a system integrator to inadvertently insert cross-site scripting vulnerabilities when customizing the Liquid templates. Hence, we suggest to perform sanitization of the in-scope variables before passing them to the Liquid template, rather than relying on the sanitization being done in the Liquid template itself. Or use a gem such as liquid-autoescape to do this automatically.
Impact
Privilege escalation from Operator to Admin. Limited by the fact that applications can be added only by high-privileged users such as Operators and Admins.
Patches
This issue is resolved in Pull 392. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory: