Results 1 to 11 of 11
  1. #1
    Join Date
    Jul 2006
    Posts
    56

    Unanswered: SQL Injection ...

    Am I protected from SQL Injection by using such a function *only* ?
    Should I be using htmlentities also ?

    PHP Code:
    function validate_input($input) {

        
    # Insert the junk
        
    $junk = array("select""insert""update""delete""drop"";""--""xp_""*""'"'"'"truncate""schema.");
        
        
    # Searchs for invalid inputs in the string and replaces them with empties
        
    for ($junk_i 0$junk_i count($junk); $junk_i++) {
            
    $input str_ireplace($junk[$junk_i], ""$input); 
        }

        
    # Returns the validated string
        
    return $input;


    The "schema" array value is the Oracle Database schema name I use.

    Thanks in advance for any advice.
    Last edited by igordonin; 11-01-07 at 20:19.

  2. #2
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    What about comments such as
    Code:
    /*This
    is a
    comment */
    And they keyword "EXEC" / "EXECUTE"?
    George
    Home | Blog

  3. #3
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Even if that does protect you, it also destroys perfectly valid input.

    Your input is either going to be a string or a non-string value that matches a regular expression. For example, integers should always match /[+-]\d+/. PHP probably has what you need built in.

    Strings are easy to escape in SQL. I'm not a PHP guy, but it's as simple as:

    Code:
    "'" . str_replace("'", "''", $input) . "'"
    Now you've got a quoted string. But don't take my word for it, read the spec.

    Code:
        <character string literal>    ::= 
         [  <introducer> <character set specification>  ]  <quote>  [  <character representation> ...  ]  <quote>  [  {  <separator> ...  <quote>  [  <character representation> ...  ]  <quote>  }...  ]
        <quote>    ::=   '
        <character representation>    ::=   <nonquote character>  |  <quote symbol>
        <nonquote characte r>    ::=   !! See the Syntax rules
        <quote symbol>    ::=   <quote>  <quote>
        <separator> ::= { <comment> | <space> | <newline> }...
    
      Syntax Rules
    
             1) In a <character string literal> or <national character string
                literal>, the sequence:
    
                  <quote> <character representation>... <quote>
                  <separator>... <quote> <character representation>... <quote>
    
                is equivalent to the sequence
    
                  <quote> <character representation>... <character representa-
                  tion>... <quote>
    
                Note: The <character representation>s in the equivalent se-
                quence are in the same sequence and relative sequence as in the
                original <character string literal>.
    Basically, it's saying two things: you can represent a quote with two quotes. (That's the quote symbol rule.) And that if you have two strings next to each other, like 'foo' 'bar' it's the same as saying 'foobar'. This is the way it works in C and other languages, too. (Well, there's more stuff about choosing character sets, but I can't imagine that would work very well...)

    Also note that there's no reason that 'a string on two lines

    doesn''t work just fine'. And having keywords inside the quote marks doesn't bother SQL in the least... so long as it's properly quoted, it gets turned into a character string literal token by the lexer.

  4. #4
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by igordonin
    Should I be using htmlentities also ?
    No. Stop trying to do shotgun programming. HTML entities are for HTML, not SQL.

  5. #5
    Join Date
    Jul 2006
    Posts
    56
    Thank you very much for your help.


    Cheers

  6. #6
    Join Date
    Mar 2007
    Location
    010101010110100
    Posts
    803
    Quote Originally Posted by sco08y
    No. Stop trying to do shotgun programming. HTML entities are for HTML, not SQL.
    Hang on there Mister.. There is absolutley nothing wrong with filtering input with htmlentities(). I believe what he is actually looking for though is htmlspecialchars().

  7. #7
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by fjm1967
    Hang on there Mister.. There is absolutley nothing wrong with filtering input with htmlentities(). I believe what he is actually looking for though is htmlspecialchars().
    Are you sure you don't mean filtering output?

  8. #8
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    If you are using Oracle as it seems to be, just use bind variables and you will avoid SQL injection .

    http://asktom.oracle.com/pls/asktom/...23863706595353

    For even better Oracle programming, use PLSQL stored procedures within packages and there you go .

    If you want some more details, feel free to ask.

    Regards,

    rbaraer
    ORA-000TK : No bind variable detected... Shared Pool Alert code 5 - Nuclear query ready .

  9. #9
    Join Date
    Nov 2007
    Posts
    14
    You can really use bind variables and prepared statements with most db systems if you have PHP 5, the PDO extension and the necessary adapter installed ... unless it ships with the core install these days.

    Probably the best way of preventing sql injection and dealing with sql in php in general.

  10. #10
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    Quote Originally Posted by Genx
    Probably the best way of preventing sql injection and dealing with sql in php in general.
    Absolutely
    ORA-000TK : No bind variable detected... Shared Pool Alert code 5 - Nuclear query ready .

  11. #11
    Join Date
    Jan 2004
    Location
    India
    Posts
    168
    htmlspecialchars() is also one of the methods used to avoid SQL injection.
    Freelance and Technology Consultant
    -------------------
    Dreams are for ever
    -------------------

Posting Permissions

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