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.
Results 1 to 4 of 4
  1. #1
    q1h
    q1h is offline
    New Coder
    Join Date
    May 2011
    Posts
    34
    Thanks
    7
    Thanked 0 Times in 0 Posts

    Input Sanitization

    I've read a few things about attacks, and I'm wondering if what I'm using is sufficiently secure:

    PHP Code:
    $string mysql_real_escape_string$_POST['string'] ); // do the escape
    $string substr($string,0,12); // limit the input to the needed amount of characters
    $string preg_replace("/[^A-Za-z0-9]/",'',$string); // filter out unwanted characters 
    Also, is it ok to just use converted data without escaping? Like:

    PHP Code:
    $string md5($_POST['string']);

    // or

    $string strtotime$_POST['string'] ); 
    Thanks ...

  • #2
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    escaping is an output function that has nothing at all to do with security. You eacape HTML using htmlspecialchars() before writing it so as to make sure that any < and & in the text don't get misinterpreted as tags. You use mysql_real_escape_string() if you are using the old approach to referencing the database using query instead of prepare/bind so as to make sure that your data isn't confused with the query. Using prepare/bind is a better method because it keeps the query in the prepare and the data in the bind so that the data doesn't need to be escaped to be kept separate.

    To sanitize fields in PHP you use the sanitiize filters at http://au2.php.net/manual/en/filter....s.sanitize.php as your first choice of sanitization method [unless there is a specific function that will handle it for you such as is_numeric() ] and only use a regular expression for fields that it can't handle.

    For your first example all you need is:

    $string = preg_replace("/^([^A-Za-z0-9]){,12}$/",'', $_POST['string'] );

    With your second example given that the functions you are calling return sanitized data there is no need for anything further to sanitize those values.
    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.

  • #3
    q1h
    q1h is offline
    New Coder
    Join Date
    May 2011
    Posts
    34
    Thanks
    7
    Thanked 0 Times in 0 Posts
    felgall, thanks for the info ...

    I thought that the danger was SQL injection when inserting user data INTO a database? Are you saying the danger is when their code is displayed?

  • #4
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,342
    Thanks
    13
    Thanked 349 Times in 345 Posts
    Quote Originally Posted by q1h View Post
    I thought that the danger was SQL injection when inserting user data INTO a database? Are you saying the danger is when their code is displayed?
    the danger of SQL Injections is user data being interpreted as SQL Statement.
    if you have for example SELECT * FROM mytable WHERE id = '$id'; then the content of $id is parsed as statement. if it's a value, then this is OK, if that'd be SQL code, it's SQL Injection ($id = "' or 1 = 1 --").

    Prepared Statements on the other hand side treat SQL statements and data differently, because the SQL is parsed first and after that, data are added: SELECT * FROM mytable WHERE id = ?; there is no way for user data to be parsed as SQL Statements rendering SQL Injections useless (even if you used the code from above, the data are not evaluated as SQL)

    (and another feature is that you don't have to concern yourself with whether the value needs to be quoted or not. that information (the data type) is passed in the data bind process)
    Last edited by Dormilich; 01-13-2012 at 06:54 AM.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer


  •  

    Posting Permissions

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