Hi guys, today we are going to see the Insecure Data Storage from the OWASP Top 10 mobile. In this there we have few important storage type through which we face problems(vulnerabilities). The types are as follows

1. SQL Databases.
2. Log Files.
   
3. XML Data Stores / Shared Preferences.
   
4. Browser Cookie Objects.
   
5. HTML5 Data Storage.
   
6. Copy/Paste Buffer Caching.
   
7. Keyboard Press Caching.
   

We will see them in detail.

SQL Databases:

We need SQLite Database to store data in mobile, it is the commonly used storage type in the mobile application. It is very easy to use. In this type, we have the risk of vulnerability as the developer stores the data for caching purpose or maybe second-time use which is not a good practice at all. Sensitive data need not be stored in this database like username, password, debit card number etc. We found the vulnerability in one of the application but can’t tell you the name of application where they stored the username and password. It is easy to retrieve the data from SQLite DB when the phone is rooted.

Prevention:

We need to hash/encrypt data before inserting in DB and we can avoid inserting sensitive data into DB.

Log Files:

In this medium of storage the developer log the value of the few fields or variable which is always helpful for them to track the output, but they forget to remove them which could cause harm to the client. The logger file in android mobile is common for all application and could be accessed through the available application. If the developer logs the username, password or any sensitive information then it could be accessible to all application. So it is recommended to remove log while launching the app. We found the vulnerability in one of the application where they log username name and password.

Prevention:

The developer needs to remove log after the development is over.

XML Data Stores/ Shared Preference:

In this method of storing the data is stored in the XML file which is available in the application package folder, similar to above application in this also we have the same possibility of vulnerability. So it is recommended to not to store any sensitive information in shared preference or any other storage medium. The same application which we tested we also found the shared preference where developer stores the username in the XML file. If we really need to store data then we must encrypt it or hash it so that the attacker could not get the data.

Prevention:

We need to avoid storing the sensitive data in the XML file or text file.

Keyboard Press Cache:

In this method, the data which we type is stored in the cache of the keyboard, where the words are stored for auto-correct use. The stored data in the keyboard cache is accessible to all app without asking any permission from the user. The data like password, username, debit card number etc, these kinds of data is stored in keyboard cache then it could be harmful to the client and could be easily accessed by other apps which is vulnerable. In one the application we tried to type username few times and it got stored in the cache and it could be easily accessible to all app. It is recommended not to use the external keyboard and clear the cache of the keyboard.

Prevention:

We need to avoid using the third-party keyboard and can developer can avoid caching of the particular field on the keyboard .

Copy/Paste Buffer Cache:

In this medium of storage, the data whatever we copy and paste to anywhere is stored in the clipboard. So, for example, we copied the debit card number from one place to another for our convenience is also stored in the clipboard. Similar to keyboard cache this clipboard cache can also be accessible to all application available. So if the clipboard data is not cleared then it could be easily available for others to use. This could be vulnerable and our data could be leaked so we need to keep an eye on it and do not allow the user to copy data from few sensitive fields.

Prevention:

We need to disable copying feature in sensitive fields.

HTML5 Data Storage:

HTML5 applications run in the browser, so we don’t have access to the storage options that native applications do. We do still have access to the usual browser storage options that websites have access to though like Data Storage, Web SQL (deprecated) and IndexedDB.

Data Storage:

• The read-only data storage property allows you to access a storage object for the Document’s origin; the stored data is saved across browser sessions. It gets cleared when the page session ends. that is when the page is closed.
  

• It is more difficult to share your data with others. the world of work people are required to work collaboratively and share the work and therefore it is easier to do this with a hosted storage.
  

• More expensive than traditional external hard drives, Possible theft, and the storage space you have on hand is all you’ve got. If you need to increase your storage capacity, you’ll have to invest in more hardware.
  

• Information stored on your local hard drive is exposed to Internet hackers whenever you open a port to use the Internet.
  

• To access your files everywhere the only thing you need is the internet connection. If you don’t get internet connection somewhere then you will end up with no access to data even though it is safely stored online.
  

Example:

you need to upload to a hosted server and then either send an email or a link to the intended user

Prevention:

We need to avoid storing the Sensitive Data in HTML local storage and can hash the data.

Browser cookie objects:

• The cookie is stored in the user browser; the client sends this cookie back to the server for all the subsequent requests until the cookie is valid. The container checks the request header for cookies and get the session information from the cookie and use the associated session from the server memory.
  

• When a cookie is not set securely, then it is sent by the browser even with unencrypted requests, even if they are generated in an application. If an attacker is able to intercept such requests, he can steal the cookie.
  

• When looking for Cookie Vulnerabilities, an attacker will first observe cookies through various HTTP proxies and check their attributes. He will then try to steal cookies from various users by employing multiple attacks. If he is successful, he may be able to get sensitive information which can be further used for his own profit in an illegitimate way.
  

• If an attacker compromises a large number of Web applications, he may be able to gain access to multiple sessions and then use them for large-scale identity theft or other attacks.
  

• Cookies are not secure as they are stored in clear text they may pose a possible security risk as anyone can open and tamper with cookies. You can manually encrypt and decrypt cookies, but it requires extra coding and can affect application performance because of the time that is required for encryption and decryption.
  

• Users can delete a cookies and Users browser can refuse cookies, so your code has to anticipate that possibility.
  

Prevention:

We need to avoid storing the Sensitive Data in Cookie Object and can hash the data.