turn off global xss on login page

[eluser]Unknown[/eluser]
Okay, so this is what the problem is... I have global xss turned on so it sanitizes _post and what not.

However, I have a lot of users who use special characters in their password for security requirements so CI is converting them and making the password invalid.

How can I leave the global xss on but not sanitize the login page _post vars with its xss_clean function?

I thinking I need to do some kind of hook to turn it off specifically for that controller but just wanted to see what you guys thought.

Thanks

[eluser]Pascal Kriete[/eluser]
It's hardcoded into the input library, so there's no easy way to do it. You could extend the input library though.

application/libraries/MY_Input.php

Code:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

class MY_Input extends CI_Input {
    
    function MY_Input()
    {
        log_message('debug', "Input Class Initialized");
        
        $URI =& load_class('URI');
        $CFG =& load_class('Config');
        
        // Change this to match what you need
        if ($URI->segment(1) == 'login')
            $this->use_xss_clean = FALSE;
        else
            $this->use_xss_clean = ($CFG->item('global_xss_filtering') === TRUE) ? TRUE : FALSE;
        
        $this->allow_get_array = ($CFG->item('enable_query_strings') === TRUE) ? TRUE : FALSE;
                
        parent::_sanitize_globals();
    }
    
}
// END MY_Input class

/* End of file MY_Input.php */
/* Location: ./application/libraries/MY_Input.php */

[eluser]onejaguar[/eluser]
Rather than change the core libraries you could do a "pre_system" hook that does something like:

Code:

if (isset($_POST['login_password'])) {
    global $login_password;
    $login_password = $_POST['login_password'];
}

and then retrieve the global variable in your login controller. Of course I would recommend not using global xss_cleaning in the first place; it has many of the same problems (and more!) which eventually caused PHP developers to bury magic quotes.

[eluser]Pascal Kriete[/eluser]
There are other issues involved. If you have a registration form or change password forms, those will need to be excluded as well. I also prefer to not xss_clean globally for that reason. However, for user generated content you should always use it. Cross-site scripting is nasty, and in some cases very hard to detect.

[eluser]onejaguar[/eluser]
I agree, any user input which will be displayed elsewhere on your site should be put through xss_clean or something similar, but content which is validated in another way (eg. checked with ctype_digit, put through validation's alpha_numeric, valid_email, etc.) does not need to be cleaned; and any data which will not be re-displayed to other users (e.g. passwords) does not need to be cleaned.

Xss_clean is also very blunt in some cases, for instance in this forum typing
"Use this javascript{colon} "
or
"I made a funny facial expression (like I always do)"
gets turned into
"Use this [removed] "
and
"I made a funny facial [removed]like I always do)"

The worst part is, it doesn't show up in the preview so I don't see my post is mangled until after it is submitted.

Also, any HTML content will getting totally destroyed so WYSIWYG HTML editors need other forms of validation anyway.