$_POST case sensitivity

[Michael Fesser]

Re: $_POST case sensitivity

..oO(Jeff)

>OK, I'll bite as I'm a php newbie. Not that I'm planning on ever using
>magic quotes (I see it's deprecated) but I don't quite get the concept
>of why such a functionality exists.
>
Is there some vulnerability this was supposed to cover up? Or is it
>just a lazy way of getting data ready to put into a database? Is there
>some other use?

It is a broken feature like register_global s. It was supposed to be an
easy to use feature to prevent SQL injection and similar problems, but
it never really worked and just led to a dangerous and false sense of
security. It will be completely removed from PHP 6, so it's not really
worth to talk about it anymore. Consider it a design mistake in PHP's
history.

Micha

[AnrDaemon]

Re: $_POST case sensitivity

Greetings, mike.coakley@gm ail.com.
In reply to Your message dated Monday, July 7, 2008, 8:15:53,

>I can appreciate your view point. Maybe I did assume too much with my
>reply. I was assuming that Bill would understand my intention with
>first giving him the answer he was looking for (array_change_k ey_case)
>and then expanding to fulfill a comment someone else made in the
>posts, to me if you are iterating over the data received from a HTML
>form you should only iterate once if possible and that is why I made
>the natural "leap" to offer some filtering advice as well.

>>

>So... BILL - please understand that all you need to use is
>array_change_k ey_case to resolve the issue you have requested within
>this topic. However, off topic of course, you can use htmlentities to
>encode/filter HTML form data received via the $_POST array to
>effectively strip the users input of HTML entities while still
>retaining their display value. (Definitely read the linked docs in my
>last reply.) You absolutely should understand what issues htmlentities
>could cause your data input routines and ensure that all of those
>involved understand how its filtering will affect your workflow.

>>

>Jerry - if you would, even off list - let me know the issues you have
>had with htmlentities. I've used it for a while now and would like to
>know what problems it can cause.

>>

>Thanks,

>>

htmlentities() is not the correct function to use here.  It is used to
write strings which may contain html special characters (like '<' and
'>', for instance) to an html page.

>>
>Say we have a textarea:
>>
><textarea$valu e </textarea>
>>
>What would be the proper processing needed for $value?

Nothing, unless you know what you want to do with it.
I.e., if you want to post it back as text (as is), just post it with
htmlspecialchar s().
If you wish to allow users to use basic formatting, you must use something
like strip_tags and probably tidy module to validate input.

>I'm using htmlentities for my textfields and selects and I assume that is
>correct, but $value could contain html and I'm unsure what to do there as I
>don't want to turn <brinto &lt;br&gt; but I also don't want to break this
>if there is a textarea tag in $value.

First, you must decide what you want to do. Second - understand, what you are
doing exactly. (I.e., ask yourself "why it is wrong")

>>
>   Jeff
>>
>  It is not meant to be used on input
>>

data, and its use in that situation is incorrect.

>>
>>

Jerry & Micha are absolutely correct in their statements about
htmlentities. I will say that my comments on input validation/
filtering probably were a little presumptuous on my part. I personally
don't allow ANY HTML tags to be entered into my HTML forms and
therefore I use htmlentities as a pre-processor

I apologize if that already have been explained, but I think I'd add a word:

You MUST NOT encode any input data before processing.
Including any expressed (htmlspecialcha rs, htmlentities etc.) or implied
encodings (like magic_quote_gpc ).

There are only one place and one case to encode data:
Place - where you sending data somewhere and
Case - to avoid damage to the target environment.

I.e., it is calling (dblayer)_escap e_string() before saving data to the
database (using prepared statements will do the same), or using
htmlspecialchar s() while sending data to client.

That's all.

BUT the intention is to use it during output. Using htmlentities will
protect against Cross-site scripting issues and not SQL injection as Micha
pointed out. Most likely what you are looking for the strip_tags function
(http://us3.php.net/manual/en/function.strip-tags.php) and pass it a string
of the tags you want to slip through.

strip_tags is another ñase, and must be handled differently (and carefully).
But it would be much better example for input data preprocessing, as you
explained that already.

Thanks,

(OF course I'm probably reading this wrong as well and this is REALLY
OT... but I hope I helped a little.)

--
Sincerely Yours, AnrDaemon <anrdaemon@free mail.ru>

[AnrDaemon]

Re: $_POST case sensitivity

Greetings, Jeff.
In reply to Your message dated Monday, July 7, 2008, 18:47:25,

>>You always want to work with the _raw_ unescaped data and only apply
>>escaping functions where necessary. Which functions to use depends on
>>what you actually want to do with the data.

>>
>>
>I can feel a 'magic quotes' moment coming on...
>>

OK, I'll bite as I'm a php newbie. Not that I'm planning on ever using
magic quotes (I see it's deprecated) but I don't quite get the concept
of why such a functionality exists.

Is there some vulnerability this was supposed to cover up? Or is it
just a lazy way of getting data ready to put into a database? Is there
some other use?

It was strange attempt to prevent SQL exploits. But it was never work good and
will be removed as I have heard.


--
Sincerely Yours, AnrDaemon <anrdaemon@free mail.ru>