So... Missing one topic about Cross-site scripting? About hacking miniBB, stealing identity and deleting topics?

For all team members: I hope that now you see what you can do using an evis script inside images. Please, do one thing - change the method of deleting topics. Don't send topic and forum id via GET, but POST. That's the only way you can prevent any further hacks.

Thank you.

Hey Charlie,

yes the hack is actually working, thank you for proving that. Could you contact me in private and provide the script you did for .htaccess'ed image? Email is ghappa [at] gmail dot com.

Unfortunatelly, I think, the POST method you suggest could be hackpassed as well. For example, using CURL commands which send POST request instead of GET and that way it will work too I suppose.

Second why we would like to avoid changing deleting routine, is because it will require a lot of changes, not only in the core, but also in some plugins. Additionally, JavaScript alerting will also require a lot of modifications.

How did you come up to this hack? Have you seen this in other BB software? I would be really interested in simple workaround on this. This hack got us stunned, because nobody from us still can not imagine an effective solution.

I discussed it with a friend of mine today (thanks to Charlie's very discrete and sensitive announcement of this problem and making the script available as public service someone also tried it on my miniBB installation) and he recommended that you should look at punBB source - if I understand it well, while it also uses GET method, some additional confirmation effectively disables the post/thread deletion (although the GET request is processed, no automatic deletion occurs).

I wish I would have time to study punBB's code :-)

Well, I've come up with another solution, so called "tokens"/"hidden fields" as suggested on Wiki - each time when user logs in, a special cookie with random value (each time new value) is being set. The hacker naturally can not know this cookie's value. So when admin/moderator clicks on the delete link, JavaScript GETS this cookie's value (getting values works perfectly in IE and all major browsers I hope), then concatenates deletion URL with this value, so this value is still not visible in the page source, never. Deletion script gets this value in the GET request and compares with the value which is set in cookie; if they are not identical, deletion fails.

In the terms of the speed it doesn't require a lot of resources: this cookie is being set only once when a member or admin is being logged in. It will be deleted when the browser is closed, and re-generated when it's opened. It is read only when topic or message is being deleted, so basically the resources it uses are closely to zero.

I've temporary updated miniBB forums only following this solution, and my colleagues agreed it's the best in the term of the security/simplicity. However I will wait for other comments regarding this to be sure this is exactly how we would like to fix this issue. Basically, it requires update only of 4 scripts and a template, which contain just few lines of the new code.

Ok this was fixed in the version 2.0.5.