“SQL injection (SQLI) is considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project. In 2013, SQLI was rated the number one attack on the OWASP top ten.”
Wiki: SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application’s software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.
According to the Open Web Application Security Project (OWASP), injection attacks are first on the list of the top 10 web vulnerabilities. Diving into these, SQL injections are responsible for a big chunk of this. Exploitation of SQL injections is trivial. This vulnerability is not just web related but can also occur in desktop applications that use SQL server backends. The detectability of these vulnerabilities depends on the complexity of the application in question. Most times, point-and-shoot tools fail to successfully detect these vulnerabilities. Sometimes there is difficulty in putting the desired conditions to successfully exploit the injections into these point-and-click tools, causing the vulnerability to go unnoticed. A generic solution to prevent these sorts of flaws from creeping in while programming is to sanitize all inputs and use proper encoding, furthermore using the white-list approach to allow only data which needs to be used by application.
Forms of SQL Injections:
SQLI : A simple common example
When SQL is used to display data on a web page, it is common to let web users input their own search values.
Since SQL statements are text only, it is easy, with a little piece of computer code, to dynamically change SQL statements to provide the user with selected data:
Server Code
txtUserId = getRequestString(“UserId”);
txtSQL = “SELECT * FROM Users WHERE UserId = ” + txtUserId;
The example above, creates a select statement by adding a variable (txtUserId) to a select string. The variable is fetched from the user input (Request) to the page.
SQL Injection Based on 1=1 is Always True
Let’s say that the original purpose of the code was to create an SQL statement to select a user with a given user id.
If there is nothing to prevent a user from entering “wrong” input, the user can enter some “smart” input like this:
UserId:
Server Result
SELECT * FROM Users WHERE UserId = 105 or 1=1
The SQL above is valid. It will return all rows from the table Users, since WHERE 1=1 is always true.
Does the example above seem dangerous? What if the Users table contains names and passwords?
The SQL statement above is much the same as this:
SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1
A smart hacker might get access to all the user names and passwords in a database by simply inserting 105 or 1=1 into the input box.
The Storm: How bad SQLI can get
The Storm Worm was one representation of Compounded SQLI and accounted for 8% of the total threats at its time.
It was late 2006 when computer security experts first identified the worm. The public began to call the virus the Storm Worm because one of the e-mail messages carrying the virus had as its subject “230 dead as storm batters Europe.” Antivirus companies call the worm other names. For example, Symantec calls it Peacomm while McAfee refers to it as Nuwar. This might sound confusing, but there’s already a 2001 virus called the W32.Storm.Worm. The 2001 virus and the 2006 worm are completely different programs.
The Storm Worm is a Trojan horse program. Its payload is another program, though not always the same one. Some versions of the Storm Worm turn computers into zombies or bots. As computers become infected, they become vulnerable to remote control by the person behind the attack. Some hackers use the Storm Worm to create a botnet and use it to send spam mail across the Internet.
To conclude, there are several approaches to combating these types of attacks; protections in the application, such as whitelisting and parameterized queries, and protections in the network, such as intrusion prevention systems.
Stay Vigilant! Happy Computing!
Image Courtesy: http://en.wikipedia.org/ , http://cis1.towson.edu/
Content Courtesy: https://www.owasp.org/, http://en.wikipedia.org/
You must be logged in to post a comment.
