Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 29
  1. #1
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,127
    Thanks
    27
    Thanked 0 Times in 0 Posts

    Converting $_POST array to regular array

    When you receive an array in a $_POST request, do you ever copy it into a regular array, or just keep working with it in the $_POST array?

    Sincerely,


    Debbie

  • #2
    Regular Coder
    Join Date
    Sep 2011
    Posts
    428
    Thanks
    18
    Thanked 26 Times in 26 Posts
    It's all developer preference really.

    I feel that $_POST should only be used to get the data, not to change it, that way you always have the data from the user and not anything modified. If you want to modify it globally (ex. escaping everything or protection) then you can create a function to access it, or assign it to a new variable to use.

    I usually only have to make a new variable for passwords, when I have to encrypt it, but other than that I use $_POST. If you're working with data from a database, such as ID's, I feel using the data retrieved from the database is better as oppose to $_POST['id'], only because you know what you're working with. It's all preference really, but I feel that data in it shouldn't be modified so it's always the raw input the user submitted.

  • #3
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    $_POST is tainted - as you validate the content you should move each value to regular untainted fields - that way you can distinguish untainted valid data from tainted potentially garbage or dangerous data.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #4
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,365
    Thanks
    61
    Thanked 530 Times in 517 Posts
    Quote Originally Posted by Dubz View Post
    It's all developer preference really.
    +1 however when i am stupid enough to edit the array directly I always keep this in mind to remind me of my stupidity:

    Quote Originally Posted by Dubz View Post
    I feel that $_POST should only be used to get the data, not to change it, that way you always have the data from the user and not anything modified. If you want to modify it globally (ex. escaping everything or protection) then you can create a function to access it, or assign it to a new variable to use.
    I do however log my serialised() $_HTTP array to a database table for all http requests so that i can see exactly what came in ($_HTTP = $_GET + $_POST)
    Last edited by tangoforce; 06-07-2014 at 12:47 AM.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #5
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by Dubz View Post
    It's all developer preference really.
    Not really. Only a beginner would modify tainted data rather than validate it and move it to an untainted field.

    Using tainted data without validating it means your script is probably full of security holes waiting to be exploited.

    Only by validating each tainted field from $_POST, $_GET etc and copying the valid data from there into a separate field (so as to restrict tainted [unvalidated] data to easily identifiable fields) can you be sure that your subsequernt code cannot be compromised through injection and other attacks.

    It was to allow tainted fields to be kept separate from untainted fields that the register globals option was removed from PHP. If you don't validate the tainted fields and then move the now known to be untainted data into a completely separate set of fields then you will easily be able to get tainted and untainted fields mixed up and make use of a tainted field in a spot that allows your script to be compromised.

    The generic version of the code to process tainted fields is:

    Code:
    $myfield = '';
    if (myfield_valid($_POST['myfield'])) $myfield = $_POST['myfield'];
    else $errorMessage .= '"myfield" is invalid<br>';
    you then need a myfield_valid() function that validates the content of the variable and returns true only if the field contains data valid for that particular field. You can substitute validation filters or built in functions for the function call if such exists to validate the specific field.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #6
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,127
    Thanks
    27
    Thanked 0 Times in 0 Posts
    This is the code that made me curious what others do...

    PHP Code:
        foreach($_POST['subscriptionStatus'] as $articleThreadID => $subscriptionStatus){
            
    // Cast to Integers.
            
    $articleThreadID = (int)$articleThreadID;
            
    $subscriptionStatus = (int)$subscriptionStatus;

            
    // Check Value.
            
    if (($subscriptionStatus == 1) || ($subscriptionStatus == 2)){
                
    // Valid Status.

                // ******************************
                // Copy Form-Data to PHP Array.    *
                // ******************************
                
    $statusArray[$articleThreadID] = $subscriptionStatus;

            }else{
                
    // Invalid Status.
                // And so on...
            

    How does that look, Felgall?

    Sincerely,


    Debbie

  • #7
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,365
    Thanks
    61
    Thanked 530 Times in 517 Posts
    Quote Originally Posted by felgall View Post
    Not really. Only a beginner would modify tainted data rather than validate it and move it to an untainted field.

    Using tainted data without validating it means your script is probably full of security holes waiting to be exploited.

    Only by validating each tainted field from $_POST, $_GET etc and copying the valid data from there into a separate field (so as to restrict tainted [unvalidated] data to easily identifiable fields) can you be sure that your subsequernt code cannot be compromised through injection and other attacks.
    I disagree - especially with the comment about security holes.

    While I agree it's often preferable to move data from the original arrays into nice new variables you do this at a cost of CPU cycle usage and then memory consumption if you then manipulate the incoming data. This may not be a big issue however on busy servers with a lot of CPU usage, efficiency counts.

    Validating data in their $_POST or $_GET form is perfectly acceptable. If it's valid, use it. If not then discard it. There is absolutely nothing that makes it safe just because you copied it to another variable (which is only a pointer to the same memory anyway until it's changed). Once that http request has been sent, the super global arrays are set. It's not like a hacker can modify them part way through the script.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #8
    Regular Coder
    Join Date
    Sep 2011
    Posts
    428
    Thanks
    18
    Thanked 26 Times in 26 Posts
    Quote Originally Posted by tangoforce View Post
    Once that http request has been sent, the super global arrays are set. It's not like a hacker can modify them part way through the script.
    If this were possible then say bye bye to the internet cause everything would be exploitable then, unless you have no server side coding and it's all just html files, but then everything would be static online and you'd have no ability to post information, unless you communicated by uploading html files and whatnot, which sounds like a terrible idea...

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by tangoforce View Post
    Validating data in their $_POST or $_GET form is perfectly acceptable. If it's valid, use it. If not then discard it. There is absolutely nothing that makes it safe just because you copied it to another variable (which is only a pointer to the same memory anyway until it's changed).
    That's where you are wrong - at least where it comes to bigger scripts. It is trivially easy to see which fields have been validated and which haven't with a small script. With a much larger script the field name acts as a reminder of whether the particular field has been validated or not and so makes the code much easier to maintain as it divides the field names into tainted and untainted groups rather than the same field name being originally tainted and then untainted once it is validated.

    Obviously you have never had to maintain projects containing many millions of lines of code where simple things like this can save many weeks of testing.

    Once validated the $_POST and $_GET values are perfectly safe to use except that when you are several levels deep inside includes you'd need hunt down the spot in the code where the field is validated to know whether it is validated or not if you keep the value in the same field whereas the simple act of moving it only when it has been validated means you can tell directly from the code you are looking at that it has been validated without having to hunt through thousands or hundreds of thousands of lines of code in other includes to check.


    Simply copying to new field names without validating (as many beginners do) is completely pointless and even negates any reason for moving them at all - leading to the position you have taken. Only where the move is done consistently from the beginning at the time of validation do you actually gain the huge benefit that I referred to.

    For more information on why you should be moving fields once you validate them see the O'Reilly book "Essecntial PHP Security" by Chris Shiflett. To overcome the stupidity of beginners who move fields without validating he suggests moving them all to $clean[] instead so that you have all the validated values in their own array that clearly identifies that they have been validated.
    Last edited by felgall; 06-07-2014 at 10:55 PM.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,127
    Thanks
    27
    Thanked 0 Times in 0 Posts
    felgall,

    Does the OP get any love here?!

    How does my sample code in Post #6 above look?

    Sincerely,


    Debbie

  • #11
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,365
    Thanks
    61
    Thanked 530 Times in 517 Posts
    Quote Originally Posted by felgall View Post
    That's where you are wrong - at least where it comes to bigger scripts.
    Well that depends on who is the judge in this scenario. You forget that there is often more than one way of doing the same thing.

    I did say earlier that validating in the original array is acceptable yet below you go on to suggest that I'm not even keen on validating so I have to even wonder if you understood my point.

    Quote Originally Posted by felgall View Post
    It is trivially easy to see which fields have been validated and which haven't with a small script.
    Who said anything about 'seeing'? I test the data, if it is acceptable in my if conditional test then it is usable. I do not need to start using markers, flags, extra arrays etc miles down the file to see if it was valid once earlier up in the code.

    Quote Originally Posted by felgall View Post
    With a much larger script the field name acts as a reminder of whether the particular field has been validated or not
    If everyone works the same way as you. You always have this "Everyone should work the exact same way as me" idea in every post you reply to where you become challenged. Unfortunately Felgall, millions of coders all over the planet do things differently to you.

    Quote Originally Posted by felgall View Post
    Obviously you have never had to maintain projects containing many millions of lines of code where simple things like this can save many weeks of testing.
    Is this really about genital sizes?

    Quote Originally Posted by felgall View Post
    Once validated the $_POST and $_GET values are perfectly safe to use
    Slight change to what you said earlier..


    Quote Originally Posted by felgall View Post
    except that when you are several levels deep inside includes you'd need hunt down the spot in the code where the field is validated to know whether it is validated or not
    I validate at the point of usage for this very reason - I don't end up with millions of lines of code to look through to see if it was put through validation elsewhere.

    Quote Originally Posted by felgall View Post
    whereas the simple act of moving it only when it has been validated means you can tell directly from the code you are looking at that it has been validated without having to hunt through thousands or hundreds of thousands of lines of code in other includes to check.
    In principle yes I would agree but only if you are using seperate scripts for seperate functions / pages. In my current project I have one central script which manages everything and at that point, it is not possible to know what the data submitted is going to be used for yet alone validate it until it's passed to the appropriate included file. At this point it can be checked and validated and used straight from the source.

    Quote Originally Posted by felgall View Post
    Simply copying to new field names without validating (as many beginners do) is completely pointless and even negates any reason for moving them at all - leading to the position you have taken.
    Those are you words not mine. I did not suggest that users copy to new variables without validating. If you re-read my previous reply you will see I clearly stated:

    Validating data in their $_POST or $_GET form is perfectly acceptable. If it's valid, use it. If not then discard it. There is absolutely nothing that makes it safe just because you copied it to another variable
    In essence, you've actually just told me what I'd said to you earlier so please tell me how I took this position as you put it of copying to new variables without validating?


    Quote Originally Posted by felgall View Post
    For more information on why you should be moving fields once you validate them see the O'Reilly book "Essecntial PHP Security" by Chris Shiflett. To overcome the stupidity of beginners
    So anyone you consider below your level of coding is a stupid beginner (even though you didn't understand my points yourself and then made the same points back to me) yet you can't spell the name of a book correctly?
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #12
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,127
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by tangoforce View Post
    Is this really about genital sizes?
    Who likes Rocky Mountain oysters here?

    Anyone?

    Mmm... I'm hungry!!


    Debbie

  • #13
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by doubledee View Post
    How does that look, Felgall?

    Sincerely,


    Debbie
    That code looks fine to me although I'd probably have called is_numeric() rather than simply casting to an int.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #14
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,127
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    That code looks fine to me although I'd probably have called is_numeric() rather than simply casting to an int.
    What is the benefit of doing that?


    Debbie

  • #15
    Regular Coder
    Join Date
    Sep 2011
    Posts
    428
    Thanks
    18
    Thanked 26 Times in 26 Posts
    Now now children, lets not fight over little things that don't matter.

    felgall, are you saying that if I write 10 million codes of PHP that I'm an automatic expert in it? Nope? Then why bring it up? Nobody here is impressed with saying how many lines you work with, the real impression is what those millions of lines of code do and how efficient it is, especially when it's being executed multiple times, as tango pointed out.

    Need I remind you both this forum is for helping other programmers with questions. Whether it be error related or general questions, there's no need to yank out our "swords" and start jabbing at everything, so put em away and show a little courtesy to the OP. Sure, we can have a debate over efficiency and past experiences, but stay on track with the subject. I'm not saying all the posts were off subject, but try not to get carried away.


    Now as for the OP, I still believe that keeping the original $_POST array (unmodified) s the way to go. If you need to sanitize the user's input, such as encrypting a password, or converting a date or timestamp, then give them a separate variable. If you want everything that's passed to the $_POST, or even $_GET, to be sanitized in some way, consider making a function to get the said data and return it sanitized, this way it keeps it on hand to get the data, but you can still get the original, raw data if needed.

    As for using is_numeric or (int), if you're trying to validate a number for an ID, or any whole number (0, 1, 2, 3, etc.), consider using ctype_digit() instead. This function will only allow numeric values in strings, so any number form $_GET or $_POST will work. I'm sure you could also do preg_match() of the data, but I've heard regular expressions can take more memory and should be stayed away from if possible.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •