PaperlayerView exact revision on arXiv

Source-linked AI summary

Stack Overflow Considered Harmful? The Impact of Copy&Paste on Android Application Security

Felix Fischer, Konstantin Böttinger, Huang Xiao, Christian Stransky, Yasemin Acar, Michael Backes, Sascha Fahl

arXiv:1710.03135v1cs.CR

TL;DR

The security impact of code snippets copied from Stack Overflow into Android applications is an important concern. The paper measures this flow using automated snippet analysis, security classification, and clone detection, finding widespread vulnerable-code reuse in Google Play applications.

  • Problem

    Android-related Stack Overflow discussions include security-related oddities such as excessive permissions and insecure X.509 certificate validation, motivating measurement of their impact on application security.

  • Method

    The paper extracts and filters security-related Stack Overflow snippets, classifies their security, represents them as program dependency graphs, and detects clones in Android applications.

  • Results

    More than 196k of 1.3 million Google Play applications contain vulnerable code copied from Stack Overflow, while 73k applications use a secure snippet.

  • Takeaways & Limitations

    The proliferation of insecure Stack Overflow snippets within the Android ecosystem poses a major and dangerous problem for Android application security.

  • Takeaways & Limitations

    Snippet security labeling may be incorrect, and missing input values can cause the prevalence of insecure APIs to be under- or overreported.

Abstract

from arXiv · show

Online programming discussion platforms such as Stack Overflow serve as a rich source of information for software developers. Available information include vibrant discussions and oftentimes ready-to-use code snippets. Anecdotes report that software developers copy and paste code snippets from those information sources for convenience reasons. Such behavior results in a constant flow of community-provided code snippets into production software. To date, the impact of this behaviour on code security is unknown. We answer this highly important question by quantifying the proliferation of security-related code snippets from Stack Overflow in Android applications available on Google Play. Access to the rich source of information available on Stack Overflow including ready-to-use code snippets provides huge benefits for software developers. However, when it comes to code security there are some caveats to bear in mind: Due to the complex nature of code security, it is very difficult to provide ready-to-use and secure solutions for every problem. Hence, integrating a security-related code snippet from Stack Overflow into production software requires caution and expertise. Unsurprisingly, we observed insecure code snippets being copied into Android applications millions of users install from Google Play every day. To quantitatively evaluate the extent of this observation, we scanned Stack Overflow for code snippets and evaluated their security score using a stochastic gradient descent classifier. In order to identify code reuse in Android applications, we applied state-of-the-art static analysis. Our results are alarming: 15.4% of the 1.3 million Android applications we analyzed, contained security-related code snippets from Stack Overflow. Out of these 97.9% contain at least one insecure code snippet.

I. INTRODUCTION

The paper measures how security-related Stack Overflow snippets flow into Android applications through an automated extraction, classification, and clone-detection pipeline. It finds widespread reuse, with insecure snippets dominating the applications containing such code.

  • The paper frames copied insecure snippets as a lifecycle from community provision through production deployment to possible exploitation.
  • The study measured 1,161 insecure Stack Overflow snippets copied into 1,305,820 Android applications available on Google Play.
  • 15.4% of 1.3 million Android applications contained security-related Stack Overflow snippets, and 97.9% of those applications contained at least one insecure snippet.
  • The analysis was designed to scale beyond Stack Overflow and Google Play, although supervised classification required one-time manual labeling of a small training fraction.
  • The automated pipeline crawled Stack Overflow, filtered security-related snippets, classified them, generated program dependency graphs, and detected clones in Google Play applications.
  • Security-related snippets were identified through calls to Java and Android security libraries covering cryptography, network communication, PKI, authentication, and access control.

B. Finding Security-related Code Snippets on Stack Overflow

The study identifies security-related Stack Overflow snippets by extracting code and resolving ambiguous Java elements against a defined security-API set. Filtering removes obvious non-security matches but can still misclassify context-dependent snippets.

  • JavaBaker used a user-defined API set and constraint-based disambiguation to infer fully qualified names from incomplete snippets.
  • Code snippets were filtered as security-related when an oracle linked their elements to defined security APIs.
  • A manually compiled blacklist excluded packages whose use did not indicate security code.
  • Sparsely used elements could produce false positives, so snippets reporting only constructors or no methods were filtered out.
  • API-based filtering could label non-security uses as security-related when the same security API served another context, such as data-management hashing.

IV. CODE LABELING

The paper labels snippets secure or insecure using reviewer-defined rules grounded in cryptographic and communication best practices. The rules account for algorithm strength, parameters, usage context, and exploitability.

  • Two reviewers manually inspected 1,360 extracted snippets, with a third reviewer resolving conflicts.
  • Snippets were categorized as SSL/TLS, symmetric cryptography, asymmetric cryptography, one-way hashing, or secure random-number generation.
  • Secure labels covered strong algorithms, sufficiently large RSA or elliptic-curve keys, and secure random-number generation.
  • Insecure labels were reserved for obviously vulnerable code, including outdated algorithms, static keys or IVs, weak RSA keys, insecure randomness, and insecure TLS.
  • The security metric was designed around parameters actually used in the corpus rather than as an exhaustive metric for every security category.
  • Some practices were context-dependent: CBC encryption was secure outside client/server settings, while RSA PKCS1 padding was vulnerable only in client/server scenarios.

3) Asymmetric Cryptography:

The paper evaluates asymmetric cryptography snippets by considering RSA padding and key length, with security judgments conditioned on whether code runs in a client/server scenario.

  • 3) Asymmetric Cryptography:: RSA security is evaluated using padding and key length rather than the transformation string’s nominal block mode.The underlying provider ignores RSA block modes such as RSA/ECB, so they have no security implication.
  • 3) Asymmetric Cryptography:: PKCS1 padding is treated differently depending on the execution scenario.It is vulnerable to padding-oracle attacks in client/server settings but considered secure in non-client/server settings.
  • 3) Asymmetric Cryptography:: Security labels may be over- or underreported because snippet security depends on input values that are often absent.Multiple reviewers and accepted best practices reduce but cannot eliminate incorrect labeling.
  • 3) Asymmetric Cryptography:: The classifier learns from manually labeled secure and insecure snippets represented through code-token features.The binary model is applied to security-related snippets after training, and vocabulary-level features support scaling beyond manual processing.
  • 3) Asymmetric Cryptography:: SVM separates secure and insecure training samples by maximizing a margin while permitting limited violations through slack variables.The feature mapping can also handle nonlinear cases through the kernel trick.

B. Feature Extraction

The detection pipeline converts snippets and Android applications into a common representation, then compares program-dependency structures and selected semantic details to identify reused code.

  • B. Feature Extraction: tf-idf converts code snippets, treated as documents, into fixed-length numeric vectors based on token frequency and inverse document frequency.The resulting vocabulary contains parsed code tokens and their frequencies.
  • B. Feature Extraction: WALA2 provides a shared intermediate representation after Android applications are converted from DEX to JVM bytecode.The researchers modified WALA to incorporate PPA for processing incomplete Stack Overflow snippets.
  • B. Feature Extraction: Partial Program Analysis creates complete, typed abstract syntax trees from incomplete Java snippets.It resolves syntactic and typing ambiguities, using UNKNOWNP.UNKNOWN when types cannot be resolved.
  • B. Feature Extraction: Reuse detection compares similar Program Dependency Graphs through semantic blocks and vector-space embeddings.Embedding reduces graph-similarity search to vector comparison because PDG subgraph isomorphism is NP-hard.
  • B. Feature Extraction: The detector strengthens similarity checks with constants, security-library method names, and restrictions on class and method restructuring.It searches only classes containing security-related API calls to reduce computational overhead.
  • B. Feature Extraction: Jaccard similarity compares semantic vectors using counts of instruction nodes and maximum outgoing-edge degrees.The definition ensures comparisons are made between elements of the same instruction type.

C. Exotic Case

Empty TrustManager methods require special handling because their empty graphs and method sets cannot distinguish them through the general detection approach.

  • C. Exotic Case: Empty TrustManager implementations receive special treatment to avoid false positives.The detector checks checkClientTrusted, checkServerTrusted, and getAcceptedIssuers when empty methods appear in an application call graph.

VII. EVALUATION

The evaluation measures the prevalence and security of Android-related Stack Overflow snippets and examines how those snippets appear across cryptographic libraries and security topics.

  • VII. EVALUATION: 29,499,660 Stack Overflow posts formed the source dataset, including 818,572 Android-tagged question threads and 1,165,350 answers.The dataset was downloaded in March 2016; 68.4% of questions and 63.9% of answers contained code snippets.
  • VII. EVALUATION: 70.7% of snippets were related to java.security, especially cryptographic key initialization or storage and message digests.Key-related snippets accounted for 44.9%, while MessageDigest snippets accounted for 30.4%.
  • VII. EVALUATION: 31.9% of snippets contained Android cryptographic API code, and 84.6% of those used javax.crypto.Cipher.701 snippets used SecretKeySpec with user-chosen raw keys, compared with 207 using KeyGenerator.
  • VII. EVALUATION: 28.9% of snippets used javax.net.ssl, including custom TrustManagers in 46.7% of those snippets and custom hostname verifiers in 17.1%.The evaluation reports that custom trust managers basically ignore authentication despite potentially being intended to improve security.

1) Labeling of Training Set:

The study labels security-related Stack Overflow snippets using a supervised SVM approach and evaluates how well the classifier distinguishes insecure from secure code. In the training set, insecurity was concentrated in TLS/SSL, symmetric cryptography, and insecure random-number generation.

  • Labeling of Training Set:: The classifier used manually labeled snippets to train an SVM that treated code snippets as token-based binary document-classification instances.The training classes were insecure and secure code snippets.
  • TLS/SSL:: 277 of 431 TLS/SSL snippets (20.23% of the training set) were classified as insecure, commonly because certificate validation was disabled.The observed causes included default hostname verification and custom TrustManagers with empty validation methods.
  • Symmetric Cryptography:: 159 of 189 symmetric-cryptography snippets (11.61% of the training set) were classified as insecure, including snippets using AES with ECB as the default mode.Other examples used zero-valued or hard-coded keys and initialization vectors.
  • Random Number Generation:: 29 of 30 random-number-generation snippets (2.11% of the training set) were classified as insecure because they explicitly seeded generators with static strings.The paper links this practice to low entropy when the seed is not supplemented.
  • Digital Signatures and Message Digests:: None of the 279 digital-signature-related snippets (20.37% of the training set) were classified as insecure.The authors attribute this to snippets mostly extracting existing signatures rather than validating or generating them.
  • Model Evaluation of SVM Code Classifier:: The learning-curve evaluation found mean precision and accuracy approximately above 0.8, while recall approached 0.75 after more than 1,000 training samples.The model used tf-idf features; the authors note that richer feature engineering and more training data could improve it further.

3) Large Scale Classification:

The authors applied the trained classifier and static-analysis toolchain to Android applications, finding widespread reuse of security-related Stack Overflow snippets. Insecure copied code was especially prevalent in TLS handling and symmetric cryptography.

  • Large Scale Classification:: 1,161 of 3,834 distinct security-related Stack Overflow snippets (30.28%) were classified as insecure.The remaining 2,673 snippets (69.72%) were classified as secure.
  • Large Scale Classification:: 1,305,820 free Android applications from Google Play were analyzed, with updated versions downloaded through May 2016.The corpus was used to measure copied snippets in applications.
  • Apps with copied and pasted code snippets:: 200,672 apps (15.4%) contained copied Stack Overflow snippets, and 196,403 apps (15%) contained at least one insecure snippet.Question snippets appeared in 198,347 apps, while answer snippets appeared in 40,786 apps.
  • Apps with copied and pasted code snippets:: 506,922 apps (38.82%) contained a secure snippet, but secure snippets appeared on average in more apps than insecure snippets.The reported averages were 10,719.83 apps per secure snippet versus 4,539.96 apps per insecure snippet.
  • SSL/TLS:: 183,268 apps (14.03%) contained insecure TLS-handling snippets, including code using an insecure custom TrustManager.The paper states that missing server verification enables man-in-the-middle attacks.
  • Symmetric Cryptography:: 21,239 apps (1.62%) contained insecure symmetric-cryptography snippets, with AES in ECB mode appearing in 18,000 apps.The paper identifies chosen-plaintext vulnerability and possible key leakage from hard-coded cryptographic keys.

4) Asymmetric Cryptography:

The application-level analysis found category-specific differences in the spread of copied snippets, with insecure random-number generation more common than insecure asymmetric-cryptography, hashing, or signature snippets. The study also examined app categories and community feedback around reused code.

  • Asymmetric Cryptography:: 114 apps (0.01%) contained an insecure asymmetric-cryptography snippet, while 698 apps (0.05%) contained a secure one.All 114 insecure instances came from question snippets.
  • Random Number Generation:: 8,228 apps (0.63%) contained an insecure random-number-generation snippet, compared with 4,100 apps (0.31%) containing a secure snippet.Most insecure instances in this category came from question snippets.
  • Digital Signatures:: No insecure signature-related snippet was found in apps, whereas 15 apps contained a secure signature-related snippet.All secure signature snippets were found in Stack Overflow questions.
  • Apps with copied and pasted code snippets:: Considering security-related snippets only, 196,403 apps contained an insecure snippet versus 73,839 containing a secure one.The broader secure count included 498,046 apps with snippets classified as not security-related.
  • Sensitive Applications:: Business, shopping, and finance apps had the largest numbers of sensitive apps using insecure copied snippets: 14,944, 4,707, and 4,243 respectively.The authors describe the finance-app result as surprising given access to bank-account information.

1) Scoring:

Community feedback does not reliably reflect the security of snippets or discourage insecure code from being copied. Higher scores and view counts correlate with more copying, while warnings can coincide with increased reuse.

  • Scoring: Secure question snippets receive higher scores than insecure ones, contradicting the expected security-oriented scoring pattern.The authors conclude that question scoring is not adequate for evaluating security.
  • Scoring: Insecure answers with security warnings receive significantly higher scores than insecure answers without warnings.The influence of warnings on answer scores is therefore described as highly questionable.
  • Scoring: The deployed feedback system is insufficient for reliable and precise security estimation.This conclusion considers security aspects alone.
  • Impact on copy and paste: Higher score or view count corresponds to an increased copy-and-paste count for insecure snippets.The analysis compares metadata with detected copy rates across top and bottom detection-rate tiers.
  • Impact on copy and paste: Warnings correlate with more copying: the top offending snippet was copied 180,388 times despite security warnings.The authors report that warned snippets were copied more often than unwarned snippets.
  • Limitations: The processing pipeline does not fully prove that copied snippets originate from Stack Overflow.The authors nevertheless consider Stack Overflow origin very likely because of platform popularity, developer reliance, and positive view-count correlation.

B. Developer Studies

The paper connects insecure Android code to developer security weaknesses and examines how community platforms and automated code-reuse analysis relate to application security. It proposes automated classification as an alternative to complicating post scores.

  • Developer Studies: Developers with limited security skills are identified as major contributors to security issues in applications.Reported causes include disabling TLS during testing, failing to re-enable it, and misunderstanding TLS guarantees and consequences.
  • Developer Studies: Stack Overflow and related platforms support code reviews, conceptual questions, and reciprocal knowledge flow with GitHub.Prior studies connect platform activity with development processes and contributions.
  • Developer Studies: Prior code-reuse studies detect duplicates using abstract syntax trees, bytecode k-grams, and control-flow-graph features.These approaches represent snippets and applications through structural or feature-based program representations.
  • Conclusion: Secure snippets also flow into real-world applications, including critical applications, alongside insecure snippets.The authors stress that secure code reuse benefits the Android ecosystem.
  • Countermeasures: The authors propose real-time browser-plugin classification to indicate security issues in snippets copied to the clipboard or viewed on discussion threads.The approach is presented as an alternative to expanding the post-scoring system with additional criteria.
  • Method: The paper presents a systematic automated pipeline combining security classification with program-dependency-graph matching for large-scale code-flow analysis.It is applied to crowd-sourced code and closed-source Android applications.
  • Results: More than 196k of 1.3 million Google Play applications contain vulnerable code copied from Stack Overflow.The platform choice is motivated by the popularity and market dominance of Stack Overflow and Google Play.
  • Conclusion: The conclusions concern Android ecosystem security and motivate future large-scale mining of developer discussions.The paper frames these conclusions as broad in scope but derived from the analyzed community discussions.

APPENDIX

The appendix presents examples of insecure security-related snippets, including permissive hostname verification, static cryptographic material, and deterministic random-number seeding.

  • Examples: An empty HostnameVerifier accepts all hostnames.The listing identifies this behavior as an insecure snippet example.
  • Examples: Static initialization vectors and keys appear directly in security-related snippets.The appendix labels the example as a sample of static IVs and keys.
  • Examples: A literal string is used to seed SecureRandom.The listing shows keyStart assigned from "this is a key" before sr.setSeed(keyStart).
  • Examples: The TrustManager example leaves certificate-trust methods empty and returns null for accepted issuers.The displayed methods include client and server trust checks plus getAcceptedIssuers().
Loading 1710.03135v1…