Is input->post meant to strip tabs?

I have a textarea field that allows the user to insert tabs. I need to preserve those tabs as part of the processing of the textarea data, but I noticed they don't seem to make it through the call to

PHP Code:

$this->input->post('tabbed_content'); 


when testing it with

PHP Code:

substr_count() 


However, they are preserved as expected calling

PHP Code:

$_POST['tabbed_content']; 


I couldn't find anything in the docs about this behaviour. Is this expected from the post method of the input class?

Thanks.

You could try this, not tested.

PHP Code:

$this->input->post(htmlspecialchars('tabbed_content')); 


What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

You could try this, not tested.

PHP Code:

$this->input->post(htmlspecialchars('tabbed_content')); 


Yes, that worked, but it's still confusing because htmlspecalcharacters reportedly doesn't perform translations on backslashes.

But anyway, thanks for the remedy.

Edit: does htmlspecialchars() act as a good replacement for xss_clean, because I just found I am having the same issue with that too. I could of course run some tests, but perhaps you already know the answer

If you really want to see what's going on open up ./system/core/Security.php

That's were all the CodeIgniter security happens.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

You could try this, not tested.

PHP Code:

$this->input->post(htmlspecialchars('tabbed_content')); 


Yes, that worked

There's absolutely zero reason for that to "work". It is the equivalent of:

Code:

$input_name = htmlspecialchars('tabbed_content'); // returns 'tabbed_content' ... zero change
$this->input->post($input_name);

That doesn't help, in any imaginable way. What did work is you changing $config['global_xss_filtering'] to FALSE and/or not using xss_clean() on the contents.

but it's still confusing because htmlspecalcharacters reportedly doesn't perform translations on backslashes.

There are no backslashes to be "translated". We write "\n", "\t", etc. while we code because that's the notation programming languages use to denote whitespace characters, for code that is easier to both read and write. But there are no actual backslashes in those characters.

Edit: does htmlspecialchars() act as a good replacement for xss_clean, because I just found I am having the same issue with that too. I could of course run some tests, but perhaps you already know the answer

Depends on the context. If it is rendered within HTML, as regular text - yes, it's fine.

But you can't run tests to determine this. You can run tests to determine if your test content is rendered correctly, but given that you don't know how htmlspecialchars() works in the first place, you couldn't possibly test it for XSS vulnerabilities.
Security isn't about what works as intended in the boring everyday scenarios; it's about what happens when someone intentionally uses your stuff in ways you didn't anticipate.

Ok, thanks. I think it's coming together now. Actually, the input->post by itself is fine now. I must have been doing something weird to get that original output when I tested it.