Reflected Cross-Site Scripting (XSS)

[vmario89]

Hi,

i got a security warning from a penetration tester right now and wonder how to fix it. I added add_header X-XSS-Protection "1; mode=block"; months ago to nginx, but seems not to take proper grip.

---

Vulnerability Report: Reflected Cross-Site Scripting (XSS)

Target URL:
https://REDACTED.org/calendar.html

Vulnerable Parameter(s):
url

Description:
The url parameter in the endpoint is vulnerable to reflected XSS. An attacker can inject malicious JavaScript code, which is then reflected back in the response and executed in the victim's browser. This could lead to theft of sensitive information, session hijacking, or other malicious actions.

Proof of Concept (PoC):
A crafted URL demonstrates the vulnerability:

URL
https://REDACTED.org/calendar.html?language=zh_Hans&url=https%3A%2F%2Fwww.calendarlabs.com%2Fical-calendar%2Fics%2F46%2FGermany_Holidays.ics&url=%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E

Steps to reproduce:

    Navigate to the crafted URL above.
    Observe that an alert box with the value 1 is triggered in the browser, demonstrating the execution of injected JavaScript.

Impact:

    An attacker could exploit this vulnerability to execute arbitrary JavaScript in the context of the vulnerable domain.
    Potential risks include:
        Stealing session cookies or user credentials.
        Defacing the application.
        Redirecting users to malicious websites.

---

We're using Polar.sh so you can upvote and help fund this issue. We receive the funding once the issue is completed & confirmed by you. Thank you in advance for helping prioritize & fund our work.

[niccokunzmann]

This looks like an img tag with Js in it. The error page would show this as a url. I wonder where this is actually exposed to the frontend. I will take more time later to dig into this.

[niccokunzmann]

http://open-web-calendar.hosted.quelltext.eu/calendar.html?language=zh_Hans&url=https%3A%2F%2Fwww.calendarlabs.com%2Fical-calendar%2Fics%2F46%2FGermany_Holidays.ics&url=%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E

[niccokunzmann]

Found:

open-web-calendar/open_web_calendar/static/js/configure.js

Line 185 in c96d5ad

"<a href='" + error.url + "'>" + error.url + "</a>" +

It would be safer here to create html elements.

Also, the OWC has a different security model than what is there usually. There is no log in, no credentials, nothing private in it.
Technically:
The same spec creates the same calendar display.
You are in charge of the specification. The specification can contain CSS or Javascript. As long as an attacker cannot alter the spec for others, the attack can come from the calendar content but not its url.

I think, I should describe this in the docs a bit more. And I have a security report to work with in early 2025. That should contain an assessment of this and explain it a bit better.

At the moment, this is expected and not a threat and an easy find for security testers. You can also set the js parameter.

[niccokunzmann]

In short: you can do what you want with JavaScript on the subdomain of the open web calendar because

• there is no state
• there is no private data
• there is no database
• there is no tracking
• there is no log-in

Understand it as static JS (same spec means same code) with a proxy in Python to retrieve the calendars.

What you do with JS then only happens where you embed the OWC.

So, this is my assumption. You can see that this model is not the usual webservice one where you sign up and so on.

[niccokunzmann]

After #595 is solved, I will publicise the report. Then, you have a proper text to see how this affects users. Also, we could make JS optional. For now, we have fixed the link creation in #590:

https://github.com/niccokunzmann/open-web-calendar/pull/590/files#diff-458cb5236b2f1fdc0095bf671db9f72f21f279d568d8c3dbf335882de35c71eeR52

What are your thoughts on this?

Closing Requirement

• fix remote code execution for the link mentioned above
• Make JavaScript customization optional for an OWC instance.
• add a OWC_ENABLE_JS=False ENV parameter
• communicate about expected security for this parameter and for the OWC.
• Optional: Use JS URL/Code from default_specification and alike but not from parameters or specification_url