Hi!
I was reading through the source code of minibb and found a potential CSRF vulnerability in bb_admin.php. At the moment, there are no checks for http referer header correctness or csrf tokens matching in this file. At the same time, in index.php both of these checks have been implemented to make the software more secure.
In the installation guide, it is advised to change the name of bb_admin.php to something else. This would indeed make it more difficult to exploit this as the attacker would need to guess the new name first. However, it seems that not all sites are following this practice... I had a quick look around minibb forums installed and found about 50% have not bothered to rename the default file.
The consequences of this kind of attack could be quite dire, if carried out on some forum. It would be possible to delete all forums and users. Therefore I think an extra layer of protection would not be too much. So, even if an attacker finds a default admin panel name or somehow guesses the new name, he could not take down the forums.
The most affected functions are those, that are irreversible - i.e. deletions. In this case both removeuser2 and editforum3.
Removeuser2 requires 3 parameters: action, userID and removemessages, which all can be obtained by the attacker quite easily.
Editforum3 takes 7 parameters: forum_name, forum_desc, forum_icon, forum_group, deleteforum, action and forumID. These can also be set / obtained.
So, a typical attack would look like this:
1. Attacker finds a forum with default admin panel name or guesses / obtains the name somehow
2. Attacker creates a special website, which sends requests to delete forums / users automatically upon opening
3. Attacker posts the link to this website with a good enough story so that admin would open it
To test if this indeed works I tried it against my own installation (version 3.0) and the public installation (version 2.5 I think). In both cases I was logged in as admin and I clicked a special link, which contained the following html:
minibb.com/forums/storage/screenshots/attack1.png
The result was that user 3 was gone, without admin knowing anything.
On my own installation I also tried to delete some forums with it. So, I went to a link, which contained the following html:
minibb.com/forums/storage/screenshots/attack2.png
And forum 5 with all of its contents was gone.
To try to fix this, I edited bb_admin.php, admin_editforum2.html and admin_removeuser1.html.
In the file bb_admin, I added the following lines:
if(isset($_COOKIE[$cookiename.'_csrfchk'])) $csrfval = $_COOKIE[$cookiename.'_csrfchk']; else $csrfval = '';
if (isset($_POST['csrfchk'])) $csrfchk=$_POST['csrfchk']; elseif (isset($_GET['csrfchk'])) $csrfchk=$_GET['csrfchk']; else $csrfchk='';
Now, I edited both forms to also include the csrf token:
<input type="hidden" name="csrfchk" value="{$csrfval}" />
And back in bb_admin.php, after both editforum3 and removeuser2 cases, I put this:
if($csrfchk=='' or $csrfchk!=$csrfval) die('Can not proceed: possible CSRF/XSRF attack!');
Now, when I tested these two cases again, the users or forums were not deleted even when the admin visited the attacker's site. Guessing this csrf value or intercepting unencrypted pages going to client is still possible but at least carrying out this kind of attack should be harder now than before.
I hope this information was useful and you can use my examples to try and fix this in some later version. In case this solution breaks something else, I guess I could also try some other ways of solving the problem (checking referer header could also work for example).
If you were already aware of this, then sorry. I just felt I had to report this problem. | 
