The report is invalid. None of the specified URLs are exploitable.

1. action.php: has include('./config.php'); as first line. config.php defines $DIR_LIBS.
2. media.php: same thing: included config.php first, via a fixed path.
3. xmlrpc/server.php: again, the same: includes config.php via a fixed path.
4. xmlrpc/api_metaweblog.inc.php: this one is just funny, since this file doesn't execute any code when called (it's included from elsewhere). The only thing it does is composing an array and defining a number of functions.

Including config.php as soon as possible, via a safe path, is crucial to Nucleus security: including config.php defines crucial variables (like DIR_LIBS) and bootstraps Nucleus (including security checks: that's why you'll receive a "Sorry, an error occurred" error message when trying these URLs)

The previous security issue, which led to the release of Nucleus v3.23, was possible because PLUGINADMIN.php has no reliable way of knowing where it is executing, and therefor cannot include config.php in a safe way. Instead, this file is included from plugin admin areas, which include the config file first. Should have called the file PLUGINADMIN.inc, actually.

Anyway, there's no need to worry about this report. You're only vulnarable to it if you've got an empty config.php file, and in that case, your site won't function anyway. As far as I know, Nucleus v3.23 is safe to use.

Short term solution was to disable these two parts of the site. An upgrade to another hosting plan has also been started. Once complete, we'll re-enable the temporarily disabled sections.

Lately, I started creating some actual documents: spreadsheets. That worked fine. Hurray! The utter user-unfriendlyness (mainly when editing charts), didn't really bother me. Hey! It's free.

Next task: setting up a small database with OpenOffice Base... My first attempts to create tables with some inter-table relationships eventually resulted in an OpenOffice crash, which rendered the entire database file unusable. That's like... a bummer.

It took a couple of days before I got my courage back and started over. One single table with some views and forms this time. No fancy options. During the next week, I entered some data.

Today, after adding an extra boolean field in the main table: BOOM! OpenOffice started spitting out SQL errors. I couldn't even access the table in question. Bye Bye data!

Things like these make me slowly turning into a Microsoft fanboy. Really. Putting the user in control rather than the software.

Ok, the Branch-NewAdminArea was created. These files and the libs directory were branched:

/nucleus/nucleus/bookmarklet.php
/nucleus/nucleus/index.php
/nucleus/nucleus/media.php
/nucleus/nucleus/libs/

For information on previous tags and branches, see the archive for the CVS category.

I ran into a similar situation while making changes to automatically activate an ActiveX control.

Because of the Eolas patent, which describes how a browser can use external applications, Microsoft is planning to release an update for Internet Explorer where users will need to click an ActiveX control before it becomes active. MSDN subscribers can already download a test release of this update.

Creating webpages with controls that respond directly to user input is still possible, by creating the object dynamically from an external JavaScript file. Because the file is external, it's not a violation of the Eolas patent (I think). The technique is described on MSDN . I based my code on this article and ended up with something like this:

...
var obj = document.createElement('object');
obj.classid= "clsid:xxxxxxxx-xxxx-...";
...
container.appendChild(obj);

This worked magnifically: the control loaded and was activated immediately. One big problem however: the ActiveX control was unable to access the IWebBrowser2 interface of the top level browser. The control accessed this interface as described in KB257717: How To Retrieve the Top-Level IWebBrowser2 Interface from an ActiveX Control, from the OnSetClientSite method. The interface was then used to get the URL location and switch to/from full screen mode.

As I eventually found out, the reason for this malfunctioning had to do with object context. As long as the created object element has not been added to the document, there is no top level browser window. The OnSetClientSite is called when setting the classid, so it fails.

The solution, as in my previous post, is to add the element to the document tree as soon as possible, before filling out the classid:

...
var obj = document.createElement('object');
container.appendChild(obj);
obj.classid= "clsid:xxxxxxxx-xxxx-...";
...

<?php
  $i = 1;
  $i += $i++ + ++$i;
  echo 'i=', $i;
?>

Bonus question: Is the result always the same in other programming languages (JavaScript, Java, C#, ...; provided the syntax is adapted to the host language :))? Why (not)?

Check it out!

Goal Conversion

Google Analytics allows you to set up "goals", and track how much visitors are "converted" to that goal. For the Nucleus CMS site, the only appropriate goal I could think of was the downloads page. While visiting the downloads page is in no way an indication that the visitor will actually download the package, it does give an idea of how much visitors have the intent to download.

The goal conversion (amount of visitors of downloads page / total visitors) for the "Download" goal is at a steady 13-15%.

Browsers

Internet Explorer is still used by about 50% of the visitors. Luckily, 97% of these are using IE6, which is good news. Firefox -- at 39% --, has a wider range of different versions.

Countries

Fascinating: almost 11% of our visitors is from Japan.

Version Check

In the Nucleus admin area, one can click the version number to do a manual version check. When the admin area is linked from the main site, this link is often followed by search engine bots, giving a global idea of which Nucleus versions are most common:

If this graph is representative, it indicates that 40% of the users are still using v3.2 or v3.21...

Maybe we need an automatic check which starts displaying a message once the version is out of date. This check could run when visiting the admin area, if the previous check was more than e.g. 7 days ago. The result (+date of last check) could be stored in the database.

How to maintain a spam-free site, without annoying your users? That's the question.

One idea would be to make the captcha-generating code more intelligent. The NP_Captcha Nucleus plugin already does this in a limited way, by not generating challenges for registered site members. But that's only a start. There are a lot of possible tweaks.

How about never displaying the captcha challenge immediately? After the user hits the submit button, a set of rules (blacklist, heuristics, ...) could be used to identify a comment as "likely being spam". Only in such a case, the user would be presented with an actual captcha challenge:

Result: in most cases, a user can post comments without interference of any kind. Only when a message has spam-like characteristics, an extra step is required.

How about the visually impaired, I hear you ask? The captcha should be accompagnied by an alternative audio-challenge. The challenge for developers here is to make such an audio file as good in telling computers and humans apart as a visual captcha. One site where I saw an audio captcha in action was the Passport registration wizard.

By the way, the same technique could be applied without the captcha. If the post looks like spam, the user could be allowed to fine-tune it, rather than dropping the post immediately. This is something which has annoyed me in NP_Blacklist in the past: a valid comment was seen as spam, a redirect to the spamtrap page occurred, and hitting the back button returned to an empty comment form :(

Just a bunch of thoughts...