In the last few days I've seen two issues reported with Joomla!, both of them invalid. The first of the issues I saw was a legitimate problem that we had ended up fixing. This problem in particular only occurs when third party developers alter our tables errorneously injecting invalid data (see my blog post earlier about not hacking the Core) and whilst the reporter had said that they had replicated it on 1.5.8, the sample they provided didn't work because we had fixed the problem for 1.5.8's release. Whilst a 'symptom' of the bug appeared in cases, the actual issue didn't resurface. The lesson here is that even if it looks the same you need to work through the entire process to reconfirm the bug before reporting. It is also a case for keeping up with the latest release because we do fix other issues as well as security.

The other issue that I saw was a "0day vulnerability in the wild". Thats the sort of email subject that we are especially alert to and follow up immediately. The issue in question was to deal with the way we handle password reset tokens and the reporter claimed that there was a potential for SQL injection via the token entry form in the reset part of the user component. They provided the steps replicate it and also provided the solution which I will copy here for reference:

Proposed fix:
      In ./components/com_user/controller.php
              In function confirmreset():
      Between the two lines:
      ----------------------------------------------------------------
         $token = JRequest::getVar('token', null, 'post', 'alnum');

         // Get the model
      ----------------------------------------------------------------
      This should be changed to:
      ----------------------------------------------------------------
         $token = JRequest::getVar('token', null, 'post', 'alnum');
         $token = mysql_real_escape_string($token);
         // Get the model
      ----------------------------------------------------------------

As we can see the issue in the reporters mind is that JRequest::getVar needs to have its input escaped (the addition of mysql_real_escape_string). Lets just have a look at getVar: its a function that takes five arguments with the fourth being the "return type for the variable, for valid values see JFilterInput::clean()". In this case we've selected "alnum" which is the alphanumeric filter. This filter strips anything that isn't a number or a letter, which is good since the token should be hexadecimal anyway. This is also makes the mysql_real_escape_string rather pointless because it just returns the string back anyway. However the next part that gets called is the reset model's "confirmReset" function which gets this token passed to it and has the following line:

$db->setQuery('SELECT id FROM #__users WHERE block = 0 AND activation = '.$db->Quote($token));

As we can see here the token gets run through the Quote function of the database class. If we look at this function it takes two arguments, the first being the string and the second being a switch to toggle 'escaping' the text which is defaulted to true. The net effect of this is that it eventually calls "mysql_real_escape_string" in the database driver, which is the item that the reporter originally suggested. As a side note we try to avoid using "mysql_real_escape_string" in these places because the user may not actually be running on MySQL, which is why the database adapters provide the string escaping functions. This way if the user does switch database systems the string is still appropriately quoted.

So whilst its great that we have people reporting issues, try to test and replicate the issue before you send it to us. In both of these cases actually trying the issue would have shown that the problem had been fixed or didn't exist.