SQL INJECTION

Print Friendly, PDF & Email

SQL INJECTION

SQL vulnerability ranks at top of the list in our government constituency. It has, therefore, become quite paramount for the team to come up with an article to help ourselves protect our priceless application from getting victimized in the Internet space.

SQL(Structured Query Language) Injection is a technique where malicious code is injected into an SQL statement from web page input that can alter SQL statement compromising the security of a web application. This happens when user inputs are not validated.

Mitigation of this vulnerability is much more complex than just applying the Security patch, since it can exist even when software is up to date. Traditional Security Measures like using SSL(Secure Socket Layer) and IPSec (IP Security) cannot protect Applications from this attack.

Using dynamic SQL queries with flawed input validation, input sanitization and escaping leads to an application being vulnerable to SQL injection vulnerability.

  1. Impact:
    A successful SQL injection can empower the attacker with privilege to get hold of sensitive (critical) information from database like user account credentials and deface (Modify) web content or completely compromise the system also leading to Denial of Service (DoS).
  2. Mitigation
    • Minimal Installation-
      •  It is recommended to install or enable only the required features especially in Server environment to ensure that potentially harmful feature/ programs are not Enabled.For instance: Using Extended Procedures like xp_cmdshell the attacker can get complete control of the device on which the server resides, thus it is advised to disable this feature.
    • Least Privilege:
      • Do not allow an application to run with database administrators privilege that would leave an opportunity for attacker to perform almost everything on database.
        It is recommended to assign a least privileged account to services during installation of SQL Server.
    • Use Parameterised Input with Prepared Statement
      • Prepared statements are kind of SQL template that can be customised using variable parameters. If only prepared statements are used, attacker will not be able to change the intent of the query since it allows database to distinguish between code and data. Thus, it is recommended for developers to make use of prepared statement as a primary means to fight SQL Injection.
    • Use Parameterised Input with Stored Procedures
      • When using parameters, input is treated as literal value instead of executable code and it allows you to enforce type and length checks.
    • Use the Parameterised Input with Dynamic SQL
      • In situations where it is difficult or not convenient to use stored procedures, parameter collections can be used even with Dynamic SQL to fight SQL Injection.
    • Validate Input:
      • Ensure that no illegal characters are inserted. Use Regular expression to reject unexpected inputs: for instance throw an exception or error if numbers inserted in name field.
    • Encryption:
      • For “data at rest” always encrypt sensitive data like passwords, personal codes, and credit card numbers. With this even if the attacker inject malicious code and gets into database table, he will not be able to understand encrypted data. B, bigger the key size, harder will it be for the attacker to decrypt it. MD5, DES, SHA-0 and SHA-1 are no more considered safe. SHA- 512 and AES are still considered to be secure enough.
    • Patch:
      • Keep the application (all layers: operating system, database, middleware, frontend) up to date, while this cannot stop the attack, it can combat and delay the same.
    • Error Messages:
      • Ensure that error messages do not expose information about internal database or application architecture which would smoothen the attacker’s route to system.
    • Use Web Application Firewall
      • It provides set of rules to filter potentially dangerous web request and also has SQL injection defences. There are options to use an open source WAF software.
    • Periodically review and remove not in use Stored procedures and Prepared statements
    • Test your application during development and before going live (Security to be incorporated in every stage of software development)
    • Log SQL queries and related actions in all application layers.
  3. Testing Tools
    • Sqlmap
    • HP’s SQL Injector
    • Absinthe
    • Firefox Extension—SQL Inject-Me

For More Details

https://php.net/manual/en/security.database.sql-injection.php

https://www.codeproject.com/Articles/9378/SQL-Injection-Attacks-and-Some-Tips-on-How-to-Prev

https://msdn.microsoft.com/en-us/library/ff648339.aspx

http:/resources.infosecinstitute.com/parameterized-sql-query-dynamic-sql-query

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)

ttps://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

https://php.net/manual/en/pdo.prepared-statements.php