Summary by xyzeva
In Cal, the single booking view accessible via https://app.cal.com/booking/<id> globally accessible by everyone can be weaponized for Cross Site Scripting (XSS)
Details
The Cal codebase uses dangerouslySetInnerHTML for field labels on the single booking page, allowing for arbitrary html including script tags with no CSP.
PoC
- Create a new event type on Cal
- Go to Advanced and add a new booking question with a malicious label
- Book a meeting with yourself
- Grab the URL of the completed page
- Send the URL to victims
- Profit!
Summary by Peer Richelsen
3rd December XSS Vulnerability found
Pentester xyz3vaIn (x.com/@xyz3vaIn) discovered and reported a vulnerability related to Cross-Site Scripting (XSS) in our booking form system. This vulnerability was present in versions prior to v4.7.16, where the use of dangerouslySetInnerHTML in the booking form label field inadvertently opened a pathway for malicious script injection.
What Happened?
The issue arose from improper sanitization of user inputs in the booking form labels. dangerouslySetInnerHTML is a React attribute that allows raw HTML to be inserted into the DOM, intended for controlled use where developers are certain about the safety of the HTML content. However, in this case, it was exploited because the input wasn't adequately validated or escaped, allowing rogue users to inject JavaScript code into the label.
Upon submitting a booking form, an attacker could craft a payload within the label text. This payload, when clicked by an unsuspecting user, could execute malicious scripts. The potential harm included:
Impact Assessment
Our extensive review and analysis of logs indicate that no customer data was compromised. The vulnerability required a user-initiated action (clicking on a maliciously crafted link), which was not exploited in any recorded instance.
Who Was At Risk?
-
Cal.com users receiving a malicious link that injected a script
- Fortunately, we have not found any evidence in our logs that this happened
-
Self-hosters with an Open Registration Form: Only those running our platform on their own servers with public registration enabled might be at risk, since the attacker needs to create an Event-Type with with the malicious XSS script as a Booking Question label.
-
Internal Use: For those using the self-hosted core internally within organizations, the risk is very low since external access was restricted. Without having access to the instance, an attacker could not create a booking question, thereby not execute the XSS. However, updating was still recommended to prevent any internal misuse of employees or accidental exposure.
The Fix and Next Steps
We've addressed this vulnerability in version v4.7.16:
-
Sanitization: Enhanced input sanitization processes to prevent script injection.
-
Secure Practices: Updated guidance for developers on the safe use of dangerouslySetInnerHTML, emphasizing input validation and escaping.
For Self-hosters:
- Immediate Upgrade: If you have an open platform where external users can sign up, we strongly recommend upgrading to v4.7.16 or later immediately to protect against this vulnerability. If you use a self-hosted instance internally for your team you are less at risk, an update is still recommended.
General Advice:
-
Always keep your software updated to the latest version to benefit from security patches.
-
If you're unsure about your version or need assistance with the upgrade, reach out to our support team.
Conclusion
While no breaches were detected, this incident serves as a reminder of the importance of secure coding practices and the vigilance required in software development. We apologize for any concern this may have caused and thank our users for their trust and support as we work to maintain a secure environment for all.
We are thankful for x.com/xyz3vaIn for the report and assitance.
Stay secure, and thank you for using our platform.
xyzeva Reporter
Summary by xyzeva
In Cal, the single booking view accessible via
https://app.cal.com/booking/<id>globally accessible by everyone can be weaponized for Cross Site Scripting (XSS)Details
The Cal codebase uses
dangerouslySetInnerHTMLfor field labels on the single booking page, allowing for arbitrary html including script tags with no CSP.PoC
Summary by Peer Richelsen
3rd December XSS Vulnerability found
Pentester xyz3vaIn (x.com/@xyz3vaIn) discovered and reported a vulnerability related to Cross-Site Scripting (XSS) in our booking form system. This vulnerability was present in versions prior to v4.7.16, where the use of dangerouslySetInnerHTML in the booking form label field inadvertently opened a pathway for malicious script injection.
What Happened?
The issue arose from improper sanitization of user inputs in the booking form labels. dangerouslySetInnerHTML is a React attribute that allows raw HTML to be inserted into the DOM, intended for controlled use where developers are certain about the safety of the HTML content. However, in this case, it was exploited because the input wasn't adequately validated or escaped, allowing rogue users to inject JavaScript code into the label.
Upon submitting a booking form, an attacker could craft a payload within the label text. This payload, when clicked by an unsuspecting user, could execute malicious scripts. The potential harm included:
Fetching user data.
Stealing API keys or other sensitive information stored in the browser's local storage or cookies.
Impact Assessment
Our extensive review and analysis of logs indicate that no customer data was compromised. The vulnerability required a user-initiated action (clicking on a maliciously crafted link), which was not exploited in any recorded instance.
Who Was At Risk?
Cal.com users receiving a malicious link that injected a script
Self-hosters with an Open Registration Form: Only those running our platform on their own servers with public registration enabled might be at risk, since the attacker needs to create an Event-Type with with the malicious XSS script as a Booking Question label.
Internal Use: For those using the self-hosted core internally within organizations, the risk is very low since external access was restricted. Without having access to the instance, an attacker could not create a booking question, thereby not execute the XSS. However, updating was still recommended to prevent any internal misuse of employees or accidental exposure.
The Fix and Next Steps
We've addressed this vulnerability in version v4.7.16:
Sanitization: Enhanced input sanitization processes to prevent script injection.
Secure Practices: Updated guidance for developers on the safe use of dangerouslySetInnerHTML, emphasizing input validation and escaping.
For Self-hosters:
General Advice:
Always keep your software updated to the latest version to benefit from security patches.
If you're unsure about your version or need assistance with the upgrade, reach out to our support team.
Conclusion
While no breaches were detected, this incident serves as a reminder of the importance of secure coding practices and the vigilance required in software development. We apologize for any concern this may have caused and thank our users for their trust and support as we work to maintain a secure environment for all.
We are thankful for x.com/xyz3vaIn for the report and assitance.
Stay secure, and thank you for using our platform.