Sankuru

In its original version, the RsMonials component is vulnerable to security attacks, such as SQL injection and XS Scripting, because the standard Joomla 1.5 security guidelines were neglected. Let's have a look at the code and identify the areas where things go wrong.

Joomla automatically protects from most exploits, if you use the JRequest and the JTable classes for handling information submitted through forms. JRequest will filter the information for malicious HTML and counter XS Scripting attacks (XSS), while JTable will enforce proper escaping rules and counter SQL injection attacks (SQLI). Therefore, it is not even that hard to avoid the most glaring security vulnerabilities in your own source code.

Of course, there are other security attack classes, that are more subtle and more complicated to counter. But then again, if you protect your users from XSS and SQLI, you have probably countered 97% of the typical attacks that anybody could reasonably expect. XSS and SQLI are truly the low-hanging fruit.

Introducing the use of JTable requires more changes than just fixing the offending lines. Therefore, I manually escape the unescaped $_POST variables. It is a quick and dirty fix, but it does fix the SQLI vulnerability. It takes less effort to fix the XSS vulnerability, because it is possible to just surround the offending variable accesses with sanitizing JRequest::getString() invocations.

function submit() {

/* ... THE SOURCE CODE WILL ONLY DO VALIDATION HERE
NO GLARING SECURITY ISSUES...
*/

/* ------------------------------------------------------------
/* THIS IS THE OFFENDING LINE
/* IT IS HIGHLY INSECURE
/* ------------------------------------------------------------
        $sql="insert into `#__".RSWEBSOLS_TABLE_PREFIX."`(`id`, `fname`, `lname`, `about`, `location`, `website`, `email`, `comment`, `date`, `status`) values('', '".$_POST['fname']."', '".$_POST['lname']."', '".$_POST['about']."', '".$_POST['location']."', '".$_POST['website']."', '".$_POST['email']."', '".$_POST['comments']."', '".date('Y-m-d')."', '".$tesistatus."')";

//THE STATEMENT ABOVE MAY WORK, BUT IS REALLY NO GOOD.

/* ------------------------------------------------------------
ACTION 1: ESCAPE UNESCAPED SQL QUERY VARS: NEEDED BECAUSE THE CODE DOES NOT USE JTABLE TO COUNTER SQLI
ACTION 2: SANITIZE USER INPUT: NEEDED BECAUSE THE CODE DOES NOT USE JREQUEST TO COUNTER XSS
/* ------------------------------------------------------------

        $sql="insert into `#__".RSWEBSOLS_TABLE_PREFIX."`(`id`, `fname`, `lname`, `about`, `location`, `website`, `email`, `comment`, `date`, `status`) values('', '".mysql_real_escape_string(JRequest::getString('fname',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('lname',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('about',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('location',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('website',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('email',"",$_POST))."', '".mysql_real_escape_string(JRequest::getString('comments',"",$_POST))."', '".date('Y-m-d')."', '".$tesistatus."')";


        $database->setQuery($sql);
        $database->query();

       
/* ... THE SOURCE CODE WILL ONLY DO POST PROCESSING HERE
NO GLARING SECURITY ISSUES...
*/

}

The solution consists in wrapping the access to the $_POST array in appropriate XSS-SQLI sanitizers:

 mysql_real_escape_string(JRequest::getString('fname',<defaultvalue>,$_POST))

Note that JTable fends off SQLI attacks already. Using JTable also simplifies the code, and makes it eminently more readable. I wholeheartedly recommend the use of JTable, instead of constructing your own SQL insert statement and fiddling with your own invocations of mysql_real_escape_string().

Voilà. The XSS and SQLI vulnerabilities should be mostly fixed now. I personally do not see any other additional security hazard in the source code, even though it is always possible that they exist. The only way to make sure that they get detected, is by having other people inspect the source code too.

As a source code author, you must always be ready to brace for additional security attacks, in the 3% attack classes outside XSS and SQLI; and act quickly to protect your user base. You must immediately make the decisive interventions in the source code, notify your user base, and pre-emptively counter any potential security assault on your users' systems.