Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[F] Custom Profile fields - possible XSS?
#1
Hi,

I am using MyBB 1.4.4 and have one custom profile textfield users are required to fill in.
It seems it isn't properly escaped/checked when viewing threads.

For example when I specify something like "<script>alert("foo")</script>" it's getting executed by the javascript interpreter when viewing the post - I get an alertbox displaying "foo".
When viewing the profile itself the box isn't displayed though.

Is this a bug or do I have to validate the field myself?
#2
Dunno if this is a vulnerability or not but I know XSS is bad so I unapproved just in case.

PM sent saying to use the Contact Form with suspected security issues in future - they also asked to hear on the status of it, i.e. if it is a bug and if/when it's fixed, not sure what the protocol on this is and whether it's OK to tell them that.
MyReactions - All Plugins

Can you still feel the butterflies?

Free never tasted like pudding.
#3
I can't reproduce this. It could be that he has some mod installed that's causing this.
#4
I can't reproduce, either.
#5
To reproduce:

1. Create a new profile field (text or textarea)
2. Instert {$post['fidX']} into the template postbit_author_user where X is the ID of the profile field.
3. Insert <script>alert("foo")</script> into the field in your UCP.
4. Open a thread in which you made a post.

It could be seen as bogus because it is related to a template modification. But many users add custom profile fields to the postbit so it would be an advantage to run all profilefields through htmlspecialchars_uni().
Greets,
Michael
-------------
[Image: donation_drive_sig.png]
#6
Unapproved your post just incase, Micheal. I'll have to try this when I get back to my house where I have access to my localhost forums.
#7
Possible fix: Open the file showthread.php and search for:
// Get the actual posts from the database here.
Above add:
$custom_fids = array();
$query = $db->simple_select("profilefields", "fid");
while($fields = $db->fetch_array($query))
{
    $custom_fids[] = $fields['fid'];
}
Search for:
$posts .= build_postbit($post);
Above add:
foreach($custom_fids as $custom_fid)
{
	$post['fid'.$custom_fid] = htmlspecialchars_uni($post['fid'.$custom_fid]);
}
Greets,
Michael
-------------
[Image: donation_drive_sig.png]
#8
Ah. I missed the part of "Viewing the Post", and instead I viewed the profile. Toungue I can't try your fix until I get back to my dev PC however. It seems your fix will work, but I'll get to it tomorrow as I'm off then. Big Grin
#9
I really don't see how this is a "vulnerability" since the administrator himself must make himself vulnerable in the first place.

This is no more of a vulnerability then installing a plugin and we don't audit plugins do we?
#10
That's why I said it could be seen as bogus. But it could be a benefit because many users seem to use $post['fidX'] in the postbit. And as $post['fidX'] is available without any modification in any php file we could run it through htmlspecialchars_uni() just to ensure that there's no XSS possibility.
Greets,
Michael
-------------
[Image: donation_drive_sig.png]


Forum Jump:


Users browsing this thread: 1 Guest(s)