SQL Injection: A Major Threat to Data Security

Of all the attacks taking place on Web sites across the Internet today, SQL injection is the most popular for cybercriminals trying to hack their way into corporate data stores. But for such a pervasive threat, there is still little understanding within the development and database communities about what constitutes a SQL injection vulnerability, how attacks against a SQL injection bug work, and how to mitigate the risk. Examine how these exploits work and what you can do to stop them.

Advertisements

About RamesesIII

Adjunct Instructor ITT-Tech IT Dept. View all posts by RamesesIII

9 responses to “SQL Injection: A Major Threat to Data Security

  • Catherine Childs

    A successful SQL injection attack don’t always lead to compromise of the actual database server: often, the attacks instead result in complete exposure of the database contents, which could be anything from a simple listing of all users and their passwords, or much worse, all customer data including credit card information. SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.The most common methods to prevent this kind of SQL injection vulnerability are to check the user’s input for dangerous characters like single-quotes; and using prepared statements, which tell the database exactly what to expect before any user-provided data is passed to it. The prevalence of SQL injection vulnerabilities and the ease in which they can be exploited begs the question of why aren’t more companies finding the vulnerabilities and securing their systems accordingly. The tools exist for scanning and detecting the flaws and many of them are free and quite effective, but for some reason, they just aren’t being used proactively for detection before an attacker has the chance to exploit them.

    Principle : Never trust user input
    Implementation: Validate all textbox entries using validation controls, regular expressions, code, and so on.

    Principle: Never use dynamic SQL
    Implementation: Use parameterized SQL or stored procedures.

    Principle: Never connect to a database using an admin-level account.
    Implemenatation: Use a limited access account to connect to the database

    Principle: Don’t store secrets in plain text
    Implementation:Encrypt or hash passwords and other sensitive data; you should also encrypt connection strings.

    Principle: Exceptions should divulge minimal information.
    Implementation:Don’t reveal too much information in error messages; use custom Errors to display minimal information in the event of unhandled error; set debug to false.

    Sources:

    http://en.wikipedia.org/wiki/SQL_injection
    http://www.topbits.com/sql-injection-attack-vulnerability.html
    http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=219401046
    http://msdn.microsoft.com/en-us/magazine/cc163917.aspx

  • Ryan Brown

    SQL injection attacks exploit the lazy or inexperienced programmer. Any SQL transaction that is processed from a web originated request should have its input validated (no exceptions) and every measure available should be taken to obfuscate the information regarding the SQL transaction in the web source code.

  • Tyler Manuel

    I agree with Ryan’s post, there is way too many tools and policies that could be put in place to prevent majority of SQL injection attacks. SQL is essentially putting your own code into the scripts to gain access to the system.

  • Nolan Oribello

    There are various security tools that you can use to detect SQL injection via scanning, and to protect at the IIS, including a Source Code Analyzer for securing at a coding level. It would also be beneficial to have developers implement a Quality Assurance procedure to validate the security of code before it is put into a production environment.

  • Robert Wooldridge

    http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=219401046

    SQL injection attacks take advantage of an application not validating input (like on Twitter and Facebook), or input into a form, such as a site search. The user’s input is then incorrectly executed by the backend database server and can have a myriad of results. The simplest example is entering a single quote (‘) into a search field or login form, and receiving an error message that the SQL query failed.

    http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Primary_Defenses

    Defense Option 1: Prepared Statements (Parameterized Queries)
    The use of prepared statements (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
    Defense Option 2: Stored Procedures
    Stored procedures have the same effect as the use of prepared statements when implemented safely*. They require the developer to define the SQL code first, and then pass in the parameters after. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.
    Defense Option 3: Escaping All User Supplied Input
    This third technique is to escape user input before putting it in a query. If you are concerned that rewriting your dynamic queries as prepared statements or stored procedures might break your application or adversely affect performance, then this might be the best approach for you. However, this methodology is frail compared to using parameterized queries. This technique should only be used, with caution, to retrofit legacy code in a cost effective way. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries.

  • Courtland Richardson

    Concerning how these exploits work and what you can do to stop them: http://cnettv.cnet.com/sql-injection-attacks/9742-1_53-50070801.html

    Who: performed by a hacker
    What: application based attack. also known as SQL insertion attacks
    Where: database server or any place where data is hosted and sought after by hackers/authorized access users
    When: at some point when the database is unsecured or misconfigured
    How: passing string statements with hope of valuable returns

    Prevention: the payload or database should be hosted in such a way that generic or common attack methods will fail. The admin or department that maintains the information should be well versed in securing critical data, as well as up to par on common and well known methods used by hackers to extract said payload. Further implementation of the database should be divided, or segregated in such a way that data tables are not embedded within one another; rather data tables should, when possible, exist as individual entities and called upon by specific characteristics that allow for individual returns drawn upon by statements that do not extract lump sums of data. Example, when the database is queried by an attacker, the output syntax should not resemble the result of valid parsing, nor tip the hacker off in any way, as to how to continue querying that database for the desired payload!

    Other forms of securing the database or application from an SQL attack would be creating an environment wherein brute force attacks cannot be used to gain passwords, or worse, r00t access. Furthermore, there should always be some sort of security policy that can assess local/remote attempts to access critical assets. Whether logical or physical attacks are performed, the system should be configured in a manner that is caching or archiving/encrypting log files, distributing account lockouts (if necessary) or performing other predetermined actions in order to implement the scope of said security policy, thus hardening and preventing unauthorized SQL Injection.

    The creation of blacklisted (I hate that word!) characters, strings, symbols, etc, should be maintained as an additional method of hardening the database server. Countermeasures are very important when obstructing attacks. Taking away the :green light” or “open gate” will assist the admin or IT department and probably ensure that some of the less experienced attacks will simply give up and walk away.

    Of course I have never performed this attack not do I really know how to. I hope that this loose explanation comes close to answering the post on SQL Injection.

  • Fred

    SQL Injection: A Major Threat to Data Security:

    Question: Of all the attacks taking place on Web sites across the Internet today, SQL injection is the most popular for cybercriminals trying to hack their way into corporate data stores. But for such a pervasive threat, there is still little understanding within the development and database communities about what constitutes a SQL injection vulnerability, how attacks against a SQL injection bug work, and how to mitigate the risk.
    Examine how these exploits work and what you can do to stop them.

    Answer: SQL attacks take advantage of a SQL application not taking a validation check to determine if the input legitimate and if there is not a validation check then the input could the unwanted, or wanted, affect of executing incorrectly at the backend database which could then bring down the SQL server or open or show a weakness or exploit.
    You could shore up the SQL database with eliminating all end user input so that it never makes unwanted query to the SQL server you would do this by assigning or making a dynamic library of sorts with prepared statements but realize this is a time consuming and bug/weakness prone technique.
    You could also use prepared statements which are process easier than dynamic database queries and this could allow the SQL server to tell the difference between valid date input versus code input and if it is possible you can have the rules or code of the SQL servers database assign privileges to certain users to allow code execution and/or log these events to an outside server for review so that the Admin can further shore up the SQL server database code against this type of un-authorized input.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: