OWASP 2016 checklist in mobile apps
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.
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:
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
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