Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sanitizing localization files #1354

Merged
merged 2 commits into from
Dec 23, 2024
Merged

Sanitizing localization files #1354

merged 2 commits into from
Dec 23, 2024

Conversation

berhalak
Copy link
Contributor

Context

Sanitizing localization files.

Proposed solution

Added a script that is executed during build time that will sanitize every key in every translations resource file.

Related issues

#1350

Has this been tested?

Tested manually.

@berhalak berhalak changed the title Sanitizing lolication files Sanitizing localization files Dec 23, 2024
Copy link
Contributor

@georgegevoian georgegevoian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @berhalak!

@berhalak berhalak merged commit e280ece into main Dec 23, 2024
12 checks passed
@berhalak berhalak deleted the sanitize-localization branch December 23, 2024 15:38

function purify(inputString) {
// This removes any html tags from the string
return DOMPurify.sanitize(inputString);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure that DOMPurify.sanitize in fact removes all html tags from a string? Examples at https://github.com/cure53/DOMPurify?tab=readme-ov-file#some-purification-samples-please contract that, e.g.:

DOMPurify.sanitize('<img src=x onerror=alert(1)//>'); // becomes <img src="x">

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@berhalak, I'm wondering if it's better to revert this change.

This PR care of the XSS attack vector discussed here, but I think style elements can still be injected (if strings are not escaped). Furthermore, I don't think we explicitly set innerHTML to a translation string anywhere in our code, do we? Sanitizing here certainly doesn't hurt, but I don't think it fully replaces the need to escape HTML, and it seems like that's all that #1247 needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants