XSS in UserSettings

[sakaru@…]

PoC:  http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://wiki.whiteacid.org/UserSettings&action=login&name="><script>alert('xss')</script>&password=&confpassword=&email=

When the login name is entered but no password is entered the user is sent back to the login form. What the user entered is then pasted back into the login name field. Insufficient filtering means JavaScript can be injected, such as injecting: "><script>alert('xss')</script> will create an alert box.

[sakaru@…]

I've fixed the flaw on my site so the old PoC no longer works. To fix it change line 498 in /actions/usersettings.php to: <td><input <?php echo $username_highlight; ?> name="name" size="40" value="<?php if (isset($_POSTname?)){ echo htmlentities($_POSTname?,ENT_QUOTES); }?>" /></td>

Working PoC:  http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://wikkawiki.org/UserSettings&action=login&name=%22%3Easd&password=&confpassword=&email=

[Amgine@…]

Although this is a vulnerability, it is not a risk to the site or system. It is, however, a potential risk to referred users.

[DarTar]

I second Amgine's opinion - but many thanks for reporting this, sakaru. The fix will be included in the dev code.

[DotMG]

It can be a potential risk to the site or the system, but I won't explain why until this bug is fixed and version 1.1.7 released.

Anyway, it can lead to invalid xhtml.

[DotMG]

fixed in [204]

[DotMG]

Refixed in [205] : Previous changeset ([204]) made unable to connect if password contained special characters.

[DarTar]

Mahefa,

I see [205] didn't remove the new GetSafeVar() method you introduced in [204]. Is this made on purpose? When introducing a new core method, I suggest we share the announcement/discussion with other devs so we know how to use it.

[DarTar]

(bumping) Mahefa, see my last comment.

[DotMG (not logged in)]

OK! GetSafeVar() is just a way of doing

return ($this->htmlspecialchars_ent($_POST['var']));

with some checks if 'var' is transmitted via the correct method. Some internet hacks exploit the fact that you assume a certain parameter is transmitted at certain circumstances, and your code throws warnings (that reveal delicate information as the arborescence of your server) when you use strict error reporting and when these parameters are deliberately absent.

The method is still used in usersettings.php, but it doesn't just accomodate with password, and only with password.

[JavaWoman]

changing milestone to 1.1.6.3 security release

[JavaWoman]

reopening for 1.1.6.3 (note it's fixed in trunk!)

[JavaWoman]

Changesets [383 and [384] apply these changes to the 1.1.6.3 branch.

Closing the ticket again since it was reopened only for this branch