Document that 'administer language' is an important permission controlling site urls

Problem/Motivation

Language negotiation allows to link a language to a separate domain.
A non-trusted user with the 'administer languages' permission, could be using this as a way to create a phishing attack.

Proposed resolution

Mark the "administer languages" permission as restricted, so people managing permissions can understand this is a permission that shouldn't be given to untrusted roles.

Remaining tasks

None.

User interface changes

In the permissions page, "administer languages" will show a warning.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Original report

This was originally reported by @mlhess: https://security.drupal.org/node/155183 . This does not pose serious threats e.g. making redirection to external domains possible and was considered appropriate to be handled publicly.

---
(Original report:)

1. give user A permission 'administer language'
2. as user A go to /admin/config/regional/language and enable a second language
3. go to admin/config/regional/language/configure and enable the URL detection method
3. go to /admin/config/regional/language/detection/url and set "Part of the URL that determines language" to "Domain"
4. Go back to admin/config/regional/language, edit the language you enabled above, and enter a domain of your choice in the "'Language domain" field.
5. Eventually (depends on caching) users will end up at your domain. (For example, if you enable the Language Switcher block provided by Drupal core, the link for the above language will point to the above external domain.)

This works. It does not require a trusted permission, but "Administer language" Should be is my guess.

---
(@David_Rothstein's comment)

So there are a couple different ways you can fake a user browsing site A into visiting evil site B:

1. "Malicious redirect" - a link points to a URL at site A, but when you go to that URL you are redirected to site B.
2. "Malicious link" - a link on site A points to site B directly, but the wording/placement of the link on the site strongly suggests it's an official link that will keep you on site A.

I guess you can make an argument that #1 is worse than #2 (though for the average web user I'm not sure it matters). But there's no way we can consider #2 a vulnerability, at least in the case where the attacker's permissions on the site already allow them to modify the site's "official" content... We'd have to mark half the permissions in Drupal as "restrict access" :)

The issue summary here is a bit vague about which this is, but in my testing (I only tested with Drupal 7) I could only produce #2 ("malicious link") with this issue, never an actual redirect. Can anyone else confirm that?

---