This is the issuetrackingsystem for DokuWiki. You may add bugs and feature wishes here. Please post support requests in the Forum.
To prevent spamming anonymous task adding had to be disabled. Your account here is valid as login for DokuWiki, too.
Please read wiki:bugs for help with the bugtracking system
Always perform a search on both open and closed tasks before
opening a new one; your bug might already have been reported.
FS#820 — XSS in "Update your account profile" and "Register"
Attached to Project— DokuWiki
Opened by Gert Kremser (Kremser) - Wednesday, 31 May 2006, 09:41AM
Last edited by Andreas Gohr (andi) - Wednesday, 31 May 2006, 08:55PM
Opened by Gert Kremser (Kremser) - Wednesday, 31 May 2006, 09:41AM
Last edited by Andreas Gohr (andi) - Wednesday, 31 May 2006, 08:55PM
| Bug Report | |
| Security | |
| CLOSED | |
| No-one | |
| All |
| Low | |
| High | |
| 2006-03-09 | |
| Undecided | |
| Undecided | |
 |
Hello,
the Fullname and E-Mail fields in "Update your account profile" are vulnerable to XSS attacks.
The Fullname is copied directly to the configuration and will be presented to the user as "Logged in as: " + XSS vector (may include visible parts such as the real username).
A possible harmless attack vector could be "Username<script>alert("Hello World!");</script>".
The problem is in function updateprofile() in inc/auth.php in line 543 and 544 where the post parameters 'fullname' and 'email' are assigned unfiltered.
The same problem exists in the function register() in line 485.
In an additional review the parameter 'login' should also get checked for XSS vulnerabilities.
the Fullname and E-Mail fields in "Update your account profile" are vulnerable to XSS attacks.
The Fullname is copied directly to the configuration and will be presented to the user as "Logged in as: " + XSS vector (may include visible parts such as the real username).
A possible harmless attack vector could be "Username<script>alert("Hello World!");</script>".
The problem is in function updateprofile() in inc/auth.php in line 543 and 544 where the post parameters 'fullname' and 'email' are assigned unfiltered.
The same problem exists in the function register() in line 485.
In an additional review the parameter 'login' should also get checked for XSS vulnerabilities.
This task depends upon
This task blocks these from closing
Date: Tuesday, 06 June 2006, 08:02PM
Reason for closing: Fixed
Can you confirm that email is vulnerable. It shouldn't be. The provided email string is tested for a valid email address in both 'register' & 'update profile' and the function immediately aborted on a fail.
Login is processed using the same filter as page names and shouldn't be an issue.
For username, I can see two possible solutions:
- apply a restrictive character set be to username - e.g. prevent <,&,%,>,x00-x31. any others?
- filter tpl_userinfo output using hsc()
That should be x00-x1f (decimal 00-31)
I took only some minutes to look at that function after I found the problem with the fullname.
My quick and dirty solution was to HTML-Encode the POST parameter in the above described lines.
if ($_POST['fullname'] != $INFO['userinfo']['name']) $changes['name'] = htmlentities($_POST['fullname']);
Your first solution will be from the security perspective the optimal way, but less functional indeed. ;-)
As I see in the mail.php the new assigned domainnames will not be allowed, maybe this should be adapted in one of the next releases.
I take it you mean http://en.wikipedia.org/wiki/Internationalized_domain_names ?
That'll be another feature request ;)
Hmm I cannot fully reproduce this bug with a current devel version. I can confirm that the attack string is written to the user file, but for some reason it is completely stripped from the username when outputed in the "Logged in as:" line!? However I agree, that we should add some stripping. An utf8_stripspecials() should be probably enough?
From what I can see, this XSS bug is hardly exploitable. Because you can add an attack string to your own name only, which is only displayed to your self you can not use it to get other user's info (cookies). I lowered the severity of the bug report - correct me if I'm wrong.
Okay. I'm somewhat slow in the head today. The reason why the attack code wasn't executed right away was because it works after a new login. Using utf8_stripspecials doesn't work because it strips spaces. I changed the cleaning of username and mail to the following line in register() and update_profile():
$_POST['fullname'] = trim(preg_replace('/[\x00-\x1f:<>&%]+/','',$_POST['fullname']));
$_POST['email'] = trim(preg_replace('/[\x00-\x1f:<>&%]+/','',$_POST['email']));
>> From what I can see, this XSS bug is hardly exploitable.
In a honest world you might be right, but if the wiki administrator is malicious he can figure out the other users passwords.
If these users reuse their passwords, he may gain access to other systems.
So I would say, this issue should be rated at least as medium.
I think, i have to add some explanations.
After a normal login the user can be redirected to a phishing-like login page, where he is prompted to put in his credentials once more.
Another possibility is to redirect the user to a contaminated web page with trojans or other bugs on it. ;-)
In the package available for download this bug was fixed.