FS#820 XSS in "Update your account profile" and "Register"

Security

• 

  2006-05-31 Kremser

  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.
• 

  2006-05-31 ChrisS

  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()
• 

  2006-05-31 ChrisS

  That should be x00-x1f  (decimal 00-31)
• 

  2006-05-31 Kremser

  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.
  
• 

  2006-05-31 ChrisS

  I take it you mean http://en.wikipedia.org/wiki/Internationalized_domain_names ?
  
  That'll be another feature request ;)
• 

  2006-05-31 andi

  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.
• 

  2006-05-31 andi

  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']));
• 

  2006-05-31 Kremser

  >> 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.
  
• 

  2006-05-31 Kremser

  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. ;-)
• 

  2006-06-04 andi

  In the package available for download this bug was fixed.