SQLite Injection – Input Validation security risk – #7 DIVA Solution

Android uses SQLite database to save things locally within the device internal memory as managed Relational Database Management System (RDBMS). Majorly used to save app activity or user’s personal details or transaction logs or state of the app by developers. Article unencrypted SQLite DB security risk explained about exploiting database confidentiality over unencrypted DB. In this article you would see for both encrypted or unencrypted SQLite database can it be exploited via SQLite injection. For SQLite injections you don’t need Rooted device, it can work on all devices and all OS versions.

As per this app functionality you should only be able to view account details of single user you enter, however information for all users is visible in clear-text from SQLite Database on performing SQLite injection. The cause SQLite injection is missing user input validation. Whatever user enters from text-field is directly passed to SQLite query string, as a result attacker can manipulate and form a query which results all results. The concept is quite similar to SQL Injection for web-apps, with minor changes as per SQLite query syntax.


The video demonstrates DIVA app to understand SQLite injection. Here aim is to view details for all users of the app in form of Android Toast message.


In general any database SELECT query to retrieve all column details for condition based on certain COLUMN is like :


Here if COLUMN_1 and COLUMN_2 both values match from the database then only query will result data as an output, otherwise no response. When attacker performs injection, the try is to break  AND operation, and try to convert it OR so that irrespective of first condition is matching or not, attacker can make condition true post OR operator. Since OR conditional operator would respect it, as the Condition after OR operator is true and give the output as attacker wanted.

So in our case we first fool the query parser by adding  ‘ (single quote) to terminate value for condition username. Next we add OR operator followed by check which should always go true i.e. ‘1’=’1 (remember to maintain matching opening and closing quotes, we don’t have to close with single quote as we already introduced additional quote in beginning – so there is one closing quote already as part of query present). Since 1 would be always 1 making the statement true, so entire query would now become as below:

SELECT * from sqliuser where user = ‘randomname‘ or ‘1’=’1‘ ;


Depending upon what data is saved within your app, risk level can vary. Leading to very serious issues as this attack neither needs device to be rooted nor app in debug mode.


  • Using Prepared statements to access SQLite DB and never using Raw query, which attacker can modify and exploit.
  • Considering any user data as untrusted, it should be properly sanitized. Whitelisting – Blacklisting (less preferred) – Regex matching can be used to identify malicious user input.

Report Errors + Bugs & Become Insider for Nestedif.com

We would like to hear you, if you find any error or misspelled phrase while reading our tutorials. By reporting mistakes through email to insider@nestedif.com you could help other peers.