Form Validation and xss_clean

[eluser]Madmartigan1[/eluser]
Is there any reason to use the xss_clean validation rule on data that, after being processed by the other rules, should be clean already?

Example:

Code:

// is this redundant?
$this->form_validation->set_rules('email', 'Email', 'valid_email|xss_clean');

// what about this?
$this->form_validation->set_rules('name', 'Name', 'exact_length[1]|xss_clean');

I've recently had to turn off global xss filtering, so this has become an issue.



I accidentally typed XXX_clean a minute ago :lol:

[eluser]Eric Barnes[/eluser]
In that context it is not redundant because valid_email does not check for xss_clean. If you are later using active record to insert or update then it would be as active record runs xss_clean.

[eluser]Madmartigan1[/eluser]
If the email is valid, how can it be dangerous? I'm no security expert...

If you are later using active record to insert or update then it would be as active record runs xss_clean.

Not following you there. Can you clarify? I always use active record and it does not xss_clean by default afaik. I ran into this when I had to edit templates and allow <scri*pt> tags.

[eluser]Eric Barnes[/eluser]
Good call. I thought active record did xss_clean but it just automatically escapes.

Now I haven't tested this by any means but the valid_email only does a single regex to verify it is an email. So I would imagine things like

Code:

% 77 % 77 % 77 % 2E % 67 % 6F % 6F % 67 l % 65 % 2E % 63 % 6F % [email protected]

may still pass.

Edit: had to add spaces to get it to show.

[eluser]Madmartigan1[/eluser]
Yes that will pass the regex, and it is a perfectly valid email.

The point you make about escaping is important for injection security.

The question is about xss_clean and when it is necessary. As I've mentioned, I've had to disable the global filtering as there is no way to disable it after it has been enabled globally. The easy way to is to add the xss_clean rule to every form rule in the app now, but I'm trying to decide where to draw the line.

Is a valid email (according to the default rules CI uses to validate it) a potential security risk?

What about data that has been processed with strip_tags()?

What about data that has been processed with alpha, is_natural, integer, numeric, etc. etc.?

Could any of this data be unsafe? Also, at what point in CI execution does the data typically become harmful?

EDIT: Missed your edit :lol: Whatever it is you changed it to will not pass

EDIT: I'd also like to remind that not every form interacts with a database.

[eluser]Atharva[/eluser]
Good point. I am listening too 8-/

[eluser]Eric Barnes[/eluser]
Let me try to answer each of your questions.

1. The question is about xss_clean and when it is necessary.

xss_clean is really only necessary when you are saving data to display on a page. Here is the actual definition which sums it up nicely. Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users.

So if you are not using the data to display data to other users then it isn't needed.

2. Is a valid email (according to the default rules CI uses to validate it) a potential security risk?

Potentially it could be, if you are going to display it on your website and they have some how injected code that passed CI validation.

3. What about data that has been processed with strip_tags()?
4. What about data that has been processed with alpha, is_natural, integer, numeric, etc. etc.?
5. Could any of this data be unsafe? Also, at what point in CI execution does the data typically become harmful?

I will wrap those together since they are all related. The validation on those should confirm it is the right type of data. I personally do not use xss_clean but when getting the value use

Code:

$this->input->post('some_data', TRUE);

The TRUE runs it through the XSS filter.

Also it is always best to follow the guidelines:

Before accepting any data into your application, whether it be POST data from a form submission, COOKIE data, URI data, XML-RPC data, or even data from the SERVER array, you are encouraged to practice this three step approach:

* Filter the data as if it were tainted.
* Validate the data to ensure it conforms to the correct type, length, size, etc. (sometimes this step can replace step one)
* Escape the data before submitting it into your database.

[eluser]Madmartigan1[/eluser]
[quote author="Eric Barnes" date="1293653183"]
* Validate the data to ensure it conforms to the correct type, length, size, etc. (sometimes this step can replace step one)
[/quote]

I think this is exactly what we're talking about. Under what circumstances can step 2 replace step 1?

For instance, if one of the rules is "integer", adding the prep rules "xss_clean" would pointless right? How can an integer be unsafe? Etc...

[eluser]Atharva[/eluser]
[quote author="Madmartigan1" date="1293653984"]

For instance, if one of the rules is "integer", adding the prep rules "xss_clean" would pointless right? How can an integer be unsafe? Etc...[/quote]

Exactly. I think it is safe to say that "integers" or "numbers" are harmless..or are there any use cases to prove this assumption wrong? Anyone?

[eluser]Eric Barnes[/eluser]
Yes I can't see any security issues with numbers if they are validated.