How Reliable is the Crowdsourced Knowledge of Security Implementation?

TL;DR

This study investigates the reliability of security advice on Stack Overflow, revealing many insecure suggestions, ineffective community feedback, and the failure of reputation systems to identify trustworthy security solutions.

Contribution

The paper provides an empirical analysis of security-related answers on Stack Overflow, highlighting the prevalence of insecure advice and the community's inability to distinguish secure solutions.

Findings

Insecure answers have higher views and scores than secure ones.

34% of advice from reputable users was insecure.

Community feedback does not effectively differentiate secure from insecure answers.

Abstract

Stack Overflow (SO) is the most popular online Q&A site for developers to share their expertise in solving programming issues. Given multiple answers to certain questions, developers may take the accepted answer, the answer from a person with high reputation, or the one frequently suggested. However, researchers recently observed exploitable security vulnerabilities in popular SO answers. This observation inspires us to explore the following questions: How much can we trust the security implementation suggestions on SO? If suggested answers are vulnerable, can developers rely on the community's dynamics to infer the vulnerability and identify a secure counterpart? To answer these highly important questions, we conducted a study on SO posts by contrasting secure and insecure advices with the community-given content evaluation. We investigated whether SO incentive mechanism is effective in improving security properties of distributed code examples. Moreover, we also traced duplicated answers to assess whether the community behavior facilitates propagation of secure and insecure code suggestions. We compiled 953 different groups of similar security-related code examples and labeled their security, identifying 785 secure answer posts and 644 insecure ones. Compared with secure suggestions, insecure ones had higher view counts (36,508 vs. 18,713), received a higher score (14 vs. 5), and had significantly more duplicates (3.8 vs. 3.0) on average. 34% of the posts provided by highly reputable so-called trusted users were insecure. Our findings show that there are lots of insecure snippets on SO, while the community-given feedback does not allow differentiating secure from insecure choices. Moreover, the reputation mechanism fails in indicating trustworthy users with respect to security questions, ultimately leaving other users wandering around alone in a software security minefield.

Figures

Tables

Table 1. TABLE I: Criteria used to decide code’s security property

Category	Parameter	Insecure
SSL/TLS	HostnameVerifier	allow all hosts
	Trust Manager	trust all
	Version	TLSv1.1
	Cipher Suite	RC4, 3DES, AES-CBC MD5, MD2
	OnReceivedSSLError	proceed
	Cipher/Mode	RC2, RC4, DES, 3DES, AES/ECB, Blowfish
Symmetric	Key	static, bad derivation
	Initialization Vector (IV)	zeroed, static, bad derivation
	Password Based Encryption (PBE)	1k iterations, 64-bit salt, static salt
Asymmetric	Key	RSA 2,048 bit, ECC 224 bit
	PBKDF	SHA224, MD2, MD5
Hash	Digital Signature	SHA1, MD2, MD5
	Credentials	SHA1, MD2, MD5
	Type	Random
Random	Seeding	setSeed$\to$nextBytes, setSeed with static values

Table 2. TABLE II: Tags used to locate relevant SO discussion threads

Category	Tags
Java platforms	android, applet, eclipse, java, java1.4, java-7, java-ee, javamail, jax-ws, jdbc, jndi, jni, …
Third-party tools/libraries	axis2, bouncycastle, gssapi, httpclient, java-metro-framework, openssh, openssl, spring-security, …
Security	aes, authentication, certificate, cryptography, des, encoding, jce, jks, jsse, key, random, rsa, security, sha, sha512, single-sign-on, ssl, tls, X509certificate, …

Table 3. TABLE III: Code labeling results for 2,657 clone groups

	Secure	Insecure	Mixed	Irrelevant	Total
# of clone groups	587	326	40	1,704	2,657
# of snippets	1,802	1,319	0	5,569	8,690
# of answer posts	785	644	0	2,133	3,562

Table 4. TABLE IV: Comparison between secure and insecure posts

		Score	Comment count	Reputation	Favorite count	View count
All	Secure mean	5	2	18,654	8	18,713
	Insecure mean	14	3	14,678	15	36,580
	p-value	0.97	0.02	0.02	0.09	1.5e-3
	Cliff’s $\Delta$	-	0.07 (negligible)	0.07 (negligible)	-	0.10 (negligible)
Category 1:	Secure mean	7	2	14,447	9	21,419
	Insecure mean	18	3	15,695	19	37,445
SSL/TLS	p-value	0.24	3.3e-4	0.42	0.86	0.31
	Cliff’s $\Delta$	-	0.20 (small)	-	-	-
Category 2:	Secure mean	5	3	19,347	7	16,232
	Insecure mean	7	3	10,057	6	16,842
Symmetric	p-value	0.29	0.82	0.45	0.36	0.10
	Cliff’s $\Delta$	-	-	-	-	-
Category 3:	Secure mean	5	2	17,079	4	11,987
	Insecure mean	8	2	14,151	3	9,470
Asymmetric	p-value	0.17	0.45	0.72	0.95	0.77
	Cliff’s $\Delta$	-	-	-	-	-
Category 4:	Secure mean	5	2	20,382	8	21,254
	Insecure mean	14	2	20,018	22	74,482
Hash	p-value	0.26	0.78	0.18	0.20	0.07
	Cliff’s $\Delta$	-	-	-	-	-
Category 5:	Secure mean	1	3	33,517	0	1,031
	Insecure mean	21	6	17,202	31	56,700
Random	p-value	0.04	0.02	0.27	0.02	0.01
	Cliff’s $\Delta$	0.58 (large)	0.68 (large)	-	0.64 (large)	0.74 (large)
Similar to prior work [38], we interpreted the computed Cliff’s delta value $v$ in the following way: (1) if , the effect size is “negligible”; (2) if , the effect size is “small’; (3) if , the effect size is “medium”; (4) otherwise, the effect size is “large”.

Table 5. TABLE V: Comparison between secure and insecure groups in terms of their group sizes

	Secure groups’ mean	Insecure groups’ mean	p-value	Cliff’s $\Delta$
Size	3.0	3.8	1.3e-4	0.13 (negligible)

Full text

To answer these highly important questions, we conducted a comprehensive study on security-related SO posts by contrasting secure and insecure advice with the community-given content evaluation. Thereby, we investigated whether SO’s gamification approach on incentivizing users is effective in improving security properties of distributed code examples. Moreover, we traced the distribution of duplicated samples over given answers to test whether the community behavior facilitates or prevents propagation of secure and insecure code suggestions within SO.

We compiled 953 different groups of similar security-related code examples and labeled their security, identifying 785 secure answer posts and 644 insecure answer posts. Compared with secure suggestions, insecure ones had higher view counts (36,508 vs. 18,713), received a higher score (14 vs. 5), and had significantly more duplicates (3.8 vs. 3.0) on average. 34% of the posts provided by highly reputable so-called trusted users were insecure.

Our findings show that based on the distribution of secure and insecure code on SO, users being laymen in security rely on additional advice and guidance. However, the community-given feedback does not allow differentiating secure from insecure choices. The reputation mechanism fails in indicating trustworthy users with respect to security questions, ultimately leaving other users wandering around alone in a software security minefield.

I Introduction

Since its launch in 2008, Stack Overflow (SO) has served as the infrastructure for developers to discuss programming-related questions online, and provided the community with crowdsourced knowledge [1, 2]. Prior work shows that SO is one of the most important information resources that developers rely on [3, 4]. Meanwhile, researchers also revealed that some highly upvoted, or even accepted answers on SO contained insecure code [5, 6]. More alarmingly, Fischer et al. found that insecure code snippets from SO were copied and pasted into 196,403 Android applications available on Google Play [5]. Several high-profile applications containing particular instances of these insecure snippets were successfully attacked, and user credentials, credit card numbers and other private data were stolen as a result [7].

These observations made us curious about SO’s reliability regarding suggestions for security implementations. Taking a pessimistic view, such insecure suggestions can be expected to be prevalent on the Q&A site, and consistent corrective feedback by the programming community may be amiss. Consequently, novice developers may learn about incorrect crowdsourced knowledge from such Q&A sites, propagate the misleading information to their software products or other developers, and eventually make our software systems vulnerable to known security attacks.

Therefore, within this paper, we conducted a comprehensive in-depth investigation of the popularity of both secure and insecure coding suggestions on SO, and the community activities around them. To ensure a fair comparison between secure and insecure suggestions, we focused on the discussion threads related to Java security. We used Baker [8] to mine for answer posts that contained any code using security libraries, and extracted 25,855 such code snippets. We reused the security domain expertise summarized by prior work [5] to manually label whether a given code snippet is secure or not. However, different from prior work [5] that studied the application of insecure SO answers to production code, our work focuses on the SO suggestions themselves. More specifically, we studied coding suggestions’ popularity, social dynamics, and duplication. We also inquired how developers may be misled by insecure answers on SO.

To identify prevalent topics on SO, we used CCFinder [9] to detect code clones (i.e., duplicated code) in the data extracted by Baker. These clones are clustered within clone groups. 953 clone groups were observed to use security library APIs and implement functionalities like SSL/TLS, symmetric and asymmetric encryption, etc. Moreover, we found that code examples within clone groups are more likely to be viewed than non-duplicated code snippets on SO. This further motivates our sampling method as we can expect clones to have a higher impact on users and production code. Among the 953 clone groups, there were 587 groups of duplicated secure code, 326 groups of similar insecure code, and 40 groups with a mixture of secure and insecure code snippets. These clone groups covered 1,802 secure code snippets and 1,319 insecure ones. By mapping cloned code to their container posts, we contrasted insecure suggestions with secure ones in terms of their popularity, users’ feedback, degree of duplication, and causes for duplication.

We explored the following Research Questions (RQs):

• •

RQ1: How prevalent are insecure coding suggestions on SO? Prior work witnessed the existence of vulnerable code on SO, and indicates that such code can mislead developers and compromise the quality of their software products [4, 5, 6]. To understand the number and growth of secure and insecure options that developers have to choose from, we (1) compared the occurrence counts of insecure and secure answers, and (2) observed the distributions of both kinds of answers across a 10-year time frame (2008-2017).

• •

RQ2: Do the community dynamics or SO’s reputation mechanism help developers choose secure answers over insecure ones? Reputation mechanisms and voting were introduced to crowdsourcing platforms to (1) incentivize contributors to provide high-quality solutions, and (2) facilitate question askers to identify responders with high expertise [10, 11, 12]. We conducted statistical testing to compare secure and insecure answers in terms of votes, answerers’ reputations, etc.

• •

RQ3: Do secure coding suggestions have more duplicates than insecure ones? When certain answers are repetitively suggested, it is likely that developers will encounter such answers more often. Moreover, if these answers are provided by different users, the phenomenon might facilitate users’ trust in the answers’ correctness. Therefore, we compared the degree of repetitiveness for insecure and secure answers.

• •

RQ4: Why did users suggest duplicated secure or insecure answers on SO? We were curious about why certain code was repetitively suggested, and we explored this facet of community behavior by examining the duplicated answers posted by the same or different users.

In our study, we made four major observations:

As with secure answers, insecure answers are prevalent on SO across the entire studied time frame. The inspected 3,121 snippets from different clone groups correspond to 785 secure posts and 644 insecure ones. Among the 505 SSL/TLS-related posts, 355 posts (70%) suggest insecure solutions, which makes SSL/TLS-related answers the most unreliable ones on SO. At least 41% of the security-related answers posted every year are insecure, which shows that security knowledge on SO in general is not significantly improving over time. 2. 2.

The community dynamics and SO’s reputation mechanisms are not reliable indicators for secure and insecure answers. Compared with secure posts, insecure ones obtained higher scores, more comments, more favorites, and more views. Although the providers of secure answers received significantly higher reputation scores, the effect size is negligible ($<$0.147). 239 of the 536 examined accepted answers (45%) are insecure. 26 out of the 72 posts (36%) suggested by “trusted users” (with $\geq$20K reputation scores [13]) are insecure. These observations imply that reputation and voting on SO are not reliable to help users distinguish between secure and insecure answers. 3. 3.

The degree of duplication among insecure answers is significantly higher than that of secure ones. On average, there are more clones in an insecure group than a secure one (3.8 vs. 3.0). It means that users may have to deal with a large supply of insecure examples for certain questions, before obtaining secure solutions. 4. 4.

Users seem to post duplicated answers, while ignoring security as a key property. Duplicated answers were provided due to duplicated questions or users’ intent to answer more questions by reusing code examples. This behavior is incentivized by the reputation system on SO. The more answers are posted by a user and up-ranked by the community, the higher reputation the user gains.

Our source code and data set are available at https://github.com/mileschen360/Higgs.

II Background

To facilitate the discussion of SO community activities around security implementations, we will first introduce SO’s crowdsourcing model, and then summarize the domain knowledge used to label secure and insecure code snippets.

II-A Stack Overflow as a Crowdsourcing Platform

Some observers believe that the success of SO lies in its crowdsourcing model and the reputation system [15, 2]. The four most common forms of participation are i) question asking, ii) question answering, iii) commenting, and iv) voting/scoring [15]. Figure 1 presents an exemplar SO discussion thread, which contains one question and one or many answers. When multiple answers are available, the asker decides which answer to accept, and marks it with “✓”.

After a user posts a question, an answer, or a comment, other users can vote for or against the post. Users gain reputation for each up-vote their posts receive. For instance, answers earn their authors 10 points per up-vote, questions earn 5, and comments earn 2 [16]. All users initially have only one reputation point. As users gain more reputation, they are granted more administrative privileges to help maintain SO posts [13]. For instance, a user with 15 points can vote up posts. A user with 125 points can vote down posts. Users with at least 20K points are considered “trusted users”, and can edit or delete other people’s posts.

The score of a question or answer post is decided by the up-votes and down-votes the post received. Users can favorite a question post if they want to bookmark the question and keep track of any update on the discussion thread. Each question contains one or many tags, which are words or phrases to describe topics of the question. Each post has a timestamp to show when it was created. Each discussion thread has a view count to indicate how many times the thread has been viewed.

II-B Categorization of Java Security Implementations

Based on state-of-the-art security knowledge, researchers defined five categories of security issues relevant to library misuses [5]. Table I shows their criteria, which we use in this project to decide whether a code snippet is insecure or not.

SSL/TLS

There are five key points concerning how to securely establish SSL/TLS connections. First, developers should use an implementation of the HostnameVerifier interface to verify servers’ hostnames instead of allowing all hosts [7]. Second, when implementing a custom TrustManager, developers should validate certificates instead of blindly trusting all certificates. Third, when “TLS” is passed as a parameter to SSLContext.getInstance(...);, developers should explicitly specify the version number to be at least 1.1, because TLS’ lower versions are insecure [17]. Fourth, the usage of insecure cipher suites should be avoided. Fifth, when overriding onReceivedSslError(), developers should handle instead of skipping any certificate validation error. Listing 1 shows a vulnerable snippet that allows all hosts, trusts all certificates, and uses TLS v1.0.

Symmetric

There are ciphers and modes of operations known to be insecure. Cryptographic keys and initialization vectors (IV) are insecure if they are statically assigned, zeroed, or directly derived from text. Password Based Encryption (PBE) is insecure if the iteration number is less than 1,000, the salt’s size is smaller than 64 bits, or a static salt is in use. Listing 2 presents a vulnerable code example that insecurely declares a cipher, a key, and an IV.

Asymmetric

Suppose that a code snippet uses either RSA or ECC APIs to generate keys. When the specified key lengths for RSA and ECC are separately shorter than 2,048 bits and 224 bits, we consider the API usage to be insecure. Listing 3 shows a vulnerable code example.

Hash

In the context of password-based key derivation, digital signatures, and authentication/authorization, developers may explicitly invoke broken hash functions. Listing 4 shows an example using MD5.

Random

To make the generated random numbers unpredictable and secure, developers should use SecureRandom instead of Random. When using SecureRandom, developers can either (1) call nextBytes() only, or (2) call nextBytes() first and setSeed() next. Developers should not call setSeed() with static values. Listing 5 presents an example using SecureRandom insecurely.

III Methodology

To collect secure and insecure answer posts, we first extracted code snippets from SO that used any security API (Section III-A). Next, we sampled the extracted code corpus by detecting duplicated code (Section III-B). Finally, we manually labeled sampled code as secure, insecure, or irrelevant, and mapped the code to related posts (Section III-C). Additionally, we compared the view counts of the sampled posts vs. unselected posts to check samples’ prevalence (Section III-D).

III-A Code Extraction

To identify coding suggestions, this step extracts security-related answer posts by analyzing (1) tags of question posts, and (2) the code snippets’ API usage of answer posts. After downloading the Stack Overflow data as XML files [23], we used a tool stackexchange-dump-to-postgres [24] to convert the XML files to Postgres database tables. Each row in the database table “Posts” corresponds to one post. A post’s body text may use the HTML tag pair <code> and </code> to enclose source code, so we leveraged this tag pair to extract code. Since there were over 40 million posts under processing, and one post could contain multiple code snippets, it is very challenging to efficiently identify security implementations from a huge amount of noisy code data. Thus, we built two heuristic filters to quickly skip irrelevant posts and snippets.

III-A1 Filtering by question tags

As tags are defined by askers to describe the topics of questions, we relied on tags to skip obviously irrelevant posts. To identify as many security coding suggestions as possible, we inspected the 64 cryptography-related posts mentioned in prior work [6], and identified 93 tags. If a question post contains any of these tags, we extracted code snippets from the corresponding answer posts. As shown in Table II, these tags are either related to Java platforms, third-party security libraries or tools, or security concepts.

III-A2 Filtering by security API usage

Similar to prior work [5], we used Baker [8] to decide whether a snippet calls any security API. This paper focuses on the following APIs:

• •

Java platform security: org.jetf.jgss., android.security., com.sun.security., java.security., javax.crypto., javax.net.ssl., javax.security., javax.xml.crypto.;

• •

Third-party security libraries: BouncyCastle [25], GNU Crypto [26], jasypt [27], keyczar [28], scribejava [29], SpongyCastle [30].

After taking in a set of libraries and a code snippet, Baker (1) extracts all APIs of types, methods, and fields from the libraries, (2) extracts names of types, methods, and fields, used in the code snippet, and (3) iteratively deduces identifier mappings between the extracted information. Intuitively, when multiple type APIs (e.g., a.b.C and d.e.C) can match a used type name C, Baker compares the invoked methods on C against the method APIs declared by each candidate type, and chooses the candidate that contains more matching methods.

We included a code snippet if Baker finds at least one API (class or method) with an exact match. However, Baker’s result set is not fully accurate and requires a number of post-processing steps to reduce false positives. These include a blacklist filter for standard Java types (e.g., String) and very popular methods (e.g., get()). Baker’s oracle contains only the given security APIs, which helped reduce false positives when detecting secure code but did not help reduce false negatives.

III-B Clone Detection

With the filters described above, we identified 25,855 code snippets (from 23,224 posts) that are probably security-related. Since it is almost impossible to manually check all these snippets to identify secure and insecure code, we decided to (1) sample representative extracted code via clone detection, and then (2) manually label the samples. In addition to sampling, clone detection facilitates our research in two further ways. First, by identifying duplicated code with CCFinder [9], we could explore the degree of duplication among secure and insecure code. Second, through clustering code based on their similarity, we could efficiently read similar code fragments, and determine their security property in a consistent way. With the default parameter setting in CCFinder, we identified 2,657 clone groups that contained 8,690 code snippets, with each group having at least two snippets.

III-C Code Labeling

We manually examined each of those 8,690 snippets and labeled code based on the criteria mentioned in Section II. If a snippet meets any criteria of insecure code shown in Table I, it is labeled as “insecure”. If the snippet uses any security API but does not meet any criteria, it is labeled as “secure”; otherwise, it is “irrelevant”. Depending on the APIs involved, we also decided to which security category a relevant post belongs. When unsure about certain posts, we had discussions to achieve consensus. Finally, we randomly explored a subset of the labeled data to double check the correctness.

Table III presents our labeling results for the inspected 2,657 clone groups. After checking individual code snippets, we identified 587 secure groups, 326 insecure groups, 40 mixed groups, and 1,704 irrelevant groups. In particular, a mixed group has both secure snippets and insecure ones, which are similar to each other. Although two filters were used (see Section III-A), 64% of the clone groups from refined data were still irrelevant to security, which evidences the difficulty of precisely identifying security implementation with Baker.

The clone groups cover 1,802 secure snippets, 1,319 insecure ones, and 5,569 irrelevant ones. When mapping these snippets to the answer posts (which contain them), we identified 785 secure answers, 644 insecure ones, and 2,133 irrelevant ones. One answer can have multiple snippets of different clone groups. Therefore, we consider a post “insecure” if it contains any labeled insecure code. A post was labeled “secure” if it has no insecure snippet but at least one secure snippet. If a post does not contain any (in)secure snippet, it is labeled as “irrelevant”.

III-D Verifying the Prevalence of Sampled Posts

To check whether our clone-based approach actually included representative SO posts, we separately computed the cumulative distribution functions (CDF) [31] of view count for the included 3,562 posts (as mentioned in Table III), the excluded 19,662 posts, and the complete set of 23,224 posts identified by Baker. As shown in Fig. 2, the “included” curve is beneath the “all” and “excluded” curves. This shows that the highly viewed answers take up a higher percentage in our sample set than the excluded answers.

IV Major Findings

In this section, we present our results and discuss the main findings regarding our stated research questions.

IV-A Popularity of Secure and Insecure Code Suggestions

Figure 3 presents the distribution of 1,429 answer posts among the 5 security categories. Since some posts contain multiple snippets of different categories, the total number of plotted secure and insecure posts in Figure 3 is 1,506, slightly larger than 1,429. Among the categories, SSL/TLS contains the most posts (34%), while Random has the fewest posts (2%). Two reasons can explain such a distribution. First, developers frequently use or are more concerned about APIs of SSL/TLS, Symmetric, and Hash. Second, the criteria we used to label code contain more diverse rules for the above-mentioned three categories, so we could identify more instances of such code.

There are many more insecure snippets than secure ones in the SSL/TLS (355 vs. 150) category, indicating that developers should be quite cautious when searching for such code. Meanwhile, secure answers dominate the other categories, accounting for 94% of Asymmetric posts, 71% of Hash posts, 54% of Symmetric posts, and 52% of Random posts. However, notice that across these 4 categories, only 67% of the posts are secure; that is, considerable room for error remains.

Finding 1: *644 out of the 1,429 inspected answer posts (45%) are insecure, meaning that insecure suggestions popularly exist on SO. Insecure answers dominate, in particular, the SSL/TLS category. *

To explore the distribution of secure and insecure answers over time, we clustered answers based on their timestamps. As shown in Figure 4, both types of answers increased year-by-year from 2008 to 2014, and decreased in 2015-2017. This may be because SO reached its saturation for Java security-related discussions in 2014-2015. In 2008, 2009, and 2011, insecure answers were posted more often than secure ones, taking up 53%-100% of the sampled data of each year. For the other years, secure posts constitute the majority within the yearly sampled data set, accounting for 53%-59%.

To further determine whether older posts are more likely to be insecure, we considered post IDs as logical timestamps. We applied a Mann-Whitney U test (which does not require normally distributed data [32]), and calculated the Cliff’s delta size (which measures the difference’s magnitude [33]). The resulting $p$-value is 0.02, with Cliff’s $\Delta$=0.07. It means that secure answers are significantly more recent than insecure ones, but the effect size is negligible.

Two reasons can explain this finding. First, some vulnerabilities were recently revealed. Among the 17 insecure posts in 2008 and 2009, 6 answers use MD5, 6 answers trust all certificates, and 4 answers use TLS 1.0. However, these security functions were found broken in 2011-2012 [34, 35, 7, 36], which made the answers obsolete and insecure. Second, some secure answers were posted to correct insecure suggestions. For instance, we found a question inquiring about fast and simple string encryption/decryption in Java [37]. The accepted answer in 2011 suggested DES—an insecure symmetric-key algorithm. Later, various comments pinpointed the vulnerability and a secure answer was provided in 2013.

Note that there can be a significant lag until the community adopts new secure technologies, and phases out technologies known to be insecure. Although MD5’s vulnerability was exploited by Flame malware in 2012 [34], as shown in Fig. 5, MD5 was still popularly suggested afterwards, obtaining a peak number of related answers in 2014.

Finding 2: *Insecure posts led the sampled data in 2008-2011, while secure ones were dominant afterwards. Older security-related posts are less reliable, likely because recently revealed vulnerabilities outdated older suggestions. We found only few secure answers suggested to correct outdated, insecure ones. *

IV-B Community Dynamics Towards Secure and Insecure Code

For each labeled secure or insecure post, we extracted the following information: (1) score, (2) comment count, (3) the answerer’s reputation score, (4) the question’s favorite count, and (5) the discussion thread’s view count.

Comparison of Mean Values. Table IV compares these information categories for the 785 secure posts and 644 insecure ones and applies Mann-Whitney U tests to determine significant results. On average, secure posts’ answerers have higher reputation (18,654 vs. 14,678). However, for the SSL/TLS posts, the insecure answer providers have higher reputation (15,695 vs. 14,447). Moreover, insecure posts have higher scores, and more comments, favorites, and views. Users seemed to be more attracted by insecure posts, which is counterintuitive. We would expect secure answers to be seen more favorable; with more votes, comments and views.

Three reasons can explain our observation. First, software developers often face time constraints. When stuck with coding issues (e.g., runtime errors), developers are tempted to take insecure but simpler solutions [6]. Take the vulnerable SSL/TLS usage in Listing 1 for example. The insecure code was frequently suggested on SO, and many users voted for it mainly because the code is simple and useful to resolve connection exceptions. Nevertheless, the simple solution essentially skips SSL verification and voids the protection mechanism. In comparison, a better solution should use certificates from a Certification Authority (CA) or self-signed certificates to drive the customization of TrustManager, and verify certificates with more complicated logic [39].

Second, some insecure algorithms are widely supported by Java-based libraries, which can promote developers’ tendency to code insecurely. For instance, up till the current version Java 9, Java platform implementations have been required to support MD5—the well-known broken hash function [40]. Third, insecure posts are less recent and may have accumulated more positive scores than recent secure posts.

Finding 3: *On average, insecure posts received higher scores, more comments, more favorites, and more views. It implies that (1) more user attention is attracted by insecure answers; and (2) users cannot rely on the voting system to identify secure answers. *

Comparison of p-values and Cliff’s $\Delta$. Table IV shows that among all posts, insecure ones obtained significantly more comments ($p=0.02$) and views ($p=1.5\mathrm{e}{-3}$), while the effect sizes are negligible. Specifically for the Random category, insecure posts have significantly higher view counts ($p=0.01$) and the effect size is large. Meanwhile, the owners of secure answer posts have significantly higher reputation ($p=0.02$) but the magnitude is also negligible.

Figure 6 further clusters answers based on their owners’ reputation scores. We used logarithmic scales for the horizontal axis, because the scores vary a lot within the range [1, 990,402]. Overall, the secure and insecure answers have similar distributions among different reputation groups. For instance, most answers were provided by users with scores within [$10^{2}$, $10^{4}$), accounting for 61% of secure posts and 68% of insecure posts. Among the 208 posts by trusted users, 71 answers (34%) are insecure and not reliable. One reason to explain why high reputation scores do not guarantee secure answers can be that users earned scores for being an expert in areas other than security. Responders’ reputation scores do not necessarily indicate the security property of the provided answers. Therefore, SO users should not blindly trust the suggestions given by highly reputable contributors.

Finding 4: *The users who provided secure answers have significantly higher reputation than the providers of insecure answers, but the difference in magnitude is negligible. Users cannot rely on the reputation mechanism to identify secure answers. *

**Comparison of accepted answers. ** It is natural for SO users to trust accepted answers. Among the 1,429 posts, we found 536 accepted answers (38%). 297 accepted answers are secure, accounting for 38% of the inspected secure posts. 239 accepted answers are insecure, accounting for 37% of the inspected insecure posts. It seems that accepted answers evenly distribute among secure and insecure posts; they are not good indicators of suggestions’ security property.

Finding 5: *Accepted answers are also not reliable for users to identify secure coding suggestions. *

IV-C Duplication of Secure and Insecure Code

Among the 953 security-related clone groups, we explored the degree of code duplication for secure clone groups, insecure groups, and mixed groups. Figure 7 shows the distribution of clone groups based on their sizes. Similar to Fig. 6, we used logarithmic scales for both the horizontal and vertical axes. In Fig. 7, most clone groups are small, with 2-3 similar snippets. The number of groups decreases dramatically as the group size increases. Interestingly, within $[2^{4},2^{6})$, there are more insecure groups than secure ones. Table V compares the sizes of secure and insecure groups. Surprisingly, insecure groups have significantly larger sizes than secure ones, although the difference is negligible. Our observations imply that the frequently mentioned code snippets on SO are not necessarily more secure than less frequent ones. Users cannot trust code’s repetitiveness to decide the security property.

**Finding 6: ** * Repetitiveness does not guarantee security, so users cannot assume a snippet to be secure simply because it is recommended many times. *

To understand why there are mixed groups that contain similar secure and insecure implementations, we conducted a case study on 10 randomly selected mixed groups. Among all these groups, secure snippets differ from insecure ones by using distinct parameters when calling security APIs. This implies a great opportunity to build security bug detection tools that check for the parameter values of specific APIs.

Listing 6 shows a mixed clone group, where the insecure code uses “AES/ECB” to create a cipher, and the secure code uses “AES/CFB”. Actually, both snippets were provided by the same user, which explains why they are so similar. These answers are different because the askers inquired for different modes (ECB vs. CFB). Although the answerer is an expert in using both APIs and has a high reputation score 27.7K, he/she did not mention anything about the vulnerability of ECB. This may imply a lack of security expertise or vulnerability awareness of highly reputable SO users, and a well-motivated need for automatic tools to detect and fix insecure code.

**Finding 7: ** * Secure and insecure code in the same mixed group often differs by passing distinct parameters to the same security APIs highlighting opportunities for automatic tools to handle security weaknesses. *

IV-D Creation of Duplicated Secure and Insecure Code

We conducted two case studies to explore why duplicated code was suggested.

Case Study I: Duplicated answers by different users. We examined the largest secure group and largest insecure group. The secure group has 65 clone instances, which are similar to the code in Listing 7. These snippets were offered to answer questions on how to enable an Android app to log into Facebook. The questions are similar but different in terms of the askers’ software environments (e.g., libraries and tools used) and potential solutions they tried. Among the 65 answers, only 18 (28%) were marked as accepted answers. The majority of duplicated suggestions are relevant to the questions, but cannot solve the issues. SO users seemed to repetitively provide “generally best practices”, probably because they wanted to earn points by answering more questions.

The largest insecure group contains 32 clone instances, which are similar to the code in Listing 1. The questions are all about how to implement SSL/TLS or resolve SSL connection exceptions. 13 of these answers (41%) were accepted. We noticed that only one answer warns “Do not implement this in production code …” [44]. Six answers have at least one comment talking about the vulnerability. The remaining 25 answers include nothing to indicate the security issue.

Case Study II. Duplicated answers by the same users. In total, 109 users reused code snippets to answer multiple questions. Among the 207 clone groups these users produced, there are 111 secure groups, 90 insecure groups, and 6 mixed groups. 66 users repetitively posted secure answers, and 49 users posted duplicated insecure answers. Six among these users posted both secure and insecure answers. Most users (i.e., 92) only copied code once and produced two duplicates. One user posted nine insecure snippets, with seven snippets using an insecure version of TLS, and two snippets trusting all certificates. This user has 17.7K reputation (top 2% overall) and is an expert in Android. By examining the user’s profile, we did not find any evidence to show that the user intentionally misled people. It seems that the user was not aware of the vulnerability when posting these snippets.

To understand whether duplicated code helps answer questions, we randomly sampled 103 (of the 208) clone groups resulting in 56 secure clone pairs, 45 insecure pairs, and 2 mixed pairs. Unexpectedly, we found that 46 pairs (45%) did not directly answer the questions. For instance, a user posted code without reading the question and received down-vote (i.e., $-1$) [45]. In the other 57 cases, duplicated code was provided to answer similar or identical questions.

**Finding 8: ** *Duplicated answers were created because (1) users asked similar or related questions; and (2) some users blindly copied and pasted code to answer more questions and earn points. However, we did not identify any user that intentionally misled people by posting insecure answers. *

V Related Work

V-A Security API Misuses

Prior studies showed that API misuses caused security vulnerabilities [46, 7, 35, 47, 48, 49, 50, 5]. For instance, Lazar et al. analyzed 369 published cryptographic vulnerabilities in the CVE database, and found that 83% of them were caused by API misuses  [48]. Egele et al. built a static checker for six well-defined Android cryptographic API usage rules (e.g., “Do not use ECB mode for encryption”). They analyzed 11,748 Android applications for any rule violation [47], and found 88% of the applications violating at least one checked rule. Instead of checking for insecure code in CVE or software products, we focused on SO. Because the insecure coding suggestions on SO can be read and reused by many developers, they have a profound impact on software quality.

The research by Fischer et al. [5] is closely related to our work. In their work, secure and insecure snippets from SO were used to search for code clones in Android apps. Our research is different in three aspects. First, it investigates the evolution and distribution of secure and insecure coding suggestions within the SO ecosystem itself. Second, while [5] compares average score and view counts for secure and insecure snippets, they merely do this for snippets whose exact copies have migrated into apps but not for our much broader set of snippets on SO. Therefore, the dataset of [5] is not representative to evaluate the impact of severity, community’s awareness, and popularity of unreliable SO suggestions on secure coding. Third, we conducted not only statistical testing on a comprehensive dataset to quantitatively contrast score, view count, comment count, reputation, and favorite count, but also case studies to qualitatively analyze the differences. We further explored the missing link between gamification and security advice quality on crowdsourcing platforms.

V-B Developer Studies

Researchers conducted interviews or surveys to understand developers’ security coding practices [51, 52, 53, 4]. For example, Nadi et al. surveyed 48 developers and revealed that developers found it difficult to use cryptographic algorithms correctly [53]. Xie et al. interviewed 15 developers, and found that (1) most developers had reasonable knowledge about software security, but (2) they did not consider security assurance as their own responsibility [51]. Acar et al. surveyed 295 developers and conducted a lab user study with 54 students and professional Android developers [4]. They observed that most developers used search engines and SO to address security issues. These studies inspired us to explore how much we can trust the crowdsourced knowledge of security coding on SO.

V-C Empirical Studies on Stack Overflow

Researchers conducted various studies on SO [3, 54, 55, 50, 56, 6, 57]. Specifically, Zhang et al. studied the JDK API usage recommended by SO, and observed that 31% of the studied posts misused APIs [6]. Meng et al. manually inspected 503 SO discussion threads related to Java security [6]. They revealed various secure coding challenges (e.g., hard-to-configure third-party frameworks) and vulnerable coding suggestions (e.g., SSL/TLS misuses). Mamykina et al. revealed several reasons (e.g., high response rate) to explain why SO is one of the most visible venues for expert knowledge sharing [3]. Vasilescu et al. studied the associations between SO and GitHub, and found that GitHub committers usually ask fewer questions and provide more answers [58]. Bosu et al. analyzed the dynamics of reputation building on SO, and found that answering as many questions as possible can help users quickly earn reputation [54].

In comparison, our paper quantitatively and qualitatively analyzed secure and insecure SO suggestions in terms of (1) their popularity, (2) answerers’ reputations, (3) the community’s feedback to answers (e.g., votes and comments), and (4) the degree and causes of duplicated answers. We are not aware of any prior work that analyzes SO posts in these aspects.

V-D Duplication Detection Related to SO or Vulnerabilities

Researchers used clone detection to identify duplication within SO or between SO and software products  [59, 60, 61, 62, 63]. Specifically, Ahasanuzzaman et al. detected duplicated SO questions with machine learning [60]. An et al. compared code between SO and Android apps and observed unethical code reuse phenomena on SO [61]. Other researchers used static analysis to detect vulnerabilities caused by code cloning [64, 65, 66, 67]. For instance, Kim et al. generate a fingerprint for each Java method to efficiently search for clones of a given vulnerable snippet [67]. Different from prior work, we did not invent new clone detection techniques or compare code between SO and software projects. We used clone detection to (1) sample crawled security-related code, and (2) explore why SO users posted similar code to answer questions.

VI Our Recommendations

By analyzing SO answer posts relevant to Java-based security library usage, we observed the wide-spread existence of insecure code. It is worrisome to learn that SO users cannot rely on either the reputation mechanism or voting system to infer an answer’s security property, A recent Meta Exchange discussion thread also shows the frustration of SO developers to keep outdated security answers up to date [68]. Below are our recommendations based on this analysis.

For Tool Builders

Explore approaches that accurately and flexibly detect and fix security bugs. Although a few tools identify security API misuses through static program analysis or machine learning [47, 69, 70, 5], they are unsatisfactory due to the (1) hard-to-extend API misuse patterns hardcoded in tools, and (2) hard-to-explain machine learning results. People report vulnerabilities and patches on CVE and in security papers. Tools like LASE [71] were built to (i) generalize program transformation from concrete code changes, and (ii) leverage the transformation to locate code for similar edits. If tool developers can extend such tools to compare secure-insecure counterparts, they can automatically fix vulnerabilities in a flexible way.

For SO Developers

Integrate static checkers to scan existing corpus and SO posts under submission. Automatically add warning messages or special tags to any post that has vulnerable code. Encourage moderators or trusted users to exploit clone detection technologies in order to efficiently detect and remove both duplicated questions and answers. Such deduplication practices will not only save users’ time and effort of reading/answering useless duplicates, but also mitigate the misleading consensus among multiple similar insecure suggestions. As user profiles include top tags to reflect the frequently asked/answered questions by users. instead of accumulating a single reputation score for each user, SO developers can compute one score for each top tag to better characterize users’ expertise.

For Designers of Crowdsourcing Platforms

Provide incentives to users for downvoting or detailing vulnerabilities and suggesting secure alternatives. Introduce certain mechanisms to encourage owners of outdated or insecure answers to proactively archive or close such posts. We expect researchers from the usable security and HCI domain to evaluate and test new design patterns that integrate security evaluation in the gamification approach.

VII Threats to Validity

Threat to External Validity

This study labels insecure code based on the Java security rules summarized by prior work [5], so our studied insecure snippets are limited to Java code and these rules. Since we used the state-of-the-art insecurity criteria, our analysis revealed as diverse insecure code as possible. In the future, we plan to identify more kinds of insecure code by considering different programming languages and exploiting multiple vulnerability detection tools [72, 73].

Threat to Construct Validity

Although we tried our best to accurately label code, our analysis may be still subject to human bias and cannot scale to handle all crawled data or more security categories. We conservatively assume a snippet to be secure if it does not match any given rule. However, it is possible that some labeled secure snippets actually match the insecurity criteria not covered by this study, or will turn out to be insecure when future attack technologies are created. We concluded that insecure answers are popular on SO and gain high scores, votes, and views. Even if the labels of some existing secure answers will be corrected as insecure in the future, our conclusion generally holds.

Threat to Internal Validity

We leveraged clone detection to sample the extracted code snippets and reduce our manual analysis workload. Based on code’s occurrence repetition, clone detection can ensure the representativeness of sampled data. However, the measurement on a sample data set may be still different from that of the whole data set. Once we build automatic approaches to precisely identify security API misuses, we can resolve this threat.

VIII Conclusion

We aimed to assess the reliability of the crowdsourced knowledge on security implementation. Our analysis of 1,429 answer posts on SO revealed 3 insights.

In general secure and insecure advices more or less balance each other (55% secure and 45% insecure). Users without security knowledge may heavily rely on the community to provide helpful feedback in order to identify secure advice. Unfortunately, we found the community’s feedback to be almost useless. For certain cryptographic API usage scenarios, the situation is even worse: insecure coding suggestions about SSL/TLS dominate the available options. This is particularly alarming as SSL/TLS is one of the most common use cases in production systems according to prior work [5]. 2. 2.

The reputation mechanism and voting system popularly used in crowdsourcing platforms turn out to be powerless to remove or discourage insecure suggestions. Insecure answers were suggested by people with high reputation and widely accepted as easy fixes for programming errors. On average, insecure answers received more votes, comments, favorites, and views than secure answers. As a countermeasure, security evaluation can be included in the voting and reputation system to establish missing incentives for providing secure and correcting insecure content. 3. 3.

When users are motivated to earn reputation by answering more questions, the platform encourages contributors to provide duplicated, less useful, or insecure coding suggestions. Therefore, with respect to security, SO’s gamification approach counteracts its original purpose as it promotes distribution of secure and insecure code. Although we did not identify any malicious user that misuses SO to propagate insecure code, we do not see any mechanism designed to prevent such malicious behaviors, either.

When developers refer to crowdsourced knowledge as one of the most important information resources, it is crucially important to enhance the quality control of crowdsourcing platforms. This calls for a strong collaboration between developers, security experts, tool builders, educators, and platform providers. By educating developers to contribute high-quality security-related information, and integrating vulnerability and duplication detection tools into platforms, we can improve software quality via crowdsourcing. Our future work is focused on building the needed tool support.

Acknowledgment

We thank reviewers for their insightful comments. We also thank Dr. Kurt Luther for his valuable feedback.