Here is some code i want to start with to use in a new form (please note I am a noob, thanks):

$myid = intval($_GET['id']);
$mynumber = intval($_GET['number']);

$dbuser_name = "databaseusernamehere";
$dbpassword = "databasepasswordhere";
$dbdatabase = "databasenamehere";
$dbserver = "database.host.com";
$db_handle = mysql_connect($dbserver, $dbuser_name, $dbpassword);
$db_found = mysql_select_db($dbdatabase, $db_handle);

$dbcnx = @mysql_connect($dbserver,$dbuser_name,$dbpassword);
if (!$dbcnx) {
die('unable to connect to database server at this time.<p>');
}

if (! @mysql_select_db("$dbdatabase") ) {
die('unable to connect to db at this time.<p>');
}

$result = @mysql_query("SELECT * FROM `mydatabase` WHERE `dbfield1` = $mynumber and `dbfield2` = $myid");
if (!$result) {
die ('Error performing query: No Match ' . mysql_error() . '<p>');
}

if (mysql_num_rows($result) < 1) {
echo ("No records available");
} else {

How do i clean this up so it's safe from injection attack?

Thank you for any advice!

-Jay

    And if you choose not to use prepared statements, you'll still want to apply the same techniques of sanitizing (and/or validating) inputs before placing them inside SQL query strings.

    For example, the code above seems to assume that the two pieces of user-supplied data are to be numeric (integers, more specifically), thus it utilizes [man]intval/man to ensure this is the case. Since any non-integer data (such as the string "123 OR 1=1") would get truncated and casted/marshalled into an integer, I would say the above code is already "safe from injection attack."

      Thanks @ , I suspected my method was fairly safe and I tend to agree with your last statement. @ , thanks for the links. I've gotten the basic SQL code handed to me from another functional site, and know only about what is there and working. The data you linked to is advanced to me and will take time to absorb. The phrase "...MySQL extension" for example, doesn't mean anything to me yet. 🙂

      Thanks to all!

      -Jay

        "Extension" in this context means an optional part of the PHP language that can be installed. All the mysql() functions are part of the MySQL extension, mysqli() functions (and their related OOP versions) are part of the MySQLi extension. The "i" stands for "improved", and as such the MySQLi extension is newer and provides functionality that the older, deprecated function does not. And since the MySQL extension is now deprecated, there is no guarantee it will continue to be supported in future versions of PHP, so it's a very good idea to not use it any more if it can be at all avoided -- either use the MySQLi extension, or the PDO extension, which is a more generic interface to many different database engines, including MySQL. (I happen to prefer PDO for that reason, so I can use essentially the same coding style whether I'm working with MySQL, PostgreSQL, or whatever database I need to support at any given time.)

          8 days later

          It's important to realize that 'sql injection' is more often a problem with the code that constructs your query rather than the query itself. The two really big ways to prevent SQL injection are:
          1) ALWAYS validate user input before feeding to any sql query. If you want a number from user input, make sure it's a number and not something like ' UNION SELECT * FROM password'. To validate user input, consider using [man]filter_var[/man].
          2) ALWAYS escape values before putting them into a query. Escaping is the process by which you replace special characters (like quotes or newline chars0 with their 'escaped' equivalents. The appropriate function will vary depending on what database connection method you are using. See:
          http://php.net/manual/en/pdo.quote.php
          http://php.net/manual/en/mysqli.real-escape-string.php

            If you use prepared statements with bound parameters, you no longer have to worry about using the appropriate escaping mechanism or checking types: the preparing/binding takes care of that for you.

              NogDog;11042695 wrote:

              If you use prepared statements with bound parameters, you no longer have to worry about using the appropriate escaping mechanism or checking types: the preparing/binding takes care of that for you.

              I seem to recall also that PDO is pretty specific about data types too? I.e., you might get exceptions/errors if you supply the wrong data type for a param.

                sneakyimp;11042731 wrote:

                I seem to recall also that PDO is pretty specific about data types too? I.e., you might get exceptions/errors if you supply the wrong data type for a param.

                There is an optional argument to tell it what type you want, e.g.:

                $stmt->bindParam(':name', $value, PDO::PARAM_INT);
                  Write a Reply...