SQL injection continues to be a favourite target of attackers. In the news we see regular reports of data dumps containing credit card information, usernames, passwords, and other information; more often than not these dumps are the result of SQL injection attacks.
Successful attacks provide an attacker access to whatever data the database holds and even operating system access in the most damaging attacks.
How SQL Injection Works
The majority of modern web applications and sites use some form of dynamic content. This content can be in the form of articles, blog posts, comments, guest books, shopping carts, product lists, photo galleries, personal details, usernames, passwords the list goes on. Whether the web server is Apache on Linux or IIS on Windows, if its running a server side scripting language such as PHP, ASP, JSP, CFM it is likely there is a database in the background storing all this dynamic content.
SQL Injection involves bypassing the normal methods of accessing the database content and injecting SQL queries and statements directly to the database through the web application in order to steal, manipulate or delete the content. System access is even possible in some instances where the database is able to manipulate system resources, this can end up with entire system compromise and attackers in your network (not only stealing all your data).
Have you looked closely at the full URL of the websites you visit?
?itemid=944 ... this is a parameter that is sent via the web application to the database in order to retrieve the content you are looking at.
HTTP GET based SQL injection we can manipulate these parameters to send unintended statements into the Database. For example; Instead of retrieving article number 1, why don't you show me article number 1 AND all the users and passwords in your database....
SQL Injection Vulnerabilities are also very prevalent in the form fields of web applications.
Form based sql injection is conceptually the same, the only difference being the rogue SQL statements are inserted via a POST request on the form submit rather than the HTTP GET parameter.
Username / Password forms are a well known point of attack. One type of attack allows the bypassing of the password part of the login.
This tells the database to not worry about the rest of the SQL query (the password part) and just perform the function of "if username = googleadmin and a=a --" (then give the user access to the system). Oops!
SQL Injection can also be used to attack other points of web applications, even cookie parameters - however HTTP GET and HTTP POST requests are the most common vectors.
Fixing SQL Injection
It is simple in theory, not so easy in practice as can be seen by the on going attacks with SQL injection based compromises resulting in literally millions of database records lost.
All user editable points of input into a web application must have the input's sanitised to prevent the execution of unauthorised SQL code. The OWASP site has some excellent information if you are looking for more detailed technical resources.