vulns

[anon]

http://www.securityfocus.com/bid/14404
http://www.securityfocus.com/bid/14406

[Ryan]

Hmm, it is sad that these links don't really explain any problems.
Could anyone help diagnose the problem - it is a little to little info for me.
I am guessing these two things have to do with the code module and the media section.

[hudge]

Well I am glad to see that people are getting involved and spreading the word. Too bad they would not post a screename. These features are understood by the administrator. IE if you allow someone to access your site, they can do bad things. Yes limits can be put on and will most likely be there in version 3.

Overall this software is GREAT! Spend some time and see for yourself.

[Ryan]

What I want to know is if these "Vulnerabilities" can be used for people  that do not have an account (i.e. can anyone just go to your website and do the reported things [which i am yet to figure out are]), or do you have to login to the Administration to do these things - if so then it can easily be limited using correct permissions).

[KenZo]

Remote: Yes (via web dus)
Local: No (locale server)

(nl: duidelijk)

[tgo]

I thought I put my details in the post I did when I showed these vulns but I guess not. About the vulns: The cross site scripting one can be done by anyone with access to browse.php. The file upload one is way more dangerous because whoever has access can upload any file type they want such as php and then have php files on the server.  I dont remember exactly if this product had a file that was included for a conenction to the database, but most do, and so with this php file someone uploaded they could include the connection file and then run any query they wanted on the database.

feel free to email me if you want i put my addy in the post

[tgo]

if you want more details check my original post at

http://bluelightningblade.com/papers/wb.txt

[Ryan]

These "security vulerabilities" make things seem much worse than they really are.
These are not really security holes - it is just the way the features work.

If you don't set things up right, you can leave things dangerously vulnerable.
It is like any computer - if you just plug it in "as is", without configuring user accounts and groups with proper permissions, anyone can do anything to a system (well, for Windows this is the case).
However, if configured correctly, only trusted people can do serious things.

Although it is not really a security hole, there are measures that can be taken to prevent these problems, such as disabling certain file-extensions for media.
These features will most likely be added in 2.5.3 (or 2.6.0), just to make things more flexible.
 

[Ryan]

A forum member contacted me regarding the "vulnerabilities", here are the solutions I provided him with until I release another WB2:
- If you are on a shared host, make sure that the PHP error reporting level is set to 0 (found in config file). This way, paths should not be disclosed.
- If you cannot trust your users, a quick fix on an Apache server: you could put a .htaccess file under the media folder that blocks execution of certain file extensions.
By taking these two measure, the two security vulnerabilities become irrelavent.
 

[Ryan]

Just letting you all know that all the known "security vulnerabilities" will be fixed/have been fixed for 2.6.0 (to be released shortly - see here), not that they were that serious anyways

[fjord]

Hello!

Some of you authorities should update the Secunia database, the current status is unresolved. Then WebsiteBaker will get a top ranking on this vulnerability portal.

Check out this excellent status report: http://secunia.com/product/5455/

Thanks for keeping security focus!

Fjord