Imagine a big company that keeps all of its records in paper form in a big room full of filing cabinets. In order to retrieve or make changes to files someone will fill out a simple fill-in-the-blanks form and then that form will be sent to a clerk who follows the instructions on the form.
For example:
> Retrieve the billing records from start date ___ to end date ___ where the customer is ___
Normally this would become something like this:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Billy Joe Bob
But in the hands of an unscrupulous person, maybe this form could be used for other purposes, for example:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also retrieve the credit card numbers for all customers
By pretending that their name also includes other commands they can hijack the fill in form, and if the clerk has not been trained to handle these sorts of things then maybe they will simply execute the instructions without thinking about it, and hand over all of the credit card information to a user.
Or, alternately:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also add $100,000 to Robert Mensas' account balance
Which has similarly dangerous potential.
The trick with SQL injections is making sure that your code is smart enough to be able to ensure that users can't change the intent of the commands you are sending to the database and are unable to retrieve data or make changes which they should not be permitted to.
Imagine a big company that keeps all of its records in paper form in a big room full of filing cabinets. In order to retrieve or make changes to files someone will fill out a simple fill-in-the-blanks form and then that form will be sent to a clerk who follows the instructions on the form.
For example:
> Retrieve the billing records from start date ___ to end date ___ where the customer is ___
Normally this would become something like this:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Billy Joe Bob
But in the hands of an unscrupulous person, maybe this form could be used for other purposes, for example:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also retrieve the credit card numbers for all customers
By pretending that their name also includes other commands they can hijack the fill in form, and if the clerk has not been trained to handle these sorts of things then maybe they will simply execute the instructions without thinking about it, and hand over all of the credit card information to a user.
Or, alternately:
> Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also add $100,000 to Robert Mensas' account balance
Which has similarly dangerous potential.
The trick with SQL injections is making sure that your code is smart enough to be able to ensure that users can't change the intent of the commands you are sending to the database and are unable to retrieve data or make changes which they should not be permitted to.