Security Auditing and Testing of two Android Client-Server Applications

How secure is your application? How can you evaluate if it is secure? The threats are many and may be hard to find. In a world where things are more and more automated; how does manual labour contribute to security auditing applications? This study aims to assess two proof of concept Android client-server applications, developed by students to suit the needs of a fictitious Police Department and Fire Department, respectively. The approach is unconventional yet supported by well-established theory. The gist of a vulnerability assessment methodology initially developed to assess the security of middleware is followed and applied to the entire architecture of these client-server applications. How the manual labour contributed to the end results, in comparison to the use of automated tools and a list of known threats, is then evaluated. It is concluded that the applications encompass multiple of the Open Web Application Security Project (OWASP) Top 10 Mobile Risks and that automated tools find most of those vulnerabilities. However, relying on automation may lead to a false sense of security, which in effect may cause developers to lose understanding of why vulnerabilities occur and how they should be mitigated. Understanding how the design and architecture of the application influence its security is key. As of Android 9.0+, default is that applications use SSL encrypted communication. Only 40% of Android users are in 2020 affected by this change according to Android studio developer information, leaving a majority of users unaware of if or how their data is being protected, also observed in analysis results from this thesis work. One should consider if or how to inform users of how their data is being handled, not only in newer Android versions or regarding SSL communication. This work also shows that developers' decisions may be greatly affected by time pressed situations, which is reflected upon in the last chapter. Another important finding was that the third-party software Sinch, which enabled the use of voice and video communication in one of the applications, sent IP addresses and usernames of the users in clear text during the binding request, when the Session Traversal Utilities for NAT (STUN) protocol was used