SQL Injection- A proper way to attack websites!

SQL injection is a popular way to attack websites. Developers can easily make coding mistakes that leaves a site open, and the payoff from getting access to the database can be big. Coding a site with no injection vulnerabilities takes not just careful programming, but an overall discipline that prevents mistakes. 

There are several types of SQL injection, but they all involve an attacker inserting arbitrary SQL into a web application database query. The simplest form of SQL injection is through user input. Web applications typically accept user input through a form, and the front end passes the user input to the back-end database for processing. If the web application fails to sanitize user input, an attacker can inject SQL of their choosing into the back-end database and delete, copy, or modify the contents of the database. An attacker can also modify cookies to poison a web application's database query. Cookies store client state information locally, and web applications commonly load cookies and process that information. A malicious user, or malware, can modify cookies to inject SQL into the back-end database. Server variables such as HTTP headers can also be used as a SQL injection attack vector. Forged headers containing arbitrary SQL can inject that code into the database if the web application fails to sanitize those inputs as well. Second-order SQL injection attacks are the sneakiest of the bunch, because they aren't designed to run immediately, but much later. A developer who correctly sanitizes all their input against an immediate attack may still be vulnerable to a second-order SQL when the poisoned data is used in a different context. 

Any input to your web application database should be considered untrustworthy and treated accordingly. Also limit account privileges. Assume a breach. What if a developer fails to sanitize a single user input field? Sanitize input but assume something is going to slip past you. Limit the account privileges of the database user. Is your web application read only. The principle of least privilege applies here. Give the web application the minimum privileges it needs to run. 

Stored procedures can also make SQL a lot harder — although not impossible. If your web application only needs to run a handful of SQL queries, create stored procedures to execute those queries. Typically, only the database administrator has privileges to create or modify stored procedures. Be aware, though, that many databases ship with default stored procedures out of the box, and attackers know this. Consider removing those default stored procedures unless you really need them.