Merge branch 'main' into S4

[caalo]

No description provided.

[github-actions]

⚠️ spelling errors ⚠️
There are spelling errors that need to be addressed.
Click here ➡️ for spelling errors! ❗
Add errors that aren't errors to the resources/dictionary.txt file of this repo.
If you are having troubles see this guide
Comment updated at 2024-11-13-22:53:46 with changes from a1e7e5b

[github-actions]

⚠️ broken url errors ⚠️
There are broken url errors that need to be addressed.
Click here ➡️ for broken url errors! ❗
Add errors that aren't errors to the resources/ignore-urls.txt file of this repo.
If you are having troubles see this guide
Comment updated at 2024-11-13-22:53:45 with changes from a1e7e5b

To fix the problem, we need to ensure that the callId is validated before using it to access the pendingCalls object. This can be done by checking if callId is a valid key in pendingCalls and ensuring that the corresponding value is a function before invoking it. This approach prevents unauthorized access and potential runtime exceptions.

To fix the problem, we need to ensure that the input data is properly sanitized before being processed by the marked function. The best way to do this is to use a library that provides robust sanitization for HTML content. One such library is DOMPurify, which can be used to sanitize the output of the marked function.

• Import the DOMPurify library.
• Use DOMPurify to sanitize the HTML generated by the marked function before inserting it into the DOM.

To fix the cross-site scripting vulnerability, we need to sanitize the data.notes content before assigning it to innerHTML. This can be achieved by using a library like DOMPurify, which is designed to sanitize HTML and prevent XSS attacks.

• General fix: Sanitize the user-provided input before inserting it into the DOM.
• Detailed fix: Use DOMPurify to sanitize data.notes before setting it to innerHTML.
• Specific changes:
  • Add the DOMPurify library to the project.
  • Modify the code to sanitize data.notes using DOMPurify before assigning it to innerHTML.

To fix the problem, we need to ensure that the URL used for redirection is validated against a list of authorized URLs. This can be done by maintaining a list of allowed URLs and checking if data.url is in this list before constructing the currentURL and upcomingURL.

1. Create a list of authorized URLs.
2. Check if data.url is in the list of authorized URLs before using it to construct currentURL and upcomingURL.
3. If data.url is not authorized, handle the error appropriately (e.g., log an error, use a default URL, etc.).

To fix the cross-site scripting vulnerability, we need to sanitize the data.url before using it to construct the currentURL and upcomingURL. This can be done by using a library like DOMPurify to clean the URL or by validating the URL to ensure it conforms to expected patterns.

• Import the DOMPurify library to sanitize the URL.
• Sanitize data.url before using it to construct the iframe URLs.
• Ensure the sanitized URL is used in place of the original data.url.

To fix the problem, we need to ensure that the URL used for redirection is validated against a list of authorized URLs. This can be achieved by maintaining a list of trusted URLs and checking if the data.url is in this list before constructing the upcomingURL. If the data.url is not in the list, we should not proceed with the redirection.

1. Create a list of authorized URLs.
2. Check if data.url is in the list of authorized URLs before using it to construct the upcomingURL.
3. If data.url is not authorized, handle the situation appropriately (e.g., log an error, use a default URL, etc.).

To fix the problem, we need to ensure that the URL used in the src attribute of the iframe is properly sanitized or validated to prevent XSS attacks. One effective way to do this is to use a URL validation library to ensure that the URL is safe before using it. We can use the DOMPurify library to sanitize the URL.

1. Import the DOMPurify library.
2. Sanitize the data.url before constructing the upcomingURL and currentURL.
3. Use the sanitized URL to set the src attribute of the iframes.

To fix the problem, we need to ensure that the href attribute value is properly sanitized before it is used to construct the URL for the stylesheet. This can be done by using a function that escapes any potentially dangerous characters in the href value.

The best way to fix the problem without changing existing functionality is to introduce a function that escapes special characters in the href value. This function should be called before the href value is used in the URL construction.