Security Vulnerability in Room Persistence Library
Table of contents
Room persistence library is the preferred way of implementing local storage in an android app when it has to deal with non-trivial amounts of structured data.
The Room persistence library provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite
One of the great benefits Room offers over its alternatives like Realm, Firebase Realtime DB, GreenDAO etc is that it provides compile-time verification of SQL queries. This means that you don’t have to run the app to check if the tables name or field names you’ve entered are correct or not. The compiler shows an error immediately if any of these don’t match with your Entity classes. This decreases the amount of testing a developer has to do and helps them catch and rectify bugs that otherwise might have easily slipped through.
In simpler terms
Room generates the implementation files that contain the actual SQL queries and takes care of all the boilerplate code. These SQL queries contain the names of all the Entity classes we created and the fields that we want to create inside each of these tables along with their format.
One major drawback
When we try to obfuscate the code using Proguard or R8, these hardcoded values in the generated files are unaffected. This means that if someone were to reverse engineer the APK, they would essentially get access to the whole backend schema of your local database. It might even be possible to decode the other parts of the business logic and API signatures, once you follow the entity object flow.
If the local database structure is completely different from the backend schema design, then the impact of exposing the local schema can be minimized. Potential hackers would not be able to figure out your backend or the API structure even if they have the whole local database mapped out.
But still, this creates a big hole in the security of any application that deals with personal user information or have some proprietary logic on the front end. Most applications focusing on financial data don’t store data locally due to security concerns but applications in domains like e-commerce or games might become extremely vulnerable due to this.
Similar problems
Although this article only highlights the issue in Room, every other ORM library has similar problems. Realm, for instance, takes the table and column names in the form of hardcoded strings when querying data thereby exposing them to possible hackers. This is a universal issue that requires ORK designers to think about a new approach where queries do not expose the schema underneath. It is a very tall order but one that needs to be fixed in the era of massive Data Leaks and Intellectual property thefts.
Room persistence library is the preferred way of implementing local storage in an android app when it has to deal with non-trivial amounts of structured data.
The Room persistence library provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite
One of the great benefits Room offers over its alternatives like Realm, Firebase Realtime DB, GreenDAO etc is that it provides compile-time verification of SQL queries. This means that you don’t have to run the app to check if the tables name or field names you’ve entered are correct or not. The compiler shows an error immediately if any of these don’t match with your Entity classes. This decreases the amount of testing a developer has to do and helps them catch and rectify bugs that otherwise might have easily slipped through.
In simpler terms
Room generates the implementation files that contain the actual SQL queries and takes care of all the boilerplate code. These SQL queries contain the names of all the Entity classes we created and the fields that we want to create inside each of these tables along with their format.
One major drawback
When we try to obfuscate the code using Proguard or R8, these hardcoded values in the generated files are unaffected. This means that if someone were to reverse engineer the APK, they would essentially get access to the whole backend schema of your local database. It might even be possible to decode the other parts of the business logic and API signatures, once you follow the entity object flow.
If the local database structure is completely different from the backend schema design, then the impact of exposing the local schema can be minimized. Potential hackers would not be able to figure out your backend or the API structure even if they have the whole local database mapped out.
But still, this creates a big hole in the security of any application that deals with personal user information or have some proprietary logic on the front end. Most applications focusing on financial data don’t store data locally due to security concerns but applications in domains like e-commerce or games might become extremely vulnerable due to this.
Similar problems
Although this article only highlights the issue in Room, every other ORM library has similar problems. Realm, for instance, takes the table and column names in the form of hardcoded strings when querying data thereby exposing them to possible hackers. This is a universal issue that requires ORK designers to think about a new approach where queries do not expose the schema underneath. It is a very tall order but one that needs to be fixed in the era of massive Data Leaks and Intellectual property thefts.
Give your product vision the talent it deserves
building your dream engineering team.
.webp)
