CodeIgniter provides a couple of convenient APIs for XSS filtering.
'global_xss_filtering' in config.php.
'xss_clean' rule for individual fields, when using the form validation library.
If you use this feature, does it avoid the need to escape fields when outputting them?
There are some situations where xss_clean will not protect you. Issue 470 includes this example:
public function index()
{
$name = $this->security->xss_clean('hover me" onmouseover=alert("XSS2") "');
echo '</div>Name:<input value="'.$name.'">';
echo '</body></html>';
}
The response from developers was that this is by design, and to suggest that $name should have been escaped using form_prep().
If you use set_value('field-name', 'default') in order to preserve user input when a form fails validation), that will ... attempt to call form_prep() for you. The caveat is that if you don't have the form validation library loaded, it won't escape the 'default' parameter. (Issue 1781, fixed in 3.0-dev).
If you are running the current 3.0-dev, then form_prep() is more specific about which characters it escapes. It should avoid XSS either way; it just has unexpected results in some situations. E.g. if you try to enter a literal "&" in 3.0-dev, and then the form fails validation, the field value will change to & without warning. This change was an attempt to work around problems with double-escaping (issue 1953).
Related
I am new to CI and had just updated an old app developed by 3rd party developer and as I try to create any new record I get the following error:
Unable to access an error message corresponding to your field name `Field Name` .(xss_clean)
I have read many questions and answers on how to make it work, however, I have also read that this is a bad practice and would therefore like to get rid of xss_clean completely, but I just cannot seem to find straightforward information for how to do it.
Any help or guidance is much appreciated.
xss_clean is no longer part of form validation. The alternative is not to use it, as xss_clean is doing sanitization and not validation.
xss_clean is part of security helper. If you need to do it, after validation you do a:
$this->load->helper('security');
$value = $this->input->post('formvalue', TRUE);
// ...where TRUE enables the xss filtering
... i think...
Also, you can enable global xss filtering in the config.php file:
$config['global_xss_filtering'] = TRUE;
Or if you want to remove then you have to find all xss_clean used in validation and remove.
xss_clean is used mainly with CI's form validation library. As stated in the comments, the best way to get rid of this error (if you don't need the features of xss_clean) would be to remove all instances of xss_clean from your validation rules.
Example of where you could find xss_clean in your app:
$this->form_validation->set_rules('username', 'Username', 'trim|required|min_length[5]|max_length[12]|xss_clean');
codeigniter form validation documentation
I am using Codeigniter form validation. In my registration form the Username field allows only numbers like 123456. I don't want this to happen.
My validation rule is as follows
'rules'=>'trim|required|alpha_numeric|min_length[6]|xss_clean'
I want to prevent users entering just numeric strings. Alpha numeric strings are fine, alpha strings are fine, but purely numeric ones are not.
To allow only letters
Add alpha to your rules and remove alpha_numeric from your rules
You can use this page as a point of reference for built in validation rules.
Edit:
Since you've clarified now.
To achieve this, there's no built in validation rule. You will need to extend the Form_validation library by creating a libraries/MY_Form_validation.php file. See this manual page on how to extend libraries.
In this file, create the following function
function at_least_one_letter($string) {
return preg_match('#[a-zA-Z]#', $string);
}
Then you can add the validation rule at_least_one_letter to your rules.
According to the codeigniter user manual :
You can also use any native PHP functions that permit one parameter.
I think in this case is_int could be used as your validation rule.
So, for instance:
'rules'=>'trim|required|is_int|min_length[6]|xss_clean',
Why does CodeIgniter's XSS filter only react through regular expressions on specific things instead of sanitizing all input in the first place regardless if the content is tainted or not? Also, why is this done during input and not on output (like it's supposed to be?)
Why does CodeIgniter's XSS filter only react through regular expressions on specific things instead of sanitizing all input in the first place regardless if the content is tainted or not?
This doesn't make much sense. How are we to tell whether or not something is "tainted" without checking it first?
By the definition of CI's xss_clean(), we don't always want to sanitize input. As you mentioned, it's the output that matters - and that's where we need to be mindful of XSS atacks. If we always "sanitize" input with CI's xss_clean(), then how would I, for one example, be able to post javascript or PHP code examples on my blog, or let users do it in the comments? It would end up getting [removed].
Also, why is this done during input and not on output (like it's supposed to be?)
You do have the option to enable the global xss filter in your CI config, which will run xss_clean() on $_POST, $_GET, and $_COOKIE data automatically before you can get your hands on it. This is the lowest level possible to protect you from yourself, bu the option is always available to instead clean the data explicitly. For example:
// With the Input class on $_POST data
$this->input->post('username', TRUE); // Second parameter runs xss_clean
// Using the Security class on any data
$this->security->xss_clean($username);
// Using the Form Validation class to automatically clean the input
$this->form_validation->set_rules('username', '', 'xss_clean');
Since you could still simply use $_POST['username'] instead, by enabling the global filter it will already be xss_cleaned for you. This is the lazy way to do it, and unfortunately once those globals are cleaned, there's no way to undo it.
If you are already aware of when and where XSS attacks can happen - you have the function easily available to use if you wish. Keep in mind that this does not magically make all data "safe", it merely prevents some of the more malicious code injection. Something more harmless like </div> will get past this filter. You should always be sanitizing input explicitly in an appropriate way for the context in which it is used.
I am using input->post to get data in my codeigniter project. I was assuming that this will automatically filter quotes and i don't need to use addslashes() / htmlspecialchars() functions.
But it don't check for quotes.
I tried also to edit core>input.php but didn't help. Enabling XXS in config also don't help.
Suggest me easy way to filter quotes so that I don't have to edit in all my pages.
the xss cleaner lives in system/libraries/Security.php in a method called xss_clean()
id say your best bet is to extend this class (i.e. create a application/libraries/MY_Security.php)
then override this method with one which also removes quotes.
I'm using monorail, activerecord, and jquery. I have a form with a zip code textbox. I have in my active record class associated to the form:
[Property]
[ValidateNonEmpty]
[ValidateRegExp(#"/^\d{5}(-\d{4})?$/", "Invalid")]
public string ZipCode { get; set; }
As you can see, I'm using the ValidateRegExp attribute, which then auto-generates jQuery validate rules. The issue is that regular expressions are different in javascript than they are in C#. Javascript requires a / before and after the regex, whereas C# does not. If I put the slashes then the jQuery validation will work, but if they bypass the javascript validation and submit the form with js disabled (or if someone saves the object through another means like a test case) then it'll say the zip code is invalid because C# doesn't like the slashes.
So my question is, how do you please both javascript and C# with one regex? I would expect it to be smart enough to add slashes before and after just for the jQuery validation so that you could specify the regex in C# without the slashes but this is not the case it seems.
You should be specifying the regular expression itself, without the surrounding / characters.
If you are having problems with the client side, it would help if you'd include the JS error you see (if any), and actual generated JS code on the page that is being written out by Monorail to your page, and also the version of Monorail you are using.
As a side note, lets look at the code generating the JS validation rule from the validation attribute in JQueryValidator.cs
the relevant piece is at line 378 (as of current version of the codebase):
"function(value, element, param) { return new RegExp(param).test(value); }"
which points to the fact that the new RegExp(expression) is used, rather than the /expression/ format.
With that - it is clear that Monorail's jquery validator integration is ok.
I'm using jQuery 1.4.2. Not sure what version of MonoRail I'm using, the Castle.MonoRail.Framework dll says v2.0.0.0. I updated it within the last 3 months though so it's fairly new. The js that you're showing indicates that you have an even newer version than me, as it generates the following for me (if no slashes included in the ValidateRegExp expression):
"user.username":{ required: true , regExp: ^[\w ]{4,50}$ }
This obviously gives a syntax error in js, as it's not wrapped in quotes or slashes. I ended up creating a new RegExp validator with AbstractValidator as the base class to get around the faulty one that is in my version of MonoRail.
Do you know if this was an issue that was fixed in the last couple of months? Otherwise I can't explain how yours generates new RegExp in js and mine does not...