in android, ios, mobile

Common Vulnerabilities seen in Most Mobile Application

Use of mobile device and its accessibility is increasing day by day in recent time. Thanks to the technological advancement for this. For the same reason, these devices are now turning into the gateway to leak user’s personal information and confidential credential from hacker all around the world. Devices are often blamed for insecurities, but we mobile devices vulnerabilities are insidious most of the time. So in this article, I will discuss common vulnerabilities in the mobile application that we may be overlooking.

User Input and Login related weaknesses

Mobile application is for making life easier for targeted user. To provide personalized data we need to take input from a user via Login, Signup or some other approach. Accepting user input also enables application vulnerability if not properly handled. The following are common mobile app security flaws I often come across that you need to be on the lookout for:

  • Debug Message: While developing mobile application developer print user input to the console for debugging purpose. This can be any thing such as username, password, credit card and other. And most of the time developer forget to remove this piece of code from the production version of the application. All the message that was printed on console is store in OS specific log file which can be easily accessible to other, which in turn open backdoor to intruders for misusing or hijacking user account.
  • Sending user input in plain text over HTTP or https: Most of the time mobile application and server application are developed by two separate teams. In such scenario, because of week system architect information are being the exchanged in plain text format between the server and mobile application over HTTP or https (public network). Sending username and password in plain text over HTTP for authentication is of no use because such information can easily be decode by intruders.
  • Sending encoded user input over HTTP or https: At this moment we understand sending plain text user input is the worse approach for communication between client and server. Now one may think encrypting user input may add security layer. But the bitter truth is you are just fooling yourself. There is no point sending encoded user input over HTTP or https either. Confused ? Let me simplify this issue with an example. You and your friend understand English so both of you use the English language as a communication medium. Using Chinese as your language don’t add any security in your conversation. Plain Text (English) = Encoded Text (Chinese). Intruders can get user password as in plain text method and use curl command or bash script to drill down your account again.
  • Using one-time token: From above 2 issue you might be thinking, I am in favor of sending the plain text of encoded text over HTTP. No, we always need to follow end to end encrypted information exchange. In addition to that, we also need to use one-time token within the session or request. This will invalidate the use of stolen user input.
  • Limiting login / forget attempt: There are lots of web services used by a mobile application which does not record no of failed login / forget attempt. Because of this, all of the user accounts of such service can be easily hacked. Just keep trying different password until you get success. For the human this may be frustrating, but not for the computer.
  • Mishandling of sensitive information: One of the top reasons why mobile application vulnerabilities exist is because inexperienced programmers have bad data storage habits. All it takes to access the data stored on an unlocked smartphone running a poorly written app is a simple extraction of the file attached to the mobile application. Similarly, cryptographic keys hard-coded into the app that can be accessed using mobile forensics tools.
  • Using same public key in both mobile and server for encryption and decryption, SQL injection, Javascript Injection are some other advance vulnerabilities

Write a Comment

Comment