security curmudgeon mentioned:
> /portfolio.php?cat_id=[XSS]
Based on source inspection of 1.0.2, this parameter is cleansed.
line 31 of portfolio.php says:
$catId = $dbFilter->db_clean_input($_GET['cat_id'], 'integer');
which looks like it's going to do input validation as an integer.
BUT... did it do this properly?
Let's go to the definition for db_clean_input...
includes/classes/class_db_input_filter.php:
> class db_input_filter{
>
>...
>
> function db_clean_input($input, $inputType, $quoteValue=1){
>
> $this->input = $input;
> $this->inputType = $inputType;
>
>...
>
> switch($this->inputType) {
> case 'integer':
> if(ereg("^[0-9]+$", $this->input)) {
> $this->input = (int)$this->input;
> } else {
> $this->errorMsg = "Input does not match specified type (integer).";
> return false;
> }
Notice the ereg() call. It cleanses the input ONLY if it consists of
all digits. Otherwise, the function returns 'false'. The program
doesn't check if a bad value was provided, but still, this would have
the effect of setting the $catId variable to a blank value.
In February 2006, the developer also offered a "IPG Security Patch
1.0.1" which includes the portfolio.php file that is now in 1.0.2, so
maybe the portfolio.php/cat_id vector only applies to versions of
Instant Photo Gallery BEFORE 1.0.2.
portfolio_photo_popup.php / id is more clear:
>$image_id = isset($_POST['id'])?$_POST['id']:$_GET['id'];
>
>count_click($image_id);
and in includes/functions/fns_std.php:
>function count_click($image_id){
> db_connect();
> $sql = "SELECT * FROM " . PDB_PREFIX . "image_ratings WHERE id = " . $image_id;
So, we have direct SQL injection using the "id" parameter, which
produces resultant XSS if the SQL query is malformed in an
XSS-friendly fashion.
- Steve
