translated strings shouldn't be validated

They are validated for security reasons, or otherwise translations downloaded and shared from around the web can include malicious HTML code that breaks you site or lets others hack into it easily. Please submit issues for modules which use such strings that are not translatable, those should be fixed.

In fact there are some improvements being worked on for this at #1020842: Error messages when importing translated strings fails are not helpful at all.

They are validated for security reasons, or otherwise translations downloaded and shared from around the web can include malicious HTML code that breaks you site or lets others hack into it easily. Please submit issues for modules which use such strings that are not translatable, those should be fixed.

In general you shouldn't download stuff from untrusted sources and install it on your site without checking it first. This is true for translations, modules, themes, etc.

(Even though the current mechanism prevents you from importing XSS strings, a bad translation file can still pollute you site with nonsense translations)

Now that we have localize.drupal.org as a central repository for translations, I think we should loosen this restriction. AFAIK the translations here are approved by moderators (a role similar to module maintainers) before they are included in the downloadable files.

Of course, a safety net is nice, but the current solution is too aggressive. There is no requirement that strings translation to t() should be valid HTML — some strings are used in a pure plain-text context.

This patch accepts "unsafe" translations if the source itself is unsafe.

From DRUPAL-PSA-2012-001 that was published yesterday:
"Given that translations strings can be harmful, you should treat them with the same skepticism that you treat modules"

I think this backs my point that we shouldn't just reject certain strings for security reasons (strings that are required in order to have a full translation), but rather make the user aware that importing translations is always potentially dangerous.

Please submit issues for modules which use such strings that are not translatable, those should be fixed.

Gabor, how do you suggest they should be fixed? If a module wants an option in a select dropdown (i.e. in a plain-text context where you cannot use HTML entities) to be labeled <none>, is there any other way to implement this than t('<node>').

Yes, the < and > are not linguistic, they are part of the look and feel of your module, so you don't give them to t(). You can find examples for that in core.

You are right. I gave a bad example. Stuff like t('<none>') should be refactored.

But there are (a few) examples where <> is part of the linguistic content, in particular texts that explains stuff about HTML tags. The following are real examples taken from below this page on drupal.org:

t('You may post code using ‹code›...‹/code› (generic) or ‹?php ... ?› (highlighted PHP) tags.')
t('Only images hosted on this site may be used in ‹img› tags. Others are replaced with an error icon.')

I don't know how this is actually implemented on drupal.org, and there are several ways to get around the limitation (e.g. encode the whole thing as HTML), but my point is just that there are real-world use-cases for putting HTML-like content in t() strings.

I re-think it once.

If i'm understand it correctly, the new change in D8 allowed XSS attack. #1317884: Remove all instances of <none>, <Hidden> and <br/> from translatable strings because they lead to import errors

<?php
$bad_trans = "IMG SRC=JaVaScRiPt:alert('XSS')";
var_dump( locale_string_is_safe($bad_trans) ); // TRUE
?>
<<?php echo t($bad_trans); ?>> 

// output XSS attack code, it worked
// https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Why not use HTML Entity:

eg.

t('< Hidden >')
t('<') . t('Hidden') . t('>')

There is no change to D8. Only some occurrences of t('<Foo>') was changed to t('- Foo -'). No danger there.

However, with the change proposed in this ticket, sites will be vulnerable to XSS if they import translations from untrusted sources. My point is that this is no different that if you install a module from untrusted sources - so I don't see why we should apply a stricter security level for translations than for modules. Even without the XSS issue, you can still screw up your site considerable if you import a bad translations (e.g. a translations file full of profane words).

I don't understand what you are trying to illustrate with your example. Such crazy code will always be vulnerable.

About HTML entities: You cannot always use HTML entities. E.g. in an #options array for a #type => 'select', the individual entries should be plain-text (i.e. not HTML-encoded).

Translateable strings are user input in the translation interface. We need to filter this. It's not the same like installing a module from an non-d.o source. Aside, d.o modules are not more secure than any other. There are no reviews in both.

A malicious user with sufficient privileges can break the site in many different ways.

The "Translate interface" permission is included in the list of permissions that are considered administrative and should thus only be granted to trusted users:

Any user with one of the above permissions can already take over the site, so there is no meaningful added risk if a vulnerability is only accessible to a user with one of these permissions.

This was closed as a duplicate and then reopened

There's been no activity in some time

Should it be closed again?

I wonder if this was addressed in #2371861: Strings including tokens in href or src attributes cannot be translated due to safeness check incompatibilities

There has been no activity here for 10 years, except for 6 month ago. At that time, it was asked if this is still applicable.
There has has been no reply. Therefor I am restoring the duplicate status.