We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 26016
    • 561 Posts
    Wise Men and Women,
    I’ve got some pages where I’m using GET variables. I’m not using user input, so generally no garbage would come through, but I’m concerned about rogue input from bots, nefarious people, etc.

    I’m reading up on handling that sort of thing, and can write some code, but I’m wondering if there’s a handy function that does this checking, cleaning, etc.? I’m not concerned about fancy error-handling, as the normal user would never be doing the input. I would probably just get out and do nothing.

    Oh, and maybe it would handle POST’s and other such variables.

    Thx!
    Samba
      MODx and Wordpress development
      Linux, PHP 5.2, MySQL 5.0, Evo 1.05, Revo 2.08-pl, Firefox 4
      • 34127
      • 135 Posts
      Well any sort of data that even just *might* be touched by a user should be sanitized before actually being used, whether in a GET or POST request, without exception. I usually use a function like this to initially clean my input:

      function clean( $input ) {
      	$input = trim( $input );				//Trim whitespace
      	$input = mysql_real_escape_string( $input );		//Escape data to make query-safe
      	$input = htmlentities( $input, ENT_COMPAT, 'UTF-8' );	//Convert characters like < and & to their ASCII equivalent. Double check the charset for encoding!
      
      	return $input;
      }


      That’s generally enough to protect against most types of attacks (SQL injection and XSS). Of course, it’s best to also combine that with type checking too. For example, if you’re expecting a variable to only contain an id or numerical value, use either is_numeric to check the type, or intval to cast the input to an integer (so something like "aa\2" would become "2". If a value should be a certain length, check the length using strlen. You could even use preg_replace to strip out characters other than those expected which is also a pretty good method. For some of my own scripts, I use an array to populate a dropdown list. If you compare the actual user input against the values in the array using in_array, then that’s yet another good way to prevent "bad" data from being inputted. smiley

      Edit: I forgot to mention that the $modx->db->escape() function does the same thing as mysql_real_escape_string. smiley
        • 26016
        • 561 Posts
        Quote from: Eleventeen at Apr 20, 2007, 12:40 AM

        Well any sort of data that even just *might* be touched by a user should be sanitized before actually being used, whether in a GET or POST request, without exception. I usually use a function like this to initially clean my input:

        Eleven,
        Very smart ideas and function... thanks!!!!! While thinking about this, I’ve also been getting up to speed on preg_match and regex, stuff you real PHP programmers do every day. Seeing those long regex lines can be pretty frightening! wink

        But I can get some of it, and with that, I might lock it down really tight by only allowing a half-dozen possible values.

        At first I thought I wasn’t using user input, but actually in another spot I am, with POST’s, so I’ll definitely use your ideas there as well.

        I appreciate the help,
        Cheers, S
          MODx and Wordpress development
          Linux, PHP 5.2, MySQL 5.0, Evo 1.05, Revo 2.08-pl, Firefox 4
          • 34127
          • 135 Posts
          You’re welcome, anytime. wink The big thing to always remember is that you should never trust any user input, whether it be in a simple link (because values could always be changed from the address bar), or a form, and it should always be treated as "dangerous" until you fix it up. A lot of exploits occur in web apps because the programmer didn’t think that someone would take advantage of it. For example, if you have a dropdown menu of options, there’s nothing stopping the user from downloading the page containing the form and changing the field into a text field (or any field for that matter) and injecting their own data, then submitting the form from their computer. IF you remember that, you’re pretty much good to go. laugh

          And yes, regex was a scary thing when I first started (and sometimes they still are little monsters to deal with tongue ). They’re very handy for validation though, and are well worth the time taken to learn. Good luck! smiley