How was my database hacked? – Databases – SitePoint Forums

Error mode must be set to use exceptions. The connection already always uses exceptions for errors and by using exceptions for all other database statements that may fail – query, prepare and execute, you will get “free” error handling for those statements without adding any code to every statement, and allowing you to remove any existing discrete error handling logic you might have now, simplifying the code. The only time error handling for database statements, which would now use try/catch exception logic, is for errors that the user at the site might catch, such as inserting/updating day of duplicate or out-of-range values. In all other cases, there is nothing the user can do about the type of errors that would occur, so there is no point in your application code trying to handle them specifically. Just let php catch the exception in those cases, where php will use its error related parameters to control what happens with the actual error information (database declaration errors will be “automatically” displayed/logged from the same way as php errors.)

Yes. A prepared query prevents any sql special character in a value from breaking the sql query syntax, for all data types. A prepared statement also simplifies the sql query syntax, since all the extra quotes, concatenation dots and {} that are used to get php variables in the sql query are removed, when you remove the variables and replace them with simple ? placeholders. A second point of a paper query is that it provides a minor performance improvement (~5%) for queries that are executed more than once, with different input values, since the sql query statement is sent only once to the database server, where it is parsed and scheduled to run only once on the database server.

If you read the examples I gave, it is a SELECT query used to retrieve data from any table. The key is to prevent any sql special characters in a data value from breaking the sql query syntax.

One point that hasn’t been made yet is that for at least the MySql/MariaDB database, they decode a hex encoded string, when encountered in a string context in the query statement sql, to revert to the original encoded string. This is how much of the SQL injection is accomplished, as it allows the value to bypass the checks and sanitization attempts made to it. It is therefore imperative that ALL external, unknown (past, present and future) and dynamic values ​​be supplied to a query when it is executed using a prepared statement.

So, using the PDO extension, always using a prepared statement with external, unknown and dynamic values, using implicit binding by supplying a simple array of input values ​​to ->execute([…]) call, just using ? placeholders and using exceptions for database statement errors makes your database code safe for all data types and generates the simplest code and simplest query syntax.

James S. Joseph