Today we will learn about SQL Injection by Untrusted Data Parsing. In our previous article we have learned about “SQL Injection basics” which is #1 among Injection attacks. We have learned that SQL Injection majorly occurs because of three things :
1. Untrusted Data Parsing
2. Dynamic Queries Creation from user data.
3. Escape Sequences, Encoded Character Set Parsing.
Today we are going to learn about SQL Injection by Untrusted Data Parsing. How an data from untrusted source can result into SQL Injection flaw.
 |
| SQL Injection by Untrusted Data parsing |
What is untrusted data?
Here’s a simple rule which is applicable for all web applications. If you are not sure that incoming data doesn’t contain attacks, then it’s untrusted. All the data from the browser, including URL parameters, form fields, headers, and cookies are all untrusted. But so are other sources like flat files, web services, databases, etc… Even internal sources of data can (and probably should) be considered untrusted.
Most untrusted data comes in the form of a “string” without any restrictions on the size, characters, format, or pattern.
SQL Injection by Untrusted Data Parsing:
Most web applications or web pages use web forms or text boxes(like search box etc.) to accept data from users. Developers consider the data coming through these text boxes or web forms as trusted data and use this data in their programs for some other functionality. But in real world scenario, the data from web forms or text boxes should not be considered as trusted or safe because data can come from untrusted sources like unvalidated users, network connections and other untrusted sources. The data coming from web forms or text boxes must be sanitized before using it further in the web application programs or i would advise that it should be validated even before sending to parser.
Untrusted data must be sanitized because subsystem might not be prepared to handle this malformed data input. Also this untrusted data may even contain the Injection attack attached with it.
Ideally data must be validated before it is being sent for parsing or interpretation. If it contains anything suspicious which you think that your sub program will not be able to handle, then it must be sanitized before sending for parsing.
Consider an database which have a users table where user names and passwords are stored to authenticate users to use the web application.
SELECT * FROM users WHERE username=’+USERNAME+’ AND
password=’+PASSWORD+’
Now this query will work successfully when user supplies correct username and password.
Now once user provides correct username and passwords, this SQL works perfectly but in case user has supplied some special characters or special sequences or some random data in username or password or both. If the user input is not sanitized properly then it will result into SQL Injection attack.
Characters like ‘(single quote), “(double quote), -(single dash) , –(double dash), =(equals), (, {, /* etc.. are part of SQL database language syntax, these characters provides different functionality. So if any user passes any of escape sequences or data type which SQL parser understands then SQL will not work as it should. It may result into error or just successful execution. Whatever is the result, but one thing is confirmed that web application or website is vulnerable to SQL Injection.
Now say i passes user123′ or ‘1’=’1 in the username, then the SQL will become something like:
SELECT * FROM users WHERE username=’user123′ or ‘1’=’1′ AND password=’PASSWORD’
Now if user123 is an valid user then this SQL will fetch the user123 from the table and password will never be checked because statements after ‘OR’ is not being tested according to syntax of SQL. So user123 will able to login into website if the user123 is a valid user.
Now suppose i pass ‘ OR ‘1’=’1 in password and pass null or spaces in username, now SQL will become something like :
SELECT * FROM users WHERE username=” AND password=” OR ‘1’=’1′
Now this OR will allow 1’=’1 always true condition i.e. whatever is the username or password it doesn’t matter because 1’=’1 is always true condition. So the hacker will login into website without any credentials at all.
This is the reason why Developer needs to sanitize the input Data received from web form or text boxes. None of the data can be trusted blindly, every field needs to be validated properly so that the untrusted data will not alter the actual behavior of the existing SQL and its functionality.
This type of SQL injection is also referred as Blind SQL Injection.
That’s it for today. In later article we learn other two causes of SQL Injection in detail and then we will learn how to protect ourselves from these type of vulnerabilities.
dns says
Aw, this was an incredibly nice post. Taking a few minutes and actual effort
to produce a top notch article… but what can I say…
I hesitate a whole lot and never seem to get nearly anything done.