New role name not filtered into admin/user/permissions

ingo86 - October 2, 2008 - 08:31
Project:Drupal
Version:7.x-dev
Component:user.module
Category:task
Priority:normal
Assigned:Unassigned
Status:needs work
Issue tags:Security improvements
Description

If you add a javascript as new name of a role, this will be executed into admin/user/permission page.
I assume this is not a security hole because it's inside admin area.

#1

pwolanin - May 19, 2009 - 19:05
Version:6.4» 7.x-dev

This should be fixed, but is not really a security hole - to add new roles requires 'administer permissions' which already means you essentially can escalate your own permissions without limit.

#2

pwolanin - May 19, 2009 - 19:21
Status:active» needs review

Catching it in the user_roles() function also gets most places it's displayed - but might lead to double-encoding.

AttachmentSizeStatusTest resultOperations
role-names-filter-316136-2.patch1.55 KBIdlePassed: 11305 passes, 0 fails, 0 exceptionsView details | Re-test

#3

pwolanin - May 19, 2009 - 19:25

#4

pwolanin - May 19, 2009 - 19:37
Category:bug report» task
Status:needs review» needs work

This will break any select lists using the output of the user_roles() function, so guess we would need to track down uses.

However, it would perhaps make more sense to just validate on input as we do for translations.

#5

dww - May 19, 2009 - 20:57

Right. We're back to the evil checkboxes are output unescaped, while select lists are escaped by FAPI. Ugh. Given that, I think we really do have to continue to output potentially malicious text from user_roles(), and check the call sites 1-by-1 to fix this.

I think it's reasonable to consider validation-on-input, too, but then it seems like we need a DB update to check for existing roles that aren't valid. Not sure what exactly to do with them during the DB update in that case. :( Given that, we should probably stick with escape-on-output...

While we're grepping, we should also make sure no one does anything stupid with $user->roles directly. The hunk in user_edit() is the only spot I can think of where we do anything with that, but there might be others, so we should check.

I'm *really* tempted to call this "minor". If you can't trust the users that have 'administer permissions', you're already in deep trouble.

#6

greggles - May 27, 2009 - 14:52

Is check_plain the right filter here? The issue we're trying to fix is XSS. Why not filter_xss_admin?

Validation on input goes against our overall filtering practice. It also won't save us when some contrib/install profile creates a role name based on user input. We filter on output.

#7

Heine - July 31, 2009 - 11:18

Because rolenames are plaintext (would you expect tags in them? (no) Ampersands ? (yes)), they need to be check_plained to get even valid HTML.

#8

Heine - July 31, 2009 - 11:29

Also from Handle text in a secure fashion:

Plain-text
This is simple text without any markup. What the user entered is displayed exactly on screen as is, and is not interpreted in any form. This is generally the format used for single-line text fields.

When outputting plain-text, you need to pass it through check_plain() before it can be put inside HTML. This will convert quotes, ampersands and angle brackets into entities, causing the string to be shown literally on screen in the browser.

 
 

Drupal is a registered trademark of Dries Buytaert.