SQL (Structural Query Language) injection is an attack technique that trick database to execute unintentional malicious code. SQL injection usually involves combination of over elevated permissions, un-sanitized user input and/or true software vulnerabilities.
SQL Injection Attacks
SQL Injection attack is a kind of code injection vulnerability in which the attacker tries to get unauthorized access to data or bypass authentication by injecting crafted strings through web forms in a web application. In web applications, some of the data from the web forms are used for constructing Structured Query Language (SQL) statements and are executed in the database server. In SIA (SQL Injection Attack), the attacker injects data through the web forms, in such a way that the resultant SQL statement will produce malicious outcomes.
Consider the example Login scenario in which the variables user_name and password are entered through the web form. At the server, using these variables a SQL statement like “SELECT * FROM USER WHERE uname=’user_name’ and pwd=’password’“ is created and executed in the database. If the database returns any row corresponding to the above query, the user will be authenticated. In the above scenario if the attacker injects a crafted string like ‘or 1=1 –‘ at the username, the resultant SQL query will look like “SELECT * FROM USER WHERE uname=’ ‘or 1=1 –‘’ and pwd=’password’“ the symbol ‘—‘ will comment any statement after it. This results in the WHERE condition always evaluating to true and will return some row and the final output, the attacker will be authenticated to the system. This is a simple example of SQL injection.
In advanced SQL injection technique, the input strings are crafted in such a way that, the complete mapping of the entire database can be created. In this attack the queries are crafted in such a way that on executing the corresponding queries in the database, it will produce errors. These error statements are used further to make a finger print of the entire database of the system which could be used later for further attacks.
• Unauthorized Access by bypassing the Authentication.
• Unauthorized addition, deletion or alteration of data.
• Denial of Service (by deleting the entire Database).
Impact & Causes
The impact of any attack depends on the total damages caused and the ease with which the attack can be executed. Considering both the factors, the impact of SIA attacks are dangerously high. This is due to the fact that even a novice user with a set of injection string can perform the attack and it does not require any high level of technical knowledge. Moreover a successful SIA can result in administrative access to the attacker, finger printing of the entire database or deleting of rows in a table, complete table or even complete database itself.
The main cause of SQL injection vulnerability is the insufficient input data validation at the server. The point is that anything coming as an input to the server can cause a vulnerability, so before processing it, the input should be properly validated and filtered. The input validation at the browser using java scripts is not enough to prevent this kind of attacks as a professional attacker may use his own browser or advanced attack tools to inject the data. So the input data should be validated at the server side itself.
SQL injection Malware Attacks
Mitigation Technique and Best practices
Since SQL injection is possible even when no traditional software vulnerabilities exist, mitigation is often much more complicated than simply applying a security patch. Following are the best practices given by CERT (Computer Emergency Response Team) can be used to minimize the risks associated with this attack vector.
Network Level Recommendations
1. Deny access to the internet except through proxies for Store and Enterprise servers and workstations.
2. Implement firewall rules to block or restrict internet and intranet access for database systems.
3. Implement firewall rules to block known malicious IP addresses.
4. Harden internal systems against the potential threat posed by a compromised system on the local network. (Do not rely on firewalls to prevent access to insecure systems; secure them.)
System / Application Level Recommendations
1. Secure both the operating system and the application.
• Consider using NIST or other industry standard security checklists to harden both the operating systems and the applications.
• Run only the minimum required applications and services on server necessary to perform their intended function. In other words, disable all unnecessary applications and services.
• Follow application vendor security guidelines.
2. Update and patch production servers regularly.
• Include both operating system patches and application patches.
3. Disable potentially harmful SQL stored procedure calls.
• ‘xp_cmdshell’ on MSSQL has been frequently used by attackers.
4. Deny extended URLs.
• Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail to log the complete request. Unless specific applications require long URLs, set a limit of 2048 characters. Microsoft IIS will process requests over 4096 bytes long, but will not place the contents of the request in the log files. This has become an effective way to evade detection while performing attacks.
5. Sanitize/validate input.
• Ensure data is properly typed.
• Ensure data does not contain escaped code.
• Consider using type-safe stored procedures/prepared statements.
6. Ensure error messages are generic and do not expose too much information.
• Keep error messages short and usable.
• Do not disclose internal database structure, table names, or account names.
7. Use principles of least privilege.
• Install and run authorized Microsoft SQL Server and IIS services under a non-privileged account.
• Apply the principle of ‘least privilege’ on all SQL machine accounts.
• Remove guest accounts unless operationally necessary.
• Use an application account for database access.
8. Enforce best practice password and account policies.
• Require the use of a password on Microsoft SQL Server administrator, user, and machine accounts.
• Change default/built-in account passwords.
• Change application account passwords regularly.
• Use strong passwords.
• Lock out accounts after several unsuccessful logon attempts.
9. Document all database accounts, stored procedures, and prepared statements along with their uses.
• Delete/disable unnecessary accounts (including default accounts).
• Delete/disable unnecessary stored procedures/prepared statements.
10. Perform regular audits and penetration testing.
• Audit transaction logs for suspicious activity.
• Audit group and role memberships to ensure enforcement of least access principles.
• Audit stored procedures on a regular basis and remove unnecessary ones.
• If you use ASP, consider using Microsoft’s code analyzer.
• Consider using HP’s scrawlr utility to help identify problems.
• Conduct penetration tests against applications, servers, and perimeter security.
Research in ISRL (Information Security Research Lab)
SQL Injection Attacks are very popular today. But still, there are millions of web sites out there in the internet which are vulnerable to these attacks. These websites uses different web technologies like PHP, JSP, ASP, ASP.NET etc. Even though server side validation and filtering of users input is a method to prevent SQL Injection Attacks, a small flaw in it will produce this vulnerability. So ISRL is trying to build automated tools to secure the different web technologies from SQL Injection Attacks. Hence running the tool over the already present web application or newly developed web application will automatically secure it from all types of SQL Injection Attacks.
In the ISRL, we use a model based approach to achieve this goal. In this method, at run time each query generated by the instrumented web application will be validated against an approved model before running it in the database server. The model may either be statically determined or be dynamically calculated using different methods. Once the query is validated, the query is considered as safe and is run on the database. If the query cannot be validated, it is rejected as it can produce a possible SQL Injection Attack.
The video cannot be shown at the moment. Please try again later.