CI框架中的SQL注入隱患



0x00

在CI框架中，獲取get和post參數是使用了$this->input類中的get和post方法。

其中，如果get和post方法的第二個參數爲true，則對輸入的參數進行XSS過濾，注意只是XSS過濾，並不會對SQL注入進行有效的防範。

例子：

Controller中，定義一個shit方法，獲取get數據：

指定了第二個參數爲true：

（1）XSS測試

（2）SQL注入測試

並不會對單引號進行處理。

 

0x01

在CI框架中，儘量使用AR類進行數據庫查詢是比較靠譜的，因爲在底層會幫助使用者進行一次有效的轉義，但也僅僅是轉義而已。

過濾的方法是escape_str() ：

 

function escape_str($str, $like = FALSE)
{
    var_dump($str);
    echo "\n" ;
    if (is_array($str))
    {
        foreach ($str as $key => $val)
        {
            $str[$key] = escape_str($val, $like);
        }

        return $str;
    }

    if (function_exists('mysql_real_escape_string'))
    {
        $str = addslashes($str);
    }
    elseif (function_exists('mysql_escape_string'))
    {
        $str = mysql_escape_string($str);
    }
    else
    {
        $str = addslashes($str);
    }

    // escape LIKE condition wildcards
    if ($like === TRUE)
    {
        $str = str_replace(array('%', '_'), array('\\%', '\\_'), $str);
    }

    return $str;
}

 

 

 

 

該方法僅僅是調用了一些轉義函數，並對like參數進行過濾。

如果查詢的變量沒有被單引號包裹，那麼就無法進行保護：

 

 

0x02

AR類的過濾方案是沒有考慮數組的key值的，縱觀各大CMS出現的SQL注入，由於數組的$key過濾不嚴直接帶入SQL查詢的漏洞屢見不鮮。

輸出爲：

 

0x03

CI框架開發速度快，輕巧，並且不用單獨學習一門模板語言也可以使用。但是如果對CI框架中自帶的安全機制理解不透徹，會導致無窮無盡的漏洞。

 

 

瞭解本專欄 訂閱專欄 解鎖全文