• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is input->post meant to strip tabs?

#1
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.
Reply

#2
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 the CodeIgniter Community in 2009.          ( Skype: insitfx )
Reply

#3
(09-04-2017, 10:35 AM)InsiteFX Wrote: 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. Smile

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 Tongue
Reply

#4
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 the CodeIgniter Community in 2009.          ( Skype: insitfx )
Reply

#5
(09-05-2017, 12:52 AM)n2fole00 Wrote:
(09-04-2017, 10:35 AM)InsiteFX Wrote: 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.

(09-05-2017, 12:52 AM)n2fole00 Wrote: 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.

(09-05-2017, 12:52 AM)n2fole00 Wrote: 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 Tongue

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.
Reply

#6
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.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2017 MyBB Group.