Definition of SQL Injection

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).

How SQL Injection impacts the Android O.S

The SQLite used in android apps are fully functional databases, so just like SQL Server or MySQL box they can be susceptible to SQL injection. SQL injection typically works by adding data to the query string or adding data in a form field; to give hackers access to a database or unauthorized logins. SQL Injection is usually used to attack Web Views or a web service but it can also be used to attack Activities.

The root cause of the SQL Injection vulnerability is due to the use of dynamic or concatenated SQL queries. If SQL queries are constructed by concatenating user supplied inputs; The user can then supply SQL attack vectors instead of valid inputs and manipulate the backend SQL query.

The injection process works by prematurely terminating a text string and appending a new command. Because the inserted command may have additional strings appended to it before it is executed, the injected string is terminated with a comment mark “–”. Subsequent text is ignored at execution time.

My Question

Although I understand what SQL Injection is and how SQL Injection can take place. I don't know what factors makes a selection of Android code vulnerable to such an attack.


SQL injection attacks apply when an application uses SQL and carelessly assembles SQL requests with attacker-provided elements. Here, "carelessly" means "without using prepared statements". Prepared statements are the correct way to do SQL with externally provided data; many developers try to think of it in terms of "escaping quoting characters", which is a bad method and leads to disaster (even though some escaping ultimately happens, only prepared statements guarantee that it is done properly).

Android is not a factor in all this, except very indirectly: Android comes with SQLite, hence developers are very tempted to use it and thus fiddle with SQL, even in cases where it is not strictly necessary. When your only tool is a hammer, problems had better be nails, because there's going to be some serious hammering. Of course, when developers are given the power of SQL but are not careful enough to use it properly, then SQL injection attacks become a definite possibility.

Another effect is that Android applications are based on a Java-like language, which is inherently protected against buffer overflows (because all array accesses are systematically checked) and double-free and use-after-free situations (because of the GC-based memory management). Therefore, other kinds of attacks mechanically constitute a bigger proportion of all overall vulnerabilities. Having lots of SQL injection vulnerabilities in Android apps may be, in fact, the result of having comparatively much fewer of other kinds of attacks.


SQLite supports prepared queries and bound parameters, so the issue is more with the use of the tool, rather than the tool itself.

If query parameters are used it's impossible to inject SQL into the process because the data is handled separately from the statement. The issue only arises if the developer has done something like:

SQLStatement = "select * from users where password='"+thePassword+"' and email='"+theEmailAddr+"';";

This is because it give the end user the opportunity to type in a password that terminates the statement and adds another, or specify conditions where any password would work. For example, if the user types in a password of

' or password!='fred

and a real email address, say whosit@whatamacallit.com, then the query sent to the database is:

select * from users where password='' or password!='fred' and email='whosit@whatamacallit.com';

If you use parameters, then there is no option to inject new sql into the command text, because the data is treated separately from the command.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy