A Security Analysis of Autofill on Ios and Android
Total Page：16
File Type：pdf, Size：1020Kb
The Emperor’s New Autofill Framework: A Security Analysis of Autofill on iOS and Android Sean Oesch, Anuj Gautam, Scott Ruoti The University of Tennessee [email protected], [email protected], [email protected] Abstract—Password managers help users more effectively (P3) the filled credential will only be accessible to the manage their passwords, encouraging them to adopt stronger mapped app or web domain. [23]. passwords across their many accounts. In contrast to desktop On desktop environments, password managers are primarily systems where password managers receive no system-level support, mobile operating systems provide autofill frameworks implemented as ad-hoc browser extensions—i.e., the extension that are designed to integrate with password managers to individually implements all aspects of the autofill process provide secure and usable autofill for browsers and other apps without support from OS or browser autofill frameworks. installed on mobile devices. In this paper, we conduct the first While some desktop password managers correctly achieve P1 holistic security evaluation of such frameworks on iOS and and P2 [19], many have incorrect implementations that allow Android, examining whether they achieve substantive benefits over the ad-hoc desktop environment or become a problematic attackers to steal or phish users’ credentials [14], [22], [23], single point of failure. Our results find that while the [19], and none can fully implement P3 due to technical frameworks address several common issues (e.g., requiring user limitations of browser extension APIs [23], [19]. interaction before autofill), they also enforce insecure behavior In contrast to the situation on desktop, mobile operating and fail to provide the password managers implemented using systems provide system-wide autofill frameworks that attempt the frameworks with sufficient information to override this incorrect behavior. Within mobile browsers, this results in to standardize and secure the autofill process. Critically, these managers being less secure than their desktop counterparts. frameworks have the potential to enforce correct handling of Within apps, incorrect handling of WebView controls leads to P1–P3 for all mobile password managers. Additionally, these manager-assisted phishing attacks from malicious apps or frameworks provide support for autofill within apps, which is domains, depending on how autofill is implemented. Based on largely unavailable on desktop. our results, significant improvements are needed for mobile autofill frameworks and we conclude the paper with concrete In this paper, we conduct the first evaluation of the mobile recommendations for the design and implementation of more autofill frameworks, examining whether they achieve secure autofill frameworks. substantive benefits over the ad-hoc desktop environment or Index Terms—password managers; iOS; Android; mobile; instead become a problematic single point of failure. In this authentication; security; evaluation evaluation, we consider all such frameworks: iOS’s app extensions, iOS’s Password AutoFill, and Android’s autofill I. INTRODUCTION service. Positively, our evaluation finds that all frameworks correctly require user interaction before autofilling credentials The cognitive burden of remembering many strong, unique (P1), a marked improvement over the mixed support on passwords leads users to create easily guessed passwords [6], desktop. In contrast, we find that framework support for P2 [21] and to reuse passwords [5], [26], [20], [10]. These insecure and P3 is severely limited. behaviors make targeted attacks easier and lead to large scale Within browsers, we find that the frameworks do not account compromise when data breaches occur. While other properly validate the authenticity of the webpage nor ensure arXiv:2104.10017v1 [cs.CR] 20 Apr 2021 authentication schemes have been proposed, passwords remain that filled credentials will be sent to the appropriate domain dominant [4], [3]. upon form submission. The frameworks also provides very Password managers offer a pathway to help users more limited information about the webpage to the password effectively manage their passwords, assisting users to create managers, preventing the managers from making appropriate strong passwords, store those passwords, and finally fill those security checks themselves. Overall, this leads to mobile passwords into login forms (i.e., password autofill), password managers being less secure than their desktop significantly reducing the cognitive burden of using strong, counterparts. unique passwords [29], [16]. On the other hand, if Within apps, autofill behavior differs based on the type of implemented incorrectly, password managers can become a interface being filled: (1) native UI elements, (2) WebView single point of failure, putting all a user’s credentials at controls, and (3) custom-drawn UI elements, of which the risk [19]. In regard to securing autofill, password managers first two are supported by mobile autofill frameworks. For must only fill credentials when: (P1) the user has explicitly native elements, we find that iOS Password AutoFill provides authorized the fill operation [14], [22], (P2) the credential is a strong and secure binding between credentials and apps, mapped to the web domain or app to be filled [1], [19], and achieving P2 and P3. In contrast, the Android autofill service provides no such binding, leaving the mapping of credentials is that this is easier to do than memorizing the tens or and apps to the individual password managers, with nearly hundreds of passwords they would otherwise need to. all such mappings being insecure (breaking P2). Even worse, 2) Due to this reduced cognitive burden, they make it possible iOS app extensions not only fail to provide a secure mapping for users to have unique passwords for every service they mechanism but also prevent managers from implementing their authenticate to, addressing the problem of password reuse. own mappings, allowing any credential to be autofilled into 3) They help users generate passwords, avoiding weak any app. passwords that would be vulnerable to online and offline For WebView controls, credentials should only be autofilled guessing attacks. if they match the domain of the webpage within the WebView 4) They audit user credentials, helping users identify and control, regardless of which credentials are mapped to the app. replace reused or weak passwords, as well as notifying Such behavior is enforced by iOS Password Autofill users of password breaches that involve the user’s (achieving P2), whereas both iOS app extensions and the credentials. Android autofill service leave the mapping decision to the On desktop environments, password managers are individual password managers, with only some managers implemented as ad-hoc browser extensions (i.e., the browser implementing the mapping correctly. Managers that do not provides no first-party APIs supporting password properly implement this mapping instead autofill the app’s management). In contrast, on mobile there are first-party mapped credentials into the webpage, allowing malicious or frameworks that assist managers conduct the autofill process. compromised webpages displayed in benign apps to phish the This first-party support allows for autofill both within app’s mapped credential (breaking P3). Even in the browsers (see §IV) and within apps, something largely not frameworks and managers that do enforce a secure mapping, possible with desktop managers. we identify a limitation in the design of WebView controls on For apps, there are three types of interfaces where autofill Android and iOS that allows a malicious app to host benign would be applicable: (1) native UI elements (i.e., OS-provided webpages within a (potentially invisible) WebView and steal widgets), (2) using custom UI elements drawn and managed filled credentials, enabling the surreptitious phishing of all the by the app, and (3) within a webpage displayed in a WebView user’s credentials (also breaking P3). hosted by the app. The security of autofill for native UI elements Critically, in both phishing attacks, the password manager is discussed in §V, while the security of autofill in WebView acts as a confused deputy, displaying the autofill dialog and controls is discussed in VI. Custom rendered UI elements are suggesting that the user fills the credential being targeted by the not supported by the mobile autofill frameworks. attack. This is extremely problematic, as in all other contexts the autofill dialog is an indication that phishing is not occurring and A. Secure Autofill is designed to give users confidence in filling their credentials. Autofilling credentials is a multi-step process. First, the As such, users are unlikely to look carefully at the autofill password manager must detect the login form to be filled. dialog, increasing the probability that their credentials will be Second, it must identify the correct credentials to fill into the successfully stolen. login form. Third, the manager must ensure that filling the Overall, our results show that there are significant security credentials is safe. Finally, the manager will fill the appropriate issues with mobile autofill frameworks, limiting both the utility credentials. and usability (as users need to be ever vigilant) of mobile By examining past research [14], [22], [23], [1], [19], we password managers. This is especially problematic as these have synthesized three properties that need to be guaranteed tools are being promoted ever more frequently by the news by password managers in