Does the form_validation library clean/sanitize data?

[eluser]jprateragg[/eluser]
In previous projects I've worked on, I usually used filter_var and its parameters to clean and sanitize data. I noticed CI has this built-in with the form_validation library. Does this library actually sanitize the data being passed to it?

I'm trying to pass a simple text field to my database. In the text field I entered some data that should be cleaned "Lastname&%'". I'm using the following rule:

Code:

$this->form_validation->set_rules('last_name', 'Last Name', 'trim|xss_clean|htmlspecialchars');

When sending data to a database query, I'm using this:

Code:

$query = $this->db->query("SELECT * FROM table WHERE last_name LIKE '". $this->input->post('last_name', TRUE) ."' AND ...");

But when I run this query, I receive a message saying there is an error in my syntax, and the error being at the questionable characters:

Code:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%') AND first_name LIKE '%' AND cs_no LIKE '%' ORDER BY last_name, first_name' at line 1

Do I need to add an additional layer of sanitation to my data?

I'm running this after my rules run:

Code:

echo $this->input->post('last_name', true);

...And it's not escaping (or converting it to an HTML character) the apostrophe ('). I just want to make sure I'm doing this correctly.

[eluser]Aken[/eluser]
Form validation does not manipulate any data sent to it, no. Only functions that you add to your rule sets will modify the posted value.

Using xss_clean in your rules, and then specifying the TRUE param in post() is redundant, as both do xss_clean. That may affect your data, so you should do one or the other.

htmlspecialchars does not encode single quotes unless a flag is specified, so you should use it after retrieving the post value, and not as a validation rule.

[eluser]jprateragg[/eluser]
[quote author="Aken" date="1352341910"]Form validation does not manipulate any data sent to it, no. Only functions that you add to your rule sets will modify the posted value.

Using xss_clean in your rules, and then specifying the TRUE param in post() is redundant, as both do xss_clean. That may affect your data, so you should do one or the other.

htmlspecialchars does not encode single quotes unless a flag is specified, so you should use it after retrieving the post value, and not as a validation rule.[/quote]

Can we add custom functions to the rules? For example, in my previous project, I had simple functions like:

Code:

function clean_text($data) {
    return filter_var($data, FILTER_SANITIZE_STRING);
}

[eluser]Aken[/eluser]
Of course, you can add any function that only requires one parameter, whether it's built in to PHP or custom.

[eluser]jprateragg[/eluser]
I'm assuming I would put these functions in a helper (applications/helpers), correct?

[eluser]Aken[/eluser]
A helper or by extending the form validation library would be the most CI-esque ways, yes.

[eluser]jprateragg[/eluser]
So I've created a helper and it seems to be working. But now I've run into another issue. I'm running this rule:

Code:

$this->form_validation->set_rules('last_name', 'Last Name', 'trim|clean_string');

Using this helper function:

Code:

function clean_string($input) {
return filter_var($input, FILTER_SANITIZE_STRING);
}

And using this in my view to set the value:

Code:

<td>&lt;input type="text" name="last_name" value="&lt;?php echo set_value('last_name'); ?&gt;" /&gt;&lt;/td>

I'm using a test of "Last'". When I run it through the validation rule, it gets outputed as:

Code:

Last'

But, when I use set_value in the form to display the value after a post, the ampersand gets rewritten and the result is this:

Code:

Last'

It seems like set_value is running the data through a filter. Is there something I'm doing wrong, or is this expected behavior?

[eluser]Aken[/eluser]
It's expected. set_value() and similar functions will encode the string for form elements. For example, say you actually had a string that said & that you wanted to save. Without the encoding, a literal & would be shown. With encoding, you'd still see & as you needed. I'm sure you'll notice that the ampersand is shown properly in the field, as well as passed normally when the form is submitted.