The file page.tpl.php prints out the $page_icon_class variable, which is set in rubik_preprocess_page using the function _rubik_icon_classes. This doesn't do any XSS filtering on the page path, so someone malicious could use a path that contains a single quote and put whatever they like in the page. For instance, the path /admin/build/imagecache/%27%3Cbody%20onmouseover%3D%22prompt%28%29%22%3E exploits this, and will give you the following markup.
<h1 class='page-title path-admin-build-imagecache-'<body onmouseover="prompt()"> path-admin-build-imagecache path-admin-build path-admin'>
I've verified this on the Drupal 6 version, and it looks like it's still a vulnerability in latest 7.x-4.x-dev code. I'd recommend fixing this by putting the $path variable through the filter_xss function.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1425122_filter_path_class.patch | 555 bytes | greggles |
Comments
Comment #1
ericduran commentedlol, This is not supposed to be a public issues :-/
Comment #2
ericduran commentedIn the future please use this as a guideline for reporting security issues http://drupal.org/node/101494
Comment #3
gregglesHere's a patch for 6.x. It requires #1443012: backport core drupal_html_class and drupal_clean_css_identifier.
Comment #4
greggles@ericdruan's advice is generally right, but per the security advisory policy this can be handled in public because it affects a theme that doesn't have a stable full release http://drupal.org/security-advisory-policy
Comment #5
coffeymachine commented@greggles Thanks for the patches. The patch here in #3 actually broke the icon CSS because it was chaining a bunch of classes together since drupal_html_class replaces spaces with hyphens. I ended up putting the wrapper in _rubik_icon_classes itself.
I made the fix on both the 6.x-3.2 branch as well as the 7.x-4.x branch and will be posting new releases of both versions shortly.