I have a client who has a large member organization for canine handlers.  Most are police officers training for drug and bomb detection.  They want a forum for their site, if it can be secure, and I am exporing more options for their members in to interact with using your product.  My client's main concern is with how easily one can hack into a member area.  He told me he had heard it was easy to hack into a forum, and I did a quick google search on-line only to find tons of listings showing how easy it was.  I watched a few and learned for myself that his friend was correct.

Can you please comment on this with regard to Wiccle?  I would need to know the reality of it and would not want to enter into it if it was a potential problem.  Thanks so much,

There are a great number of ways in which to go about hacking a website, a forum or otherwise. Aside the obvious (compromised password access and brute force hacking), there are SQL injections, XSS injections, malicious uploads, user input modifications and filtering in general, and certain security areas internal to the software to consider.

I keep my level best tabs on the world of web application hacking to stay on top of things. Many of the large community applications, and forums in particular, are frequently the target of new exploits, simply because their code isn't screened carefully enough for vulnerabilities, or isn't structured well enough to allow such screening. Software users contribute to the poor security scenario by keeping out-of-date versions online for months on end, and then wondering why they got hacked.

As a general principle, Wiccle CMS Framework code architecture narrows possible points of exploit down to a manageable handful thanks to sufficient abstraction, and as such the bases to cover are much fewer than in many other complex web applications. Over our last year of public releases, and in particular with the iWiccle 1.2x series builds, security has been beefed up to what I see as a very solid standard. Here are some notes on the areas of concern in web application security.

SQL Injections. All SQL queries across the software are filtered for injection attempts, and I routinely double-check for omitted filtering software-wide. Last omissions I spotted were several months back, and in areas one'd have a hard time plugging into.

XSS Injections. All HTML input is a) filtered by TinyMCE, b) filtered against a white-list configurable in the Admin CP, and c) stripped of all evasive characters, mashed together and matched against all known XSS vectors, and d) on positive match an XSS alert is logged in system logs, and the entire HTML input stripped of tags. I have tested this (along with some new inventions) against the ha.ckers.org XSS vector cheat sheet by RSnake, which is almost identical to the test cases used by HTMLPurifier and other such larger HTML filtering applications. (They cause a bit too much overhead to my taste, but if someone wants to hook in extra filtering levels, it's very easy --- just let me know.)

Path traversals. All variables in user-initiated queries specific to files or filesystem are filtered against a whitelist of allowed characters and strings, eliminating both path traversal attacks and remote file fetching attempts in certain scenarios. In general, user input is filtered across the system in order to eliminate unwanted user behavior.

Malicious uploads. Uploads are matched against a whitelist of allowed filetypes, and upload permissions can further be restricted to known users. Clam AV virus scanning and advanced MIME recognition are something in the works for the future.

Cookie and Session Theft. To protect against compromized login cookies, WWB stores user passwords as salted SHA1 hashes combined with a random hash rotated on each consecutive login, invalidating the old access cookies. No unhashed passwords are ever stored anywhere, and passwords stored in cookies are double-hashed to make them completely impossible to reverse by matching against rainbow databases.

General tracking. WWB keeps system logs (available in Admin CP > System Logs) of five levels of alerts: Output errors, PHP errors, SQL errors, XSS alerts, and Admin login failures. System logs are logged with IPs and linked with the user causing the error, making malicious user tracking and banning much easier.

Atop the above, which is well within what I consider a decent industry standard for web security, there's more in the way of security both in the current system as well as in works for future releases, from advanced content spam filtering onward to automated filesystem integrity checks and reporting. If you are interested in or concerned over some particular areas of security, please let me know and I'll get back to you with more detail.

We try to stay on top of things, and until otherwise reported, I consider the current iWiccle and WWB build adequately secure for production use. Should vulnerabilities surface in the future, they take precedence over all other development work, and we will release necessary patches within 24 hours of my receiving notice of the issue. To date, we have had one published vulnerability --- in the early iWiccle version 1.01, discovered in the summer of 2009 by a certain Romanian hacker (who received a thank-you mail and a pat on the back to keep up the good work) .

Added Note: The vulnerability of the first version release of the iWiccle Community Builder could only be caused when you were logged in as Admin to hack yourself!  

There was actually also a public path traversal component to it (details), which was available if magic_quotes are off (generally on by default in PHP), where neither open_basedir nor safe_mode restrict fetching files from above the site root area, and where your other directory structures contain sensitive information in readable format in a place that can be guessed, but not in a PHP file. At the time it was reported, the patch advisory was also immediately forwarded to Secunia and other major security sites reporting the issue.

In all honesty there may still be a place or two in the Admin CP where you can cause something exotic, but really, if you have Admin access and want to hack your own site, or if a malicious user has Admin level access to your site, you have other sorts of problems at hand...