Thursday

OWASP Mobile Threat- A Guide for Mobile Developers For Detecting Risks

<!– Quick Adsense WordPress Plugin: http://quickadsense.com/ –>




With the massive growth of technology and the use of mobile applications users are finding it convenient to use and manage apps. But in the midst of this, the security threats have increased as the developer has to protect their application from various issues. If you take things at face value the apps or mobile devices might work out to be secure as global brands are behind their emergence. But the reality poses a different picture altogether. A research points to the fact a majority of the apps are prone to vulnerabilities.


OWASP Mobile Threat


Most of the contemporary apps available in the market store bank along with personal information about the users. Their objective is to provide a customized experience to the users. With the emergence of complex security threats, it is necessary for the developers to have a fair idea about the security threats. At this juncture, OWASP becomes a handy tool for security professionals.


It had its emergence in the year 2001 and targets a community of developers who go on to formulate methodologies, tools and documentation in the domain of security. Let us now flip through the OWASP mobile top 10 platform


Improper usage of the platform


The risk outlines the failure or misuse of an operating system to accomplish security control in a proper way. It includes platform transmissions, key chain, Android intents etc.  Their occurrence is a common task and on the affected apps the impact can be severe.


For example when it is an Android intent app you have to restrict permission so that an app is not able to establish communication with another app. Then there is another option where you can allow export opinion pertaining to intents.


Data storage in an insecure form


These points to the fact of how an adversary can go on to access the insecure data that is part of a mobile device. Now when there is physical access to any device you can access the file system when you attach it to the computer. In fact, an adversary explores multiple options for unsecured data in a compromised device. They include log files, SQL file, SD cards and cookie stores.


Insecure communication


The process of data transmission in a mobile device is possible through a telecom carrier or via the internet. Hackers intercept the data as an adversary in a local area network or it can be through a compromised Wi-Fi network where they tap on to the proxy servers, cellular servers and through malware have an impact on the app.


Among all of them when you monitor traffic through compromised or secured WI- FI is one of the better ways for an adversary to stock information.


Authentication in an insecure way


Such a situation is bound to arise when a mobile device is not able to judge a user correctly and an adversary logs on to the app with the default credentials. This situation occurs when an attacker bypasses the authentication protocols or even their implementation could be poor. It is going to establish in a direct way with the server that uses malware that is in the middle of the botnet or mobile device.


Insufficient cryptography


There are data in mobile apps that become vulnerable to the process of encryption or decryption. The hackers are in a position to gain access to a mobile device or malicious apps with the aid of encrypted data.   Eventually, it paves way for the encryption process where you detect data in its original form by the use of an adverse process. In the end, it is not going to serve any purpose for the real user.


Insecure authorization         


Some people end up confusion about an M4 to an M6 risk as both of them point to user details. Developers have to be aware that the process of insecure authorization means when the adversary is going to cash in on the grey areas and logs as a form of a legitimate user. Here the adversary tries to bypass the process of authentication and tries to log in the form of a genuine user.


Code quality is of poor standards


This risk emerges from poor practices of coding, where every member of the coding team is following a variant code practice and loopholes in the final code are going to emerge. Even it is not going to create a lot of documentation for the others to comply. A saving grace for the developer is even if the risk emerges to be common the chances of detecting it are on the lower side.


Code tampering


Hackers stick to code tampering and no other form of manipulations as you gain unauthorized access to the app. The moment you are able to make a user download a tampered app, whose binary code has gone on to change. These apps allow hackers to alter the system APIs as they tend to take part in binary patching.


Sometimes you tend to come across additional features in a tampered app that is not going to exist in a normal app.


Reverse engineering


Once again this is a popular exploitable occurrence. A hacker tends to rely on external popular binary exception codes to figure out the original code of the app and study its link with a variety of processes. Even it can be put to use by the competitors of the app and they could even end up copying a set of features. In this manner, there is no need to even develop a new code. Even a hacker might use this method to gain prominent features of an app.


Extraneous functionality


In most of the cases, you do not gain any benefit with a benign code as the development team is known to keep the code so as to have access to the backend server. In fact, this code is central to the functioning of an app.


The developer also needs to take stock of the fact that automated tools cannot detect this risk type.



Previous Post
Next Post