IEEE SYMPOSIUM ON SECURITY AND PRIVACY
How Internet Resources Might Be Helping
You Develop Faster but Less Securely
, , and | CISPA, Saarland University Doowon Kim and . Mazurek | University of Maryland
Copyright By PowCoder代写 加微信 powcoder
Christian Stransky | CISPA, Saarland University
In an experiment, Android developers using Stack Overflow to solve common security issues produced functional—but less secure—code. Given today’s time constraints and economic pressures, developers need improved official documentation that’s both secure and usable.
Mobile devices in general and Android in par- ticular are a growing market, rapidly surpassing desktops and attracting many sometimes-new develop-
ers. Security and privacy problems in mobile apps are well-documented; they are sometimes attributed to developers who are inexperienced, distracted, or over- whelmed.1–6 For example, developers often request more permissions than are actually needed, fail to correctly use secure networking or cryptographic APIs, use insecure options for intercomponent communications (ICCs), and fail to store sensitive information in private areas.
Researchers and practitioners have speculated that one root cause for these programming errors is APIs that are too complicated or insufficiently documented, sending developers to a search engine for help to solve unfamiliar problems. These searches often lead to offi- cial API documentation, blog posts, or Q&A forums such as Stack Overflow; the security quality of content available at these resources can vary widely. Author Sas- cha Fahl and his colleagues, for example, interviewed Android developers whose use of pasted code snippets from Stack Overflow made their code vulnerable to man-in-the-middle (MITM) attacks.3
Such anecdotes set the stage for our work. Thus far, we know very little about how these security issues make their way into apps, and most of what we know remains unsubstantiated. In this article, we explore the following anecdotes’ validity:
■ Which information sources do Android developers use to answer security- and privacy-relevant questions? ■ Does the use of Stack Overflow really lead to less
secure code than the use of other resources?
■ Is the official Android documentation really less usable, resulting in less functional code compared to
other resources?
A Brief History of Android Insecurity
Researchers have identified several classes of common Android vulnerabilities. Perhaps the most prominent are problems with validating security certificates, which are used to establish identity at the start of secure com- munications. The certificate ecosystem runs on the TLS network protocol. Here’s how it works. Organizations that run webservers apply for certificates from a recog- nized certificate authority; these are cryptographically
50 March/April 2017 Copublished by the IEEE Computer and Reliability Societies 1540-7993/17/$33.00 © 2017 IEEE
signed assurances that associate a domain name with a specific public key. When a browser or a mobile app vis- its that webserver, the server presents its certificate. The client must then verify that the certificate isn’t expired and matches the expected domain name, and that the server can cryptographically demonstrate knowledge of the private key (secret) associated with the public key named in the certificate. This protocol protects the client from MITM attacks, in which the client is maliciously redirected to an attacker-controlled machine rather than to the server it intended to visit. Without TLS and cer- tificate validation, users can’t be assured of secure and authentic communications with banks, webmail ser- vices, social networks, and other critical services.
Several researchers have established that TLS and cer- tificate validation are broken in many deployed Android apps.3,5 The most common problem is that apps accept certificates without properly validating them. This could allow an MITM attacker to present a fake certificate and steal data. Other related problems with secure data trans- mission, including poor or absent cryptography, have also been identified in many deployed apps.2–6
Other researchers have identified problems that allow apps to access too much information on a user’s device. and her colleagues identified several deployed apps in which critical messages could be intercepted by unintended recipients, leaking private data.1 They also identified apps in which services would accept com- mands from unauthorized senders, enabling unexpected startup or shutdown of services, displaying spoofed data to the user, and causing other potentially serious prob- lems. These problems represent a failure to secure ICC.
Another well-known Android problem is that devel- opers often request more special permissions than they need. These permissions, which guard private data as well as paid activities (such as texting or calling), are rarely considered by users, so there’s little incentive for developers to choose them carefully. In fact, Adrienne Porter Felt and her colleagues found that a third of the apps they investigated overprovisioned, requesting more permissions than necessary for their operations.4 This represents a violation of the basic security prin- ciple of least privilege—requesting only as many privi- leges as absolutely needed to run a service.
Taken together, these well-documented flaws make it clear that even well-meaning app developers fre- quently make security- and privacy-relevant errors that put users at risk.
How Do Real Developers Approach Security Challenges?
To understand the challenges faced during the imple- mentation of security-critical app components, we con- ducted an online survey of Android developers that
covered their experience, their programming habits, and the resources they use.
We collected a random sample of 50,000 email addresses for Android application developers listed in Google Play. We emailed these developers, introducing ourselves and asking them to take our online survey. A total of 295 people completed the survey between April and October 2015.
We asked participants about three security-related issues they might encounter during app development: HTTPS/TLS, encryption, and Android permissions.
Approximately half of the developers (144) said that their Android apps use HTTPS to secure network con- nections; fewer participants (74, or 25.1 percent) had used encryption to store content securely. (We didn’t ask about Android permissions because all Android developers encounter them inherently.) In each case, at least 75 percent of the participants reported looking up information about these topics at least once. Most participants who looked up certificates or encryption reported solving these problems similarly to other pro- gramming problems. We find this particularly interest- ing because certificates and encryption are critical for securing connections and protecting private data, but developers don’t appear to treat them differently from less security-critical problems.
Figure 1 illustrates the resources participants reported using to look up information on these three topics, compared to the information resources they used for general programming problems. In all cases, search engines and Stack Overflow were popular, con- firming their status as the default resources for most problems. However, for Android permissions only, the official documentation was even more popular: 41 per- cent of those who had looked up the topic (91 partici- pants), compared to 30 percent (67 participants) for search engines and 29 percent (64 participants) for Stack Overflow. One participant wrote that “[I] don’t have to google. [I] go directly to Android developer resource” for authoritative information. Perhaps this is because permissions are Android specific and closely associated with the platform. These findings validate both the need to understand the resources’ impact on security and privacy decisions generally, and our choice to compare Stack Overflow and the official documenta- tion more specifically.
An Experiment to Compare Different Information Resources
Next, we used a between-subjects laboratory study to examine how information resources affect developers’ security and privacy decision making.
We recruited 54 participants who’d taken at least one course in Android development or had developed
www.computer.org/security
IEEE SYMPOSIUM ON SECURITY AND PRIVACY
What resources do you use?
General Encryption Permission HTTPS
0 25 50 75 100 % of participants
Official Android documentation Search engine
Stack Overflow
Figure 1. Resources that developers use to look up information on specific security-related issues during app development, versus more general programming problems. Search engines and Stack Overflow were confirmed as the go-to resources for most problems. For Android permissions, however, official documentation was most popular.
IEEE Security & Privacy
March/April 2017
professionally or as a hobby for at least one year; we also required participants to correctly answer at least three of five multiple choice questions testing basic Android development knowledge. Participants were recruited in and around Washington, DC, as well as in two univer- sity towns in Germany.
Participants were 18 to 40 years old; most were male (85 percent) and had grown up in Germany (52 percent), the US (11 percent), or India (9 percent). The majority were part- or full-time students (89 per- cent); eight participants were employed as Android app programmers.
The study was approved for ethical compliance by the University of Maryland Institutional Review Board. Participants were assigned round-robin to one of
four conditions:
■ official Android documentation: allowed to access only websites within the official Android documentation (developer.android.com),
■ Stack Overflow: allowed to access only questions and answers within Stack Overflow,
■ book: allowed to use only two books—Pro Android 47 and Android Security Internals,8 and
■ free choice: allowed to use any web resource of their choice; also offered access to the two books used in the book condition.
Participants were provided with Android Studio, preloaded with a skeleton app, and a software Android phone emulator. The skeleton app, which was designed to reduce participants’ workload and simplify the pro- gramming tasks, was introduced as a location-tracking tool that would help users track how much time they spent in various locations (at home, at work, and so on) each day.
After a brief introduction to the study and the skel- eton app, participants were given four programming tasks in random order (detailed in the next section), with 20 to 30 minutes to complete each. We took care to implement baseline functionality so that the tasks could be done in any order and the remaining tasks would still work even if a previous task hadn’t been successfully completed. While the short time limit impeded some participants’ performance, it also simulated the pres- sure of writing code on tight deadlines, which many app developers face.
Security and privacy weren’t mentioned during the introduction or in the directions for each task (the HTTPS task and user credential storage task do inher- ently imply some reference to security). We deliberately minimized security priming to account for the fact that security and privacy are generally secondary tasks com- pared to basic app functionality. Instead, we focused on whether developers—who in real-world scenarios might or might not be explicitly considering security— find and implement secure approaches. During the tasks, we collected the search terms used and pages vis- ited by all participants in the non-book conditions.
After completing all tasks (or running out of time), participants were given a short exit interview about their experience. We asked whether the documenta- tion and resources participants had access to were help- ful, correct, or both. We also asked whether and how participants had considered security or privacy during each task.
Tasks with Secure and Insecure Solutions
Drawing on related work, we selected four general areas that typically result in Android security or privacy errors: making mistakes in TLS and cryptographic API handling; storing sensitive user data insecurely, such
Table 1. Four Android development tasks designed to have secure and insecure solutions.
Description
Example of secure solution(s)
Example of insecure solution(s)
Secure networking
Convert an HTTP connection
to HTTPS in the presence of a certificate error. The connection was to locationtracker.org (created for this study), with a certificate for the nonexistent secure.locationtracker .org. This resulted in an exception indicating a mismatch between the certificate name and domain.
Create a custom hostname verifier for this specific case, pin the mismatched certificate, or insist that the app obtain a correct certificate.
Accept the certificate regardless of the mismatched domain, or without any validation at all.
Intercomponent communication (ICC)
Modify a service within the skeleton app to make the service callable
by other apps from the same developer.
Use a custom Android permission to require a matching developer signature; share one ID among all apps from the same developer.
Expose the service to any app by setting the export flag to true (the default for some ICC mechanisms).
Secure storage
Store the user’s login ID and password for the app’s remote server locally and persistently. The skeleton app contained empty store and load functions for the participant to fill in.
Limit access to only this app, for example, using the “private” mode for shared preferences.
Store the data as world readable in shared preferences or on the SD card.
Least privilege
Dial a hard-coded customer support telephone number by adding code to an existing but not yet functional call button.
Use the ACTION_DIAL mechanism, which requires no special permissions.
Use the ACTION_CALL mechanism, which requires an additional calling permission.
that it can be accessed by other (unauthorized) apps; using ICC in a way that violates least-privilege princi- ples; and requesting unneeded permissions.
We designed each task so that it could be function- ally completed in at least one secure and one insecure way. Table 1 describes all four tasks, with examples of each kind of solution. Before conducting the study, we verified that secure solutions for each task were avail- able in each of the documentation resources we used. This ensured that it was possible (if not necessarily easy) for participants in all conditions to locate a cor- rect and secure answer.
We manually scored each task for functionality: “true” if the code compiled and completed the assigned task, “false” if it didn’t. We then manually scored only functional tasks for security, by labeling each par- ticipant’s code with one of several solution strategies determined to be secure or insecure. Two independent coders performed scoring; conflicts were resolved by discussion to reach agreement.
We analyzed these binary functionality and secu- rity scores using a cumulative-link (logit) mixed model (CLMM) regression, which can account for multiple explanatory factors, including multiple tasks per partici- pant. We tested several models for each regression; as is standard, we selected the model with the lowest Akaike information criterion (AIC).
Stack Overflow Helps
Achieve Functional Code
In terms of functional correctness, participants allowed to use Stack Overflow or books performed best, with 67 and 66 percent achieving functional solutions, respec- tively. Participants restricted to the official documen- tation performed worst, solving 40 percent of tasks. The difference between Stack Overflow and the official Android documentation was statistically significant in our CLMM model (p = 0.015). These results are shown in Figure 2.
Participants’ perceptions of the tasks only partially dovetailed with these results. We asked participants whether they were confident they’d gotten the right answer for each task. Results are shown in Figure 3. Participants in the free-choice condition were the most confident. This confidence rating somewhat matched our correctness rating (Cohen’s kappa = 0.55).
But Stack Overflow Is Worse for Security
We found that the type of resource used had the oppo- site effect on security than functionality: participants restricted to Stack Overflow were the least likely to achieve secure solutions. In the Stack Overflow condi- tion, only 51.4 percent (18 of 35) of functional solu- tions were graded as secure, compared to 65.5 percent (19 of 29) for free choice, 73.0 percent (27 of 37) for
www.computer.org/security
IEEE SYMPOSIUM ON SECURITY AND PRIVACY
Correctness
Secure networking
Intercomponent communication (ICC )
Secure storage Least permissions
Stack Overflow Book
0 25 50 75 100 % of participants
Figure 2. Percentage of participants who produced functionally correct solutions, by task and condition. Participants who used Stack Overflow or books performed best, while those restricted to official documentation performed worst.
IEEE Security & Privacy
March/April 2017
book, and 85.7 percent (18 of 21) for official documen- tation. Figure 4 illustrates these results. Significantly more results in the official-documentation and book conditions were secure than in the Stack Overflow condition according our CLMM (p = 0.005 and 0.01, respectively). The difference between Stack Overflow and free choice, in which many participants elected to use Stack Overflow for most tasks, wasn’t statistically significant (p = 0.07).
We were also interested in the extent to which partici- pants thought about security while solving each task. We measured this in two ways: whether the participant men- tioned security while thinking aloud (as directed) dur- ing the task, and whether the participant self-reported considering security for a given task during the exit interview. For both metrics, we considered all tasks, not just those that the participants functionally completed.
Most participants didn’t mention security at all while thinking aloud (79 percent of all tasks). In the secure-storage task, 16 participants (30 percent) men- tioned security. Of these, all seven solutions that were functional were also secure. In the secure-networking task, 20 (37 percent) mentioned security, but nine later abandoned the task as too difficult or time con- suming for a study. In contrast, only five and four par- ticipants, respectively, mentioned security or privacy in the least-privilege and ICC tasks. Unsurprisingly, when prompted, more participants self-reported consider- ing security: 60 percent of all tasks (130 tasks). Using this metric, security was most frequently considered for secure networking (80 percent), followed by ICC (70 percent) and secure storage (69 percent). Only 22 per- cent of participants reported considering security for the least-privilege task. We found no significant difference between conditions for either metric (Kruskal-Wallis, observed p = 0.92, self-report p = 0.19).
Professionals Are More Functional but Not More Secure than Students
Although the relatively small sample of professionals recruited makes comprehensive comparisons difficult, we examined differences in correctness and security between the professionals (14 participants employed or recently employed as programmers) and nonprofes- sionals (primarily university students). The profession- als were randomly distributed across the conditions: five in free choice
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com