| filtering HTML form |
|
Hello, all.
In a form there is a <textarea> field containing HTML formatted data, which get damaged after PHP Code: $this->input->post('text'); Some sub-strings replaced by '[removed]'. The temporary solution i found is to turn off filtering by second parameter: PHP Code: $this->input->post('text', false); Could you suggest more secure approach?  I want this filter, but i have to to deal with HTML data.
This implies that you have 'global_xss_filtering' enabled for your site. As mentioned in the documentation, this setting is deprecated because it is not a good security practice to use the xss_clean() method on your input (which is what happens if you use either the 'global_xss_filtering' setting or pass true to the second parameter of $this->input->post()). Because some entries were missed in the updates to the documentation, the documentation of the Security Class contradicts the documentation of the Input Class.
When processing input, it should be processed for the purpose of making it safe for the current destination. So, when data is input by the user (in other words, your code receives it via $this->input->post(), usually), you are generally processing it for storing in the database. XSS filtering has nothing to do with securing the data for the database, so it doesn't belong here. When your controller receives data from the database, it should treat it as input again, but this time processing it for whatever new destination you have in mind. If the data is going to be output as JSON, you need to prepare it differently than if it is going to be output as HTML. If the output format happens to be HTML, you should use XSS filtering where appropriate. There are a number of reasons for this, but the simplest one is that xss_clean() is not a method you can use repeatedly on its own output. If you pass the data through xss_clean() and store the result, you can't necessarily pass it through again, or easily reverse the process. This becomes especially important if xss_clean() changes over time. Data you thought was safe because it went through xss_clean() before you stored it is no longer safe because someone found an issue and fixed xss_clean(), but no one provided a way for you to automatically fix your stored data. Another relatively simple reason is that if you store "clean" data and fail to perform any filtering on the data from your database, you open the site up to attack if someone can find a method to get bad data into your database (either by finding a gap in your input filters or by attacking the database directly, bypassing the site completely). So, the solution is to use the filtering when you output the data to HTML, not when you insert the data into a database. However, that may not be a complete solution to your specific problem, because you may find that there is no problem on the initial insert, but you end up with the same problem when someone goes to update the data, because the xss_clean() method will still do the same thing when you output its result into the form, then your form will pass it back to the controller to update the database and you end up with garbage again. Chances are pretty good that what you need for this specific case is going to be quite specific to your data's requirements. You need to permit HTML, but chances are that you can limit what HTML is accepted. You may want to look for a PHP library for securing HTML to be displayed in a textarea or other form inputs with the intention of being able to submit the data in the form as HTML, as CI's built-in methods are a little less subtle than what is required for your scenario. |
| Welcome Guest, Not a member yet? Register Sign In |
