OWASP 2016 checklist in mobile apps

OWASP 2016 checklist in mobile apps

Reading Time: 8 minutes




Security have become an important part of everyone’s life. And, when we talk about online security, everything have changed a little bit since Snowden leaked all the information and documents about the fact that we have been being observed for the USA government and the NSA. Now, the people are worry a little bit more about their privacy, but what hasn’t changed a lot is the worry of the people about their security online.

People don’t want to be worried about security. Should be the companies and developers who must have always an eye in give the best in security to the user.

With the purpose to serve as a reminder to companies, has been created the OWASP project. To help companies and developers to don’t forget some aspects of the online security.

What is OWASP?

OWASP (Open Web Application Security Project) is an online community which creates freely-available articles, methodologies, documentation, tools, and technologies in the field of applications (web and on devices) security. It was started in 2001 by Mark Curphey. It works under the OWASP Foundation, a non-profit organization in USA and Belgium that supports the OWASP infrastructure and projects.

Its website is a wiki style site where everyone can find documentation and methodologies about security in digital environments.

The OWASP project make every year a list with the top ten of the most critical web application (and mobile apps) security risks. This list is always accompanied by another list that serve as a checklist of some common vulnerabilities in those environments.

In words of the OWASP project:

“The OWASP Top Ten is a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.”

They have already release the checklist of 2016 with this vulnerabilities in mobile applications. Let’s take a look at the more common vulnerabilities in each client and server side:

Top vulnerabilities in client side


In the first position of the list we have that an application is vulnerable to reverse engineering attack / Lack of code. This is common in all the platforms. The problem with this is that, a possible attacker could take our app, make some reverse engineering and introduce some malware. Then, upload it to a website and someone who wants the app for free or with better features can download it and, pum, infected. That is one of the worst examples of what can someone do with the file of your app. But, how can we avoid this? Here comes the bad news, there is no way to avoid this, be there is several different ways in each platform to make it difficult to the attackers, but the reality is that there is no way to avoid it completely.


In the second position we can find that an account doesn’t implement a lockout, and again, it happens in all the platforms. The big problem here is that, if as developers we don’t create any kind of block or security alert that jumps after some retries with the password, the app can suffer a brute-force attack. With this, an attacker could make some kind of script to check every possible combination until find the right password.

The most obvious way to block brute-force attacks is to simply lock out accounts after a defined number of incorrect password attempts. The account lockouts can have a specific duration, such as one hour, or the accounts could remain locked until manually unlocked by an administrator. However, account lockout is not always the best solution, because someone could easily abuse the security measure and lock hundreds of user accounts.


With the bronze medal we see that most of the app out there, in all the platforms, are vulnerable to XSS attacks. The XSS (cross-site script) vulnerability is typically found on websites, enabling attackers to inject client-side scripts with languages like javascript, into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. But there is another possibilities for the attackers. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner. And Smartphones, as mini computers allowed to visit websites, are not exempt from this vulnerability. To avoid this kind of attacks, the OWASP has some documentation to help the developers with this issue.


In the fourth position we find a problem that all platforms could suffer. Authentication bypass. Yes, as ugly as it sounds. I really want to think that this doesn’t happen frequently in mobile apps, but it is in the fourth position of the OWASP checklist, so I don’t know what to think. If it’s possible to just go through the authentication and use the app without the need of be a user, this is an important security breach. The solution to this problem is to have a clear authentication scheme, well tested and without breaches. And forget to publish a production version of this code with a hardcoded trick to log in without use the server to check the user.


In fifth position we find something that sadly is more common than people might think. Because, who hasn’t ever coded sensitive information in the application’s code?

Yes, in Android, for example, it’s possible to obfuscate the code to make it difficult to read for third parties. Then, if someone make some reverse engineering to see the app’s file code (something that, in fact, is really easy) won’t see the code in clear text. I named Android, but the problem with hard coded sensitive information in the code is something that affect to all the platforms. So, please, don’t do that.

A clear example is when a developer writes in the code a password needed to, for example, encrypt some data. But also when this sensitive information is written in a file inside the app, or in a file in an external service, like Dropbox, and the link is in the app’s code.

To avoid this there is some approaches that can work depending of the case.

-Designing for default accounts: Rather than hard code a default username and password for first logins, utilize a “first login” mode which requires the user to enter a unique strong password.

-Designing for front-end to back-end connections we have three possible solutions:

-Use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time interval.

-The passwords used should be limited at the back-end to only performing actions valid to for the front end, as opposed to having full access.

-The messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.

Top vulnerabilities in server side


At the first position of the most common errors in server side we find, …cleartext password in response? Seriously? Is this the number one of the checklist? Who in his right mind would do that?

Save and use internally the password of the user as clear text is something dangerous and totally not recommended. Once we have the password we should encrypt it as soon as possible and “play” with the encrypted version. There is some tools that make this task easier in every language. Just take a look in Google and you will discover the perfect one.

It’s also not recommended implement your own solutions. There are tools that will make it better.


The second position is for a serious error that could lead to the leaking of a lot of information. This can happen when we leave a direct reference to internal resource without authentication.


The third position of this list want to remember us that is an important error when an application has NO (or improper) Session Management/Failure to Invalid. With a proper implementation of sessions manager we can avoid many problems with information leaking, data stealing or authentication. OWASP’s website offer some information about session management implementation (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Management_Implementation)


With the cross site scripting vulnerability we arrive in the fourth position in this list. As we saw in the client side part, the Cross-site Scripting, or XSS, refers to an attack made in client-side by code injection. Without the proper protection an attacker can execute malicious scripts into a legitimate website. This is one of the most common web application vulnerabilities. It happens when a web makes use of unvalidated or unencoded user input within the output it generates.


In the fifth position we find the Cross Origin Resource Sharing, or CROS. This is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the resource originated.

Complete list of vulnerabilities

Here is the complete list of vulnerabilities in both environments:

Client side:

1 Application is Vulnerable to Reverse Engineering Attack/Lack of Code

2 Account Lockout not Implemented

3 Application is Vulnerable to XSS

4 Authentication bypassed

5 Hard coded sensitive information in Application Code

6 Malicious File Upload

7 Session Fixation

8 Application does not Verify MSISDN WAP

9 Privilege Escalation

10 SQL Injection

11 Attacker can bypass Second Level Authentication

12 Application is vulnerable to LDAP Injection

13 Application is vulnerable to OS Command Injection

14 iOS snapshot/backgrounding Vulnerability iOS

15 Debug is set to TRUE Android

16 Application makes use of Weak Cryptography

17 Cleartext information under SSL Tunnel

18 Client Side Validation can be bypassed

19 Invalid SSL Certificate

20 Sensitive Information is sent as Clear Text over network/Lack of Data

21 CAPTCHA is not implemented on Public Pages/Login Pages

22 Improper or NO implementation of Change Password Page

23 Application does not have Logout Functionality

24 Sensitive information in Application Log Files

25 Sensitive information sent as a querystring parameter

26 URL Modification

27 Sensitive information in Memory Dump

28 Weak Password Policy

29 Autocomplete is not set to OFF

30 Application is accessible on Rooted or Jail Broken Device

31 Back-and-Refresh attack

32 Directory Browsing

33 Usage of Persistent Cookies

34 Open URL Redirects are possible

35 Improper exception Handling: In code

36 Insecure Application Permissions

37 Application build contains Obsolete Files

38 Certificate Chain is not Validated

39 Last Login information is not displayed

40 Private IP Disclosure

41 UI Impersonation through RMS file modification

42 UI Impersonation through JAR file modification Android

43 Operation on a resource after expiration or release

44 No Certificate Pinning

45 Cached Cookies or information not cleaned after application removal/

46 ASLR Not Used iOS

47 Clipboard is not disabled

48 Cache smashing protection is not enabled iOS

49 Android Backup Vulnerability Android

50 Unencrypted Credentials in Databases (sqlite db)

51 Store sensitive information outside App Sandbox (on SDCard)

52 Allow Global File Permission on App Data Android

53 Store Encryption Key Locally/Store Sensitive Data in ClearText

54 Bypass Certificate Pinning

55 Third-party Data Transit on Unencrypted Channel

56 Failure to Implement Trusted Issuers Android

57 Allow All Hostname Verifier Android

58 Ignore SSL Certificate Error

59 Weak Custom Hostname Verifier Android

60 App/Web Caches Sensitive Data Leak

61 Leaking Content Provider Android

62 Redundancy Permission Granted Android

63 Use Spoof-able Values for Authenticating User (IMEI, UDID)

64 Use of Insecure and/or Deprecated Algorithms

65 Local File Inclusion (might be through XSS Vulnerability)

66 Activity Hijacking Android

67 Service Hijacking Android

68 Broadcast Thief Android

69 Malicious Broadcast Injection Android

70 Malicious Activity/Service Launch Android

71 Using Device Identifier as Session

72 Symbols Remnant iOS

73 Lack of Check-sum Controls/Altered Detection Android

74 Insecure permissions on Unix domain sockets Android

75 Insecure use of network sockets Android

Server side:

76 Cleartext password in Response

77 Direct Reference to internal resource without authentication

78 Application has NO or improper Session Management/Failure to Invali

79 Cross Domain Scripting Vulnerability

80 Cross Origin Resource Sharing

81 Improper Input Validation — Server Side

82 Detailed Error page shows internal sensitive information

83 Application allows HTTP Methods besides GET and POST

84 Cross Site Request Forgery (CSRF)/SSRF

85 Cacheable HTTPS Responses

86 Path Attribute not set on a Cookie

87 HttpOnly Attribute not set for a cookie

88 Secure Attribute not set for a cookie

89 Application is Vulnerable to Clickjacking/Tapjacking attack

90 Server/OS fingerprinting is possible

91 Lack of Adequate Timeout Protection

Link: https://drive.google.com/file/d/0BxOPagp1jPHWYmg3Y3BfLVhMcmc/view

Source: https://www.owasp.org/index.php/OWASP_Mobile_Security_Project