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?
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.
I can't reproduce this. It could be that he has some mod installed that's causing this.
I can't reproduce, either.
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().
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.
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]);
}
Ah. I missed the part of "Viewing the Post", and instead I viewed the profile.
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.
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?
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.