# Secure Coding Practices in Java: Challenges and Vulnerabilities

Na Meng, Stefan Nagy, Daphne Yao, Wenjie Zhuang, Gustavo Arango Argoty
1234-5678-9012 Virginia TechBlacksburgVirginia24060 nm8247, snagy2, danfeng,
kaito<EMAIL_ADDRESS>
###### Abstract.

Java platform and third-party libraries provide various security features to
facilitate secure coding. However, misusing these features can cost tremendous
time and effort of developers or cause security vulnerabilities in software.
Prior research was focused on the misuse of cryptography and SSL APIs, but did
not explore the key fundamental research question: what are the biggest
challenges and vulnerabilities in secure coding practices? In this paper, we
conducted a comprehensive empirical study on StackOverflow posts to understand
developers’ concerns on Java secure coding, their programming obstacles, and
potential vulnerabilities in their code.

We observed that developers have shifted their effort to the usage of
authentication and authorization features provided by Spring security—a third-
party framework designed to secure enterprise applications. Multiple
programming challenges are related to APIs or libraries, including the
complicated cross-language data handling of cryptography APIs, and the complex
Java-based or XML-based approaches to configure Spring security. More
interestingly, _we identified security vulnerabilities in the suggested code
of accepted answers_. The vulnerabilities included using insecure hash
functions such as MD5, breaking SSL/TLS security through bypassing certificate
validation, and insecurely disabling the default protection against Cross Site
Request Forgery (CSRF) attacks. Our findings reveal the insufficiency of
secure coding assistance and education, and the gap between security theory
and coding practices.

CSRF, SSL/TLS certificate validation, cryptographic hash functions,
authentication, authorization

††copyright: rightsretained††doi: 10.475/123_4††isbn:
123-4567-24-567/08/06††ccs: General and reference Empirical studies

##  1\. Introduction

Java platform and third-party libraries or frameworks (e.g., BouncyCastle (bc,
[n. d.]) and Spring Security (spr, [n. d.]c)) provide various features to
facilitate secure coding. However, misusing these libraries and frameworks not
only costs excessive debugging effort of developers, but also leads to
security vulnerabilities in software (Rashid, [n. d.]; cwe, [n. d.]; Shuai et
al., 2014; ver, [n. d.]). For example, Veracode identified software errors in
the handling of user credentials, including hard-coded password and plaintext
passwords in configuration files (ver, [n. d.]). These errors can enable
attackers to bypass access controls.

Prior research mainly focused on the misuse of cryptography and SSL APIs that
causes security vulnerabilities (Fahl et al., 2012; Georgiev et al., 2012;
Egele et al., 2013; Lazar et al., 2014). Specifically, Lazar et al. manually
examined 269 published cryptographic vulnerabilities in the CVE database, and
observed 83% of them were caused by cryptography API misuse (Lazar et al.,
2014). Fahl et al. (Fahl et al., 2012) and Georgiev et al. (Georgiev et al.,
2012) separately implemented the man-in-the-middle attack, and detected
vulnerable Android applications and software libraries that misused SSL APIs.
Nadi et al. further investigated the obstacles developers face while using the
Java cryptography APIs, the tasks for which they use the APIs, and the kind of
tool support they desire (Nadi et al., 2016). Despite these studies, some key
questions on secure coding practices remain unanswered. They include (1)
whether programmers are equipped with sufficient security knowledge and
automatic coding support, and (2) whether the coding practices benefitted from
security research over the years.

For this paper, we conducted _a comprehensive in-depth investigation on the
common concerns, programming challenges, and security vulnerabilities in
developers’ secure coding practices_ by manually inspecting 497 StackOverflow
posts related to Java security. We chose StackOverflow (sta, [n. d.]) because
(1) developers usually share and discuss programming issues and solutions on
this online platform, and (2) StackOverflow plays an important role in
educating developers and impacting their daily coding practices. The main
challenge of performing this empirical study is _interpreting each security-
relevant programming issue or solution within both the program context and
security context_. To comprehend each post within the program context, we
manually checked all mentioned information about the source code,
configuration files, and/or execution environments. Then we decided the root
cause and solution of the problem. To comprehend each post within the security
context, we also identified the security requirement that developers tried to
implement and investigated the involved security libraries. Then we determined
whether the implementation fulfilled the requirement. Such manual analysis
requires so much comprehension and expertise in both software engineering (SE)
and security that it is difficult to automate the process.

With our thorough manual analysis on the 497 posts, we investigated the
following three research questions (RQs):

  * RQ1

_What are the common concerns on Java secure coding?_ Although there are
various security libraries and frameworks (Oaks, 1998; Gong and Ellison, 2003;
spr, [n. d.]e; asr, [n. d.]; jaa, [n. d.]; jca, [n. d.]), several questions
are still unanswered, such as (1) which are the popular security features
being frequently asked about, and (2) what are the hard-to-implement security
defenses in practice?

  * RQ2

_What are the common programming challenges?_ We aim to identify the common
obstacles that prevented developers from implementing secure code easily and
correctly. This information will help guide SE researchers and tool builders
to better develop tools, and to help close the gap between the intended
library usage and developers’ actual usage.

  * RQ3

_What are the common security vulnerabilities?_ We aim to identify security
vulnerabilities in StackOverflow posts, because the bad practices recommended
on the platform can become popular and cause profound negative impact. This
effort will help raise the security consciousness of secure software
practitioners.

In our study, we made three major observations.

  * •

_There were multiple security vulnerabilities in the recommended code of some
accepted answers_. For instance, the usage of MD5 and SHA-1 algorithms were
repetitively suggested, although these algorithms are notoriously insecure and
should not be used anymore. Additionally, developers were advised to trust all
incoming SSL/TLS certificates from servers as a workaround to certificate
verification errors. Such practice completely disables the security checks of
SSL. Although this bad practice was initially reported by researchers in 2012
(Fahl et al., 2012; Georgiev et al., 2012), developers have still asked for
and accepted the practice till now. Furthermore, when implementing
authentication with Spring security and getting errors, developers were
suggested with a workaround solution to blindly disable the default security
protection against Cross Site Request Forgery (CSRF) attacks.

  * •

_There were various programming challenges related to security libraries_. For
instance, developers were stuck with cryptography API usage due to clueless
error messages, complex cross-language data handling, and delicate implicit
API usage constraints. However, when using Spring security, developers
struggled a lot with the two alternative ways of configuring security: Java-
based or XML-based.

  * •

_Software developers have shifted their security implementation effort to
Spring security since 2012._ 261 of the 497 examined posts (53%) were about
Spring security. However, we have not seen any research that checks or
analyzes the security vulnerabilities related to the framework.

The significance of this work is that we provided empirical evidence for a
significant number of alarming secure coding issues, which have not been
previously reported. These issues are due to a variety of reasons, including
the rapidly increasing need for enterprise security applications, the lack of
security training in the software development workforce, and poorly designed
security libraries. We hope our findings can motivate the community to
research solutions for helping developers overcome these obstacles in the long
term.

##  2\. Background

The examined StackOverflow posts were mainly about three perspectives of Java
security: Java platform security, Java EE security, and other third-party
frameworks. This section introduces the key terminologies used throughout the
paper.

###  2.1. Java Platform Security

The platform defines APIs spanning major security areas, including
cryptography, access control, and secure communication (jSe, [n. d.]).

_The Java Cryptography Architecture (JCA)_ contains APIs for hashes, keys and
certificates, digital signatures, and encryption (jca, [n. d.]). Nine
cryptographic engines are defined to provide either cryptographic operations
(encryption, digital signatures, hashes), generators or converters of
cryptographic material (keys and algorithm parameters), or objects (keystores
or certificates) that encapsulate the cryptographic data.

_The access control architecture_ protects the access to sensitive resources
(e.g., local files) or sensitive application code (e.g., methods in a class).
All access control decisions are mediated by a security manager. By default,
the security manager uses the AccessController class for access control
operations and decisions.

_Secure communication_ ensures that the data which travels across a network is
sent to the appropriate party, without being modified during the transmission.
Cryptography forms the basis for secure communication. The Java platform
provides API support for standard secure communication protocols like SSL/TLS.
HTTPS, or “HTTP secure”, is an application-specific implementation that is a
combination of HTTP and SSL/TLS.

###  2.2. Java EE Security

Java EE is an standard specification for enterprise Java extensions (jee, [n.
d.]). Various application servers are built to implement this specification,
such as JBoss or WildFly (wil, [n. d.]), Glassfish (gla, [n. d.]), WebSphere
(web, [n. d.]b), and WebLogic (web, [n. d.]a). A Java EE application consists
of components deployed into various containers. The Java EE security
specification defines that containers secure components by supporting features
like authentication and authorization.

In particular, authentication defines how communicating entities, such as a
client and a server, prove to each other that they are who they say they are.
An authenticated user is issued a _credential_ , which includes user
information like usernames/passwords or tokens. Authorization ensures that
users have permissions to perform operations or access data. When accessing
certain resource, a user is authorized if the server can map this user to a
security role permitted for the resource.

Security for Java EE applications can be implemented in the following two
ways:

  * •

Declarative Security expresses an application component’s security
requirements using either deployment descriptors or annotations. A deployment
descriptor is an XML file external to the application. This XML file expresses
an application’s security structure, including security roles, access control,
and authentication requirements. Annotations are used to specify security
information in a class file. They can be either used by or overridden by
deployment descriptors.

  * •

Programmatic Security is embedded in an application and is used to make
security decisions, when declarative security alone is not sufficient to
express the security model.

###  2.3. Other Third-Party Frameworks

Several frameworks were built to provide authentication, authorization, and
other security features for enterprise applications, such as Spring Security
(spr, [n. d.]c). Different from the Java EE security APIs, these frameworks
are container independent, meaning that they do not require containers to
implement security. For example, Spring security is installed as a single
Filter in the filter chain inside a container to handle requests. There can be
multiple security filters inside Spring security. Developers can configure
security in an XML-based way, a Java-based way, or a hybrid of the two.
Similar to Java EE security, the XML-based way implements security
requirements with deployment descriptors and source code, while the Java-based
way expresses security with annotations and code.

##  3\. Methodology

We leveraged Scrapy—an open source python library (scr, [n. d.]) to crawl
posts from the StackOverflow website. Figure 1 presents the format of a
typical StackOverflow post. Each post mainly contains two regions: the
question and answers.

① Question region contains the question description and some metadata. The
metadata includes a vote for the question (e.g., 3)—indicating whether the
question is well-defined or well-representative, and a favorite count (e.g.,
1)—showing how many people liking the question.

② Answer region contains all answer(s) provided. When one or more answers are
provided, the asker decides which answer to accept, and marks it with (✓).

Figure 1. A highly viewed post asking about workarounds to bypass key checking
and allow all host names for HTTPS (pos, [n. d.])

We obtained 22,195 posts containing keywords “java” and “security”. After
extracting the question, the answers, and relevant metadata for each post, we
refined the data in three ways.

_1) Filtering less useful posts._ We automatically refined posts by removing
duplicated posts, posts without accepted answers, and posts whose questions
received negative votes perhaps because the questions were ill-formed or
confusing.

_2) Removing posts without code snippets._ We only focused on posts containing
code snippets to better understand the questions within the program context.
Since our crawled data did not include any metadata to describe the existence
of code snippets, we developed an intuitive filter to search for keywords
“public” and “class” in each post. Based on our observation, a post usually
contains these two keywords when it includes a code snippet.

_3) Discarding irrelevant posts._ After applying the above two filters, we
manually examined the remaining posts, and decided whether they were relevant
to Java secure coding or simply contained the checked keywords accidentally.

With the above three filters, we finally included 497 posts in our data set.
The question asking time of these posts were during 2008-2016. We did not
include the posts in 2017, because at the time we conducted experiments, there
was only data for the first several months of 2017. When manually filtering
retrieved posts, we also characterized relevant posts based on their _security
concerns_ , _programming challenges_ , and _security vulnerabilities_. Based
on the characterization, we classified posts and investigated the following
three research questions (RQs):

Figure 2. Taxonomy of StackOverflow posts

##### RQ1: What are the common security concerns of developers?

We aimed to investigate: (1) what are the popular security features that
developers frequently asked about, and (2) how do developers’ security
concerns shift over the years? Besides, we also classified posts into three
categories based on the number of positive votes and favorite counts their
questions received:

  * •

Neutral: A question does not receive a positive vote or favorite count.

  * •

Positive: A question receives at least one positive vote but zero favorite
count.

  * •

Favorite: A question receives at least one favorite vote.

The post shown in Figure 1 is classified as “Favorite” in this way, because
its favorite count is one. By combining this category with the identified
security concerns, we explore developers’ sentiment towards questions related
to different concerns. It is possible that although some security features are
frequently asked, people do not like the questions, probably because the
questions are so complicated and project-specific that most developers cannot
learn or benefit from them.

##### RQ2: What are the common programming challenges?

For each identified security concern, we further characterized each post with
the problem (buggy source code, wrongly implemented configuration files,
improperly configured execution environment), the root cause and accepted
solution of the problem. Then we clustered posts if they had similar
characterizations. For the post in Figure 1, we identified the problem as
asking for a workaround in SSL verification, because apparently the developer
did not realize that the SSL verification should not be bypassed. The
recommended solution was to first create a keystore that contains the
certificates of all trusted SSL servers, and then use the keystore to create a
TrustManagerFactory instance and establish connections.

##### RQ3: What are the common security vulnerabilities?

For each post, we also inspected unaccepted answers and the conversational
comments between the question asker and other developers, in order to learn
about the security context. Based on the recommended security coding practice
and the investigated security context, we decided whether the accepted
solution was security vulnerable. The post shown in Figure 1 contains a secure
accepted answer, although the question asker originally asked for a vulnerable
implementation as an easy fix.

##  4\. Major Findings

We present our investigation results for the research questions separately in
Section 4.1-4.3.

###  4.1. Common Concerns in Security Coding

Figure 2 presents our classification hierarchy among the 497 posts. At the
highest level of the hierarchy, we created two categories: implementation
questions vs. understanding questions. The majority—472 questions—were about
implementing security functionalities or solving program errors. Only 25
questions were asked to understand why certain features were designed in
certain ways (e.g., how does Java string being immutable increase security
(152, [n. d.])). Since our focus is on secure coding practice, our further
classification expands on the 472 implementation-relevant posts.

At the second level of the classification hierarchy, we clustered posts based
on the _major security platforms or frameworks_ involved in each post. For
instance, Java platform security posts were relevant to the security features
of the Java platform and related software libraries extending the features
(e.g., BouncyCastle (bc, [n. d.])). Java EE security posts were related to the
security mechanisms of Java EE platform, and Spring security posts were about
the Spring security framework (spr, [n. d.]c). The Other category at this
level includes posts relevant to other libraries or platforms, such as Shiro
(304, [n. d.]) and Android (412, [n. d.]). _Unexpectedly, Spring security
posts (261) counted for 55% of the implementation questions_. However, no
research exists to explore the misuse of Spring security APIs. Although there
are many application servers developed to implement the Java EE
specifications, developers have many fewer questions concerning Java EE
security than Spring security.

At the third level of the classification hierarchy, we further classified
posts separately belonging to the two categories: Java platform security and
Spring security, because both categories contained many posts. Among the Java
platform security posts, in addition to cryptography and secure communication,
we identified a third major concern—access control. Among the Spring security
posts, we found the majority (219) related to authentication, with the
minority discussing authorization and configuration.

Finding 1: _55%, 30%, and 12% of the implementation-relevant posts focused on
Spring security, Java platform security, and Java EE security, indicating that
developers need more help to secure Java enterprise applications._

Based on the second- and third-level classifications, we identified seven
major security concerns: cryptography, access control, secure communication,
Java EE security, authentication, authorization, and configuration. The first
three concerns correspond to Java platform security, while the last three
correspond to Spring security. To reveal developers’ security concern trends
over the years, we clustered posts based on the year when each question was
asked.

Figure 3. The post distribution during 2008-2016

Figure 3 presents the post distribution among 2008-2016. The total number of
posts increased over the years, indicating that more developers were involved
with secure coding and faced problems. Specifically, there was only 1 post
created in 2008, but 107 posts were created in 2016. During 2009-2011, most
posts were about Java platform security. However, since 2012, the major
security concern has shifted to securing Java enterprise applications
(including both Java EE security and Spring security). Specifically, Spring
security has taken up over 50% of the posts published every year since 2013.

Figure 4. The post distribution among developers’ sentiment towards the
security features: neutral, positive, and favorite

For each security concern, we also clustered posts based on developers’
attitudes towards the questions. As mentioned in Section 3, we defined three
types of sentiment: _neutral_ , _positive_ , and _favorite_. Figure 4 shows
the post distribution among different developers’ attitudes. In this figure,
configuration posts received the highest percentage of neutral opinions (50%).
One possible reason is that these posts mainly focused on the problems caused
by wrong versions of software libraries and version conflicts between
dependent libraries. Since such problems are usually specific to programmers’
software development environments, they are not representative or relevant to
many developers’ security interests. In comparison, secure communication posts
received the lowest percentage of neutral opinions (16%), but the highest
percentage of favorite (61%), indicating that the questions were more
representative, focusing more on security implementation instead of
environment settings.

Finding 2: _Developers’ major security concern has shifted from Java platform
security to enterprise application security over the years, especially to
Spring security. Compared with others, secure communication posts received the
highest percentage (61%) of favorite votes, indicating that the questions are
important and representative._

###  4.2. Common Programming Challenges

To understand the common challenges developers faced, we further examined the
posts of the most popular five major categories: authentication (219),
cryptography (64), Java EE security (58), access control (43), and secure
communication (31). We identified posts with similar questions and related
answers, and further investigated why developers asked these common questions.
This section presents our key findings for each category.

####  4.2.1. Authentication

Most posts were on (1) integrating Spring security with different application
servers (e.g., JBoss) (spr, [n. d.]g) or frameworks (e.g., Spring MVC) (sec,
[n. d.]b), (2) configuring security in an XML-based (spr, [n. d.]d) or Java-
based way (spr, [n. d.]a), or (3) converting XML-based configurations to Java-
based ones (xml, [n. d.]). Specifically, we observed three challenges.

_Challenge 1: The way to integrate Spring security with different types of
applications varies a lot._ Although Spring security can be leveraged to
secure various applications, the usage varies with the application settings
(spr, [n. d.]f). What is even worse, some Spring security-relevant
implementations may exhibit different dynamic behaviors in different
applications. For instance, by following a standard tutorial example (spr, [n.
d.]h), a developer defined two custom authentication
filters—apiAuthenticationFilter and webAuthenticationFilter—to secure two
different sets of URLs of his/her Spring Boot web application as shown below.

Listing 1: An exemplar implementation working unexpectedly in Spring Boot
applications

⬇

1@EnableWebSecurity

2public class SecurityConfiguration {

3 @Configuration @Order(1)

4 public static class ApiConfigurationAdapter

5 extends WebSecurityConfigurerAdapter {

6 @Bean

7 public GenericFilterBean

8 apiAuthenticationFilter() {…}

9 @Override

10 protected void configure(HttpSecurity http)

11 throws Exception {

12 http.antMatcher(”/api/**”)

13 .addFilterAfter(apiAuthenticationFilter()…)

14 .sessionManagement()…; } }

15 @Configuration @Order(2)

16 public static class WebSecurityConfiguration

17 extends WebSecurityConfigurerAdapter {

18 @Bean

19 public GenericFilterBean

20 webAuthenticationFilter() {…}

21 @Override

22 protected void configure(HttpSecurity http)

23 throws Exception {

24 http.antMatcher(”/”)

25 .addFilterAfter(webAuthenticationFilter()…)

26 .authorizeRequests()…; } } }

In Listing 1, lines 3-14 correspond to ApiConfigurationAdapter, a security
configuration class that specifies apiAuthenticationFilter to authenticate
URLs matching the pattern “/api/**”. Lines 15-26 correspond to
WebSecurityConfiguration, which configures webAuthenticationFilter to
authenticate the other URLs. Ideally, only one filter is invoked given one
URL. However, both filters were invoked in reality. The root cause is that
each filter is a bean (annotated with @Bean on lines 6 and 18). Spring Boot
detects the filters and adds them to a regular filter chain, while Spring
security also adds them to its own filter chain. Consequently, both filters
are registered twice and can be invoked twice. To solve the problem,
developers need to enforce each bean to be registered _only once_ by adding
specialized code.

_Challenge 2: The two ways of security configurations (Java-based and XML-
based) are hard to implement correctly._ Take the Java-based configuration for
example. There are lots of annotations and APIs of classes, methods, and
fields available to specify different configuration options. Particularly,
HttpSecurity has 10 methods, each of which can be invoked on an HttpSecurity
instance and then produces another HttpSecurity object. If developers are not
careful about the invocation order between these methods, they can get errors
(sec, [n. d.]a). As shown in Listing 1, the method antMatcher("/api/**’’) must
be invoked before addFilterAfter(...) (lines 12-13), so that the filter is
only applied to URLs matching the pattern “/api/**”. Unfortunately, such
implicit constraints are not documented in the API specifications (spr, [n.
d.]b).

_Challenge 3: Converting from XML-based to Java-based configurations is
tedious and error-prone._ The semantic conflicts between annotations,
deployment descriptors, and code implementations are always hard to locate and
resolve. Such problems become more serious when developers configure security
in a hybrid way of Java-based and XML-based. Since Spring security 3.2,
developers are supported to configure Spring-security in a pure Java-based
approach, and there is documentation describing how to migrate from XML-based
to Java-based configurations (spr, [n. d.]e). However, manually applying every
migration rule to convert every configuration file is tedious and error-prone.

Finding 3: _Spring security authentication posts were mainly about configuring
security for different applications or in different ways (Java-based or XML-
based), and converting between these ways. The challenges were due to
incomplete documentation and missing tool support for error checking, solution
recommendation, and configuration generation._

####  4.2.2. Cryptography

Many posts were about key generation and usage. For instance, some posts
discussed how to create a key from scratch (key, [n. d.]i), or how to generate
or retrieve a key from a random number (key, [n. d.]h), a byte array (key, [n.
d.]e), a string (key, [n. d.]f), a certificate (key, [n. d.]g), BigIntegers
(key, [n. d.]c), a keystore (key, [n. d.]b), or a file (key, [n. d.]l). Some
other posts focused on how to compare keys (key, [n. d.]d), print key
information (key, [n. d.]k), or initialize a cipher for encryption and
decryption (key, [n. d.]j). Specifically, we observed three common challenges
of correctly using the cryptography APIs.

_Challenge 1: The error messages did not provide sufficient useful hints about
fixes._ We found five posts concentrated on the same problem: “get
InvalidKeyException: Illegal key size”, while the solutions were almost
identical: (1) download the “Java Cryptography Extension (JCE) Unlimited
Strength Jurisdiction Policy Files”, “local_policy.jar”, and
“US_export_policy.jar”; and (2) place the policy files in proper folders (key,
[n. d.]a). Developers got the same exception because of missing either of the
two steps. Providing a checklist of these necessary steps in the error message
could help developers quickly resolve the problem. However, the existing error
messages did not provide any constructive suggestion.

_Challenge 2: It is difficult to implement security with multiple programming
languages._ Three posts were about encrypting data with one language (e.g. PHP
or Python) and decrypting data with another language (e.g., Java). Such cross-
language data encryption & decryption is challenging, because the format of
the generated data by one language requires special handling of another
language. Listing 2 is an example to generate an RSA key pair and encrypt data
in PHP, and to decrypt data in Java (com, [n. d.]).

Listing 2: Encryption in PHP and decryption in Java

⬇

1// ***** keypair.php *****

2if(file_exists(’private.key’)) {

3 echo file_get_contents(’private.key’); }

4else {

5 include(’Crypt/RSA.php’);

6 $rsa = new Crypt_RSA();

7 $res = $rsa->createKey();

8 $privateKey = $res[’privatekey’];

9 $publicKey = $res[’publickey’];

10 file_put_contents(’public.key’,$publicKey);

11 file_put_contents(’private.key’,$privateKey); }

12// ***** encrypt.php *****

13include(’Crypt/RSA.php’);

14$rsa = new Crypt_RSA();

15$rsa->setEncryptionMode(CRYPT_RSA_ENCRYPTION_OAEP);

16$rsa->loadKey(file_get_contents(’public.key’));

17// ***** MainClass.java *****

18BASE64Decoder decoder=new BASE64Decoder();

19String b64PrivateKey=getContents(

20 ”http://localhost/api/keypair.php”).trim();

21byte[] decodedKey=decoder.decodeBuffer(b64PrivateKey);

22BufferedReader br=new BufferedReader(

23 new StringReader(new String(decodedKey)));

24PEMReader pr=new PEMReader(br);

25KeyPair kp=(KeyPair)pr.readObject();

26pr.close();

27PrivateKey privateKey=kp.getPrivate();

28Cipher cipher=Cipher.getInstance(

29 ”RSA/None/OAEPWithSHA1AndMGF1Padding”,”BC”);

30cipher.init(Cipher.DECRYPT_MODE, privateKey);

31byte[] plaintext=cipher.doFinal(cipher);

In this example, when a key pair is generated in PHP (lines 2-11), the public
key is easy to retrieve in PHP (lines 13-16). However, retrieving the private
key in Java is more complicated (lines 18-30). After reading in the private
key string (lines 19-20), the Java implementation first uses Base64Decoder to
decode the string into a byte array (line 21), which corresponds to an OpenSSL
PEM encoded stream (line 22-23). Because OpenSSL PEM is not a standard data
format, the Java code further uses a PEMReader to convert the stream to a
PrivateKey instance (lines 24-27) before using the key to initialize a cipher
(lines 28-30). Existing documentation seldom describes how the security data
format (e.g., key) defined in one language corresponds to that of another
language. Unless developers are experts in both languages, it is hard for them
to figure out the security data processing across languages.

_Challenge 3: Implicit constraints on API usage cause confusion._ Two posts
were about getting “InvalidKeySpecException: algid parse error, not a
sequence”, when obtaining a private key from a file (pkc, [n. d.]). The
problem is that the key should be in PKCS#8 format when used to create a
PKCS8EncodedKeySpec instance, as shown below:

Listing 3: Consistency between the key format and keyspec

⬇

1//privKey should be in PKCS#8 format

2byte[] privKey=…;

3PKCS8EncodedKeySpec keySpec=

4 new PKCS8EncodedKeySpec(privKey);

The tricky part here is that a private key retrieved from a file always has
the data type byte[] even if it is not in PKCS#8 format. If developers invoke
the API PKCS8EncodedKeySpec(...) with a non-PKCS#8 formatted key, they will be
stuck with the clueless exception. Three solutions were suggested to get a
PKCS#8 format key: (1) to implement code to convert the byte array, (2) to use
an openssl command to convert the file format, or (3) to use the PEMReader
class of BouncyCastle to generate a key from the file. Such implicit
constraints between an API and its input format are delicate.

Finding 4: _The cryptography posts were majorly about key generation and
usage. Developers asked these questions mainly due to clueless error messages,
cross-language data handling, and implicit API usage constraints._

####  4.2.3. Java EE security

33 of the 58 posts were on authentication and authorization. However, the APIs
of these two security features were defined differently on different
application servers (e.g., WildFly and Glassfish), and developers might use
these servers in combination with diverse third-party libraries (jav, [n.
d.]). As a result, the posts seldom shared common solutions or code
implementation.

One common challenge we identified is the usage of declarative security and
programmatic security. When developers misunderstood annotations, they could
use incorrect annotations that conflict with other annotations (con, [n.
d.]b), deployment descriptors (con, [n. d.]d), code implementation (con, [n.
d.]a), or file paths (con, [n. d.]c). Nevertheless, existing error reporting
systems only throw exceptions. Unfortunately, there is no tool support that
prevents developers from configuring such conflicting settings, or assists
developers with diagnosing conflicting usage of annotations and deployment
descriptors.

Finding 5: _Java EE security posts were mainly about authentication and
authorization. One challenge is the complex usage of declarative security and
programmatic security, and any complicated interaction between the two._

####  4.2.4. Access Control

The 43 posts mainly discussed how to _restrict_ or _relax_ the access
permission(s) of a software application for certain resource(s).

Specifically, 21 questions asked about restricting untrusted code from
accessing certain packages (lim, [n. d.]b), classes (lim, [n. d.]c), or class
members (i.e., methods and fields) (lim, [n. d.]a). Two alternative solutions
were commonly suggested for these questions: (1) to override the checkXXX()
methods of SecurityManager to disallow invalid accesses, or (2) to define a
custom policy file to grant limited permissions. Another nine posts were on
how to allow applets to perform privileged operations (all, [n. d.]), because
applets are executed in a security sandbox by default and can only perform a
set of safe operations. One commonly recommended solution was to digitally
sign the applet. Although it seems that there exist common solutions to the
most frequently asked questions, the access control implementation is not
always intuitive. We identified two common challenges of correctly
implementing access control.

_Challenge 1: The effect of access control varies with the program context._
We identified two typical scenarios from multiple similar posts. First, the
RMI tutorial (rmi, [n. d.]a) suggested that a security manager is needed
_only_ when RMI code downloads code from a remote machine. Including a
SecurityManager instance in the RMI program which does not download any code
can cause an AccessControlException (rmi, [n. d.]b). Second, although a signed
applet is allowed to perform sensitive operations, it loses its privileges
when invoked from Javascript (app, [n. d.]). As a result, the invocation to
the signed applet should be wrapped with an invocation of AccessController.
doPrivileged(...).

_Challenge 2: The effect of access control varies with the execution
environment._ SecurityManager can disallow illegal accesses via reflection
only when the program is executed in a controlled environment (i.e., on a
trusted server) (ref, [n. d.]). Nevertheless, if the program is executed in an
uncontrolled environment (e.g. on an untrusted client machine) and hackers can
control how to run the program or manipulate the jar file, the security
mechanisms become voided.

Finding 6: _The access control posts were mainly about SecurityManager,
AccessController, and the policy file. Configuring and customizing access
control policies are challenging._

####  4.2.5. Secure Communication

Among the 31 examined posts, 22 posts were about SSL/TLS-related issues,
discussing how to create (cer, [n. d.]a), install (cer, [n. d.]c), find (ssl,
[n. d.]b), or validate an SSL certificate (cer, [n. d.]b), how to establish a
secure connection (est, [n. d.]), and how to use SSL together with other
libraries, such as JNDI (ssl, [n. d.]a) and PowerMock (ssl, [n. d.]f).

In particular, six posts focused on solving the problem of unable to find a
valid server certificate to establish an SSL connection with a server (ssl,
[n. d.]b). Instead of suggesting a way to install the required certificates,
two accepted answers suggested a highly insecure workaround to disable the SSL
verification process, so that any incoming certificate can pass the validation
(ssl, [n. d.]d). Although such workarounds can effectively remove the error,
they essentially fail the requirement to secure communication with SSL. In
Section 4.3, we will further explain the security vulnerability due to such
workarounds. Probably developers tended to accept the vulnerable answers
because they felt it challenging to implement the whole process of creating,
installing, finding, and validating an SSL certificate.

Finding 7: _Security communication posts mainly discussed the process of
establishing SSL/TLS connections. This process contains so many steps that
developers were tempted to accept a broken solution to simply bypass the
security check._

###  4.3. Common Problems from Security Perspectives

Among the five categories listed in Section 4.2, we identified security
vulnerabilities in the accepted answers of three frequently discussed topics:
Spring security’s csrf(), SSL/TLS, and password hashing.

####  4.3.1. Spring security’s csrf()

Cross-site request forgery (CSRF) is a serious attack that tricks a web
browser into executing an unwanted action (e.g., transfer money to another
account) in a web application (e.g., a bank website) for which a user is
authenticated (Zeller and Felten, [n. d.]). The root cause is that attackers
created forged requests that appear to be legitimate requests, and somehow
mixed them with the legitimate ones. Since the application cannot distinguish
between the two types of requests, it normally responds to the forged
requests, performing undesired operations.

By default, Spring security provides CSRF protection by defining a function
csrf() and implicitly enabling the function invocation. Correspondingly,
developers should include the CSRF token in all PATCH, POST, PUT, and DELETE
methods to leverage the protection (csr, [n. d.]a). However, among the 12
examined posts that were relevant to csrf(), 5 posts discussed program
failures, while all the accepted answers suggested an insecure solution:
disabling the CSRF protection by invoking http.csrf().disable(). In one
instance, after accepting the vulnerable solution, an asker commented as “
_Adding csrf().disable() solved the issue!!! I have no idea why it was enabled
by default_ ” (csr, [n. d.]b). Unfortunately, the developer happily disabled
the security protection without realizing that such workaround would expose
the resulting system to CSRF security exploits.

Finding 8: _In 5 of the 12 csrf()-relevant posts, developers took the
suggestion to irresponsibly disable the default CSRF protection. Developers
are unaware of the security consequences of their insecure coding._

####  4.3.2. SSL/TLS

We examined 11 posts discussing the usage of SSL/TLS, and observed two
important security issues.

Figure 5. Simplified overview of creating an SSL connection

_Problem 1: Developers commonly trusted all SSL certificates and allowed all
hostnames in order to quickly build a prototype in the development
environment._ SSL is the standard security technology for establishing an
encrypted connection between a web server and a browser. Figure 5 overviews
the major steps of establishing an SSL connection (rfs, [n. d.]). To activate
SSL on the server, developers need to provide all identity information of the
website (e.g., the host name) to a Certification Authority (CA) and request
for an SSL certificate (Step ①). After validating the website’s information,
CA issues a digitally signed SSL certificate (Step ②). When a client or
browser attempts to connect to the website ((Step ③), the server sends over
its certificate (Step ④). The client then conducts several checks, including
(1) whether the certificate is issued by a CA the browser trusts, and (2)
whether the request hostname matches the hostname associated with the
certificate (Step ⑤). If all these checks are passed, the SSL connection can
be established successfully.

Although ideally, developers should only enable SSL after obtaining a
certificate from CA, in reality, they usually implement and test the
certificate verification code before obtaining the certificate. Therefore, a
well-accepted recommended solution without CA-signed certificates is to create
a self-signed certificate and use the certificate to drive the implementation
of SSL certificate verification (cer, [n. d.]a). However, 9 of the 11 examined
posts accepted an insecure solution to bypass security checks by trusting all
certificates and/or allowing all hostnames, as demonstrated by Listing 4.

Listing 4: A typical implementation to disable SSL certificate validation
(ssl, [n. d.]c)

⬇

1// Create a trust manager that does not validate certificate chains

2TrustManager[] trustAllCerts = new TrustManager[]{

3 new X509TrustManager() {

4 public java.security.cert.X509Certificate[] getAcceptedIssuers() {return
null;}

5 public void checkClientTrusted(…) {}

6 public void checkServerTrusted(…) {} }};

7// Install the all-trusting trust manager

8try {

9 SSLContext sc = SSLContext.getInstance(”SSL”);

10 sc.init(null, trustAllCerts, new java.security.SecureRandom());

11 HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

12} catch (Exception e) {}

13// Access an https URL without having the certificate in the

14// truststore

15try {

16 URL url=new URL(”https://hostname/index.html”);

17} catch (MalformedURLException e) {}

Disabling the SSL certificate validation process in a client can thoroughly
invalidate the secure communication protocol, leaving clients susceptible to
the man-in-the-middle (MITM) attack (Georgiev et al., 2012). Namely, by
secretly relaying and possibly altering the communication (e.g., through DNS
poisoning) between the client and server, attackers can trick the SSL-client
to instead connect to an attacker-controlled server (Georgiev et al., 2012).
Although the insecure coding practice was shown to induce the MITM attack in
2012 (Georgiev et al., 2012), there are three examined posts created after
2012 still discussing the bad practice. This indicates a significant gap
between security theory and coding practices. Some developers justified their
checking-bypass logic by saying “ _Because I needed a quick solution for
debugging purposes only. I would not use this in production due to the
security concerns …_ ” (ssl, [n. d.]e). However, as pointed by another user of
StackOverflow (ssl, [n. d.]e) and demonstrated by prior research (Georgiev et
al., 2012; Fahl et al., 2012), _a lot of these implementations find their way
into production, and have yielded radically insecure systems as a result_.

_Problem 2: Developers were unaware of the best usage of SSL/TLS._ TLS is
SSL’s successor. It is so different from SSL that the two protocols do not
interoperate. To maintain the backwards compatibility with SSL 3.0 and
interoperate with systems supporting SSL, most SSL/TLS implementations allow
for protocol version negotiation: if a client and a server cannot connect via
TLS, they will fall back to using the older protocol SSL 3.0. In 2014, M ller
et al. reported the POODLE attack which exploits the SSL 3.0 fallback (Möller
et al., 2014). Specifically, there is a design vulnerability in the way SSL
3.0 handles block cipher mode padding, which can be exploited by attackers to
decrypt encrypted messages. With the POODLE attack, a hacker can intentionally
trigger a TLS connection failure and force usage of SSL 3.0, allowing
decryption of encrypted messages.

Ever since 2014, researchers have recommended developers to disable SSL 3.0
support and configure systems to present the SSL 3.0 fallback. The US
government (NIST) mandates to ceasing usage of SSL in the protection of
Federal information (nis, [n. d.]). In reality, nevertheless, none of the 11
posts mentioned the POODLE attack. Both of the two examined posts created in
2016 were about SSL usage.

Finding 9: _9 of 11 SSL/TLS-relevant posts discussed insecure code to bypass
security checks. We observed two important security threats: (1) StackOverflow
contains a lot of obsolete and insecure coding practices; and (2) secure
programmers are unaware of the state-of-the-art security knowledge._

####  4.3.3. Password Hashing

We found six posts related to hashing passwords with MD5 or SHA-1 to store the
user credentials in a database. However, these hashing functions were found
insecure (Wang et al., 2004; Stevens et al., 2017). They are vulnerable to
offline dictionary attacks (dic, [n. d.]). After obtaining a password hash $H$
from a compromised database, a hacker can use brute-force methods to enumerate
a list of password guesses, until finding the password $P$ whose hash value is
$H$. By impersonating a valid user to login a server, the attacker can conduct
malicious behaviors. Researchers recommended key-stretching algorithms (e.g.,
PBKDF2, bcrypt, and scrypt) as the best practice for secure password hashing,
because these algorithms are specially crafted to slow down the hash
computation by orders of magnitude (Steven, 2017; Gackenheimer, 2013;
Boonkrong, 2012), which substantially increases the difficulty of dictionary
attacks.

Unfortunately, only three of the six posts (50%) mentioned the best practice
in the accepted answers, indicating that many posts on secure hashing
suggested insecure hash functions. We found one post which asked about using
MD5 hashing in Android (md5, [n. d.]). Within the comment conversation between
developers, although people recommended to avoid MD5, the asker kept
justifying his/her choice of MD5. The asker even shared a completely wrong
understanding of secure hashing: “ _The security of hash algorithms really is
MD5 (strongest) ¿ SHA-1 ¿ SHA-256 ¿ SHA-512 (weakest)_”, although the opposite
is true, which is MD5 ¡ SHA-1 ¡ SHA-256 ¡ SHA-512. Among these posts, some
developers misunderstood security APIs and ignored the security consequences
of their security API choices. Such StackOverflow posts can have profound
negative impact, because they convey the wrong information and may mislead
people.

Finding 10: _Three of six hashing-relevant posts accepted vulnerable solutions
as correct answers, indicating that developers were unaware of the best
practice of secure programming. Their wrong knowledge or practice can
propagate among StackOverflow users and negatively influence people._

##  5\. Related Work

This section describes related work on analyzing, detecting, and preventing
security vulnerabilities due to Java library misuse.

###  5.1. Analyzing Security Vulnerabilities

Prior studies showed that the API misuse of cryptography, SSL, and Java
reflection caused many security vulnerabilities (Long, 2005; Lazar et al.,
2014; ver, [n. d.]; Yang et al., 2016). For instance, Long identified several
Java features whose misuse or improper implementation can compromise security
(Long, 2005). One feature he identified is the Java reflection API which
enables fields that are not normally accessible to be accessed and thus can
cause potential vulnerabilities. Lazar et al. manually examined 269 published
cryptographic vulnerabilities in the CVE database, and observed 83% of them
were caused by the misuse of cryptographic libraries, including low encryption
strength, insufficient randomness, and inadequate checks (Lazar et al., 2014).
Veracode reported that 39% of all applications used broken or risky
cryptographic algorithms (ver, [n. d.]). The study by Yang et al. (Yang et
al., 2016) is most relevant to our research. They used an advanced topic model
approach, Latent Dirichlet Allocation (LDA) tuned using Genetic Algorithm
(GA), to cluster security-related StackOverflow questions based on the text.
They identified frequently mentioned security topics like “Password” and
“Hash” for categorization purposes. In comparison, we investigate the
programming challenges and security vulnerabilities among the topics. Our SE
and security findings have more technical depth.

###  5.2. Detecting Security Vulnerabilities

Approaches were built to detect security vulnerabilities caused by API misuse
(Fahl et al., 2012; Georgiev et al., 2012; Egele et al., 2013; Li et al.,
2014; Onwuzurike and De Cristofaro, 2015; He et al., 2015; Chatzikonstantinou
et al., 2016; Fischer et al., 2017). For instance, Egele et al. implemented a
static checker for six well defined Android cryptographic API usage rules,
such as “Do not use ECB mode for encryption”, and analyzed 11,748 Android
applications for any rule violation (Egele et al., 2013). They found 88% of
the applications violating at least one checked rule. Fischer et al. extracted
Android security-related code snippets from StackOverflow, and manually
labeled a subset of the data as “secure” or “insecure” (Fischer et al., 2017).
The labeled data allowed them to train a classifier and efficiently judge
whether a code snippet is secure or not for the whole data set. Next, they
searched for code clones of the snippets in 1.3 million Android apps, and
found many clones of the insecure code. Fahl et al. (Fahl et al., 2012) and
Georgiev et al. (Georgiev et al., 2012) separately implemented an attack
model: man-in-the-middle attack, and detected vulnerable Android applications
and popular software libraries which misused SSL APIs. Both research groups
observed that developers disabled certification validation for testing with
self-signed and/or trusted certificates. He et al. developed SSLINT, an
automatic static analysis tool, to identify the misuse of TLS/SSL APIs in
client-side applications (He et al., 2015).

Compared with prior research, our study has two new contributions. First, _our
scope is broader._ We report new challenges on secure coding practices, such
as complex security configurations in Spring security, poor error messages,
and multilingual programs. Second, _our investigation on the online forum
provides a new social and community perspective about secure coding_. The
unique insights cannot be discovered through analyzing code.

###  5.3. Preventing Security Vulnerabilities

Various techniques were proposed to prevent developers from implementing
vulnerable code and misusing APIs (Mettler et al., 2010; Dey and Weis, [n.
d.]; Mitchell et al., 1997; Datta et al., 2007; Smith and Dill, 2008; Erkök
and Matthews, 2008). For example, Mettler et al. designed Joe-E—a security-
oriented subset of Java—to support secure software development by removing any
encapsulation-breaking features from Java (e.g., reflection), and by enforcing
the least privilege principle (i.e., by default, each Joe-E object has no
privilege to access system resources, unless another entity passes it a
reference to a system resource object) (Mettler et al., 2010). Keyczar is a
library designed to simplify the usage of cryptography, and thus to prevent
API misuse (Dey and Weis, [n. d.]). Below shows how Keyczar APIs are used to
decrypt data:

Listing 5: Simple decryption with Keyczar APIs

⬇

1Crypter crypter=new Crypter(”/rsakeys”);

2String plaintext=crypter.decrypt(ciphertext);

Compared with the decryption code shown in Listing 2 (lines 18-31), this
implementation is much simpler and more intuitive. All details about data
format conversion and cipher initialization are hidden, while a default strong
block cipher is used to properly decrypt data.

Some approaches were developed to apply formal verification techniques and
analyze the security properties of cryptographic protocol specifications
(Mitchell et al., 1997; Datta et al., 2007) and cryptographic API
implementations (Smith and Dill, 2008; Erkök and Matthews, 2008). For
instance, Protocol Composition Logic (PCL) is a logic for proving security
properties, like network protocols that use public and symmetric key
cryptography (Datta et al., 2007). The logic is designed around a process
calculus with actions for possible protocol steps including generating new
random numbers, sending and receiving messages, and performing decryption and
digital signature verification actions. The proof system consists of axioms
about individual protocol actions and inference rules that yield assertions
about protocols composed of multiple steps.

##  6\. Our Recommendations

By analyzing the StackOverflow posts relevant to Java security from both
software engineering and security perspectives, we observed the gap between
the intended usage of APIs and the actual problematic API usage by developers,
sensed developers’ frustration when they spent tremendous time figuring out
the correct usage of APIs (e.g., two weeks as mentioned in (sec, [n. d.]b)),
and observed terrible security consequences of library misuse. Below are our
recommendations based on the analysis.

##### For Security Developers

Conduct security testing to check whether the implemented features work as
expected. Do not disable security checks (e.g., SSL certificate validation) to
implement a temporary workaround in the testing or development environment. Be
cautious when following the StackOverflow accepted answers to implement secure
code, because these solutions may be unsafe and outdated. For administrators
of StackOverflow, we recommend them to carefully handle the posts that suggest
vulnerable code, because these posts can play an influential negative role
when educating security programmers.

##### For Library Designers

Remove or deprecate the APIs whose security protection is broken (e.g., MD5).
Design clean and helpful error reporting interfaces which show not only the
error, but also the possible root causes and solutions. Design simplified APIs
with strong security defenses implemented by default.

##### For Tool Builders

Develop automatic tools to diagnose security errors, locate buggy code, and
suggest security patches or solutions. Build vulnerability prevention
techniques that compare peer applications that use the same set of APIs to
infer and warn potential misuses. Explore approaches that check and enforce
the semantic consistency between security-relevant annotations, code, and
configurations. Build new approaches to transform between the implementations
of declarative security and programmatic security.

##  7\. Threats to Validity

This study is mainly based on our manual inspection of Java security-relevant
posts, so the observations may be subject to human bias. To alleviate the
problem, the first author of the paper carefully inspected all posts relevant
to implementation questions multiple times, while the second author also
examined the posts related to security vulnerabilities (mentioned in Section
4.3) multiple times.

To remove posts without code snippets, we defined a filter to search for
keywords “public” and “class”. If a post does not contain both words, the
filter automatically removes the post from our data set. This filter may
incorrectly remove some relevant posts that contain code. In future, we will
improve our crawling technique to keep the ¡code¿ tags around code snippets in
the raw data, and then rely on these tags to filter posts more precisely.

We conservatively mentioned posts whose accepted answers will cause security
vulnerabilities, although there might be more accepted answers that suffer
from known security attacks. Due to the limited available program and
environment information in each post, and our limited knowledge about
frameworks and potential security attacks, we decided not to mention the
suspicious posts whose accepted answers might lead to security
vulnerabilities.

##  8\. conclusion

Our work aimed at assessing the current secure coding practices, and
identifying potential gaps between theory and practice and between
specification and implementation. Our analysis of hundreds of posts on the
popular developer forum (StackOverflow) revealed a worrisome reality in the
software development industry.

  * •

A substantial number of developers do not appear to understand the security
implications of coding options, showing a lack of cybersecurity training. This
situation creates frustration in developers, who sometimes end up choosing
completely insecure-but-easy fixes. Examples of such easy fixes include using
obsolete cryptographic hash functions, disabling cross-site request forgery
protection, trusting all certificates in HTTPS verification, or using obsolete
communication protocols. These poor coding practices, if used in production
code, will seriously compromise the security of software products.

  * •

We provided substantial empirical evidences showing that APIs in Spring
security (designed for enterprise security applications) are overly
complicated and poorly documented, and error reports from runtime systems
cause confusion. In addition, multi-language support for securing data is
rather weak. The multi-language situation is common in security applications,
as oftentimes the data is encrypted in one programming language (e.g., Python)
and decrypted in another (e.g., Java). These issues can seriously hinder
developers’ productivity, resulting in great frustration and confusion.

  * •

Interestingly, we found that the social dynamics among askers and responders
can impact people’s security choices. Some influential posts are not secure.
For example, we observed that in some cases an insecure suggestion by a user
with a high reputation score was selected as the accepted answer, as opposed
to the correct fix by a user with a lower reputation score (rep, [n. d.]).
Sometimes insecure answers have many positive StackOverflow votes (as the
quick fixes indeed make error messages go away) (ssl, [n. d.]c), which is
quite misleading.

We described several possible solutions to improve secure coding practices in
the paper. However, efforts (e.g., workforce retraining) to correct these
alarming security issues may take a while to take effect. Our future work is
on building automatic or semi-automatic security bug detection and fixing
tools.

## References

  * (1)
  * key ([n. d.]a) [n. d.]a.  AES-256 implementation in GAE.  https://stackoverflow.com/questions/12833826/aes-256-implementation-in-gae. ([n. d.]).
  * asr ([n. d.]) [n. d.].  Apache Shiro Documentation.  https://shiro.apache.org/documentation.html. ([n. d.]).
  * web ([n. d.]a) [n. d.]a.  Application Server - Oracle WebLogic Server.  https://www.oracle.com/middleware/weblogic/index.html. ([n. d.]).
  * 304 ([n. d.]) [n. d.].  authc filter is not calling MyRealm in shiro with spring.  https://stackoverflow.com/questions/30463057/authc-filter-is-not-calling-myrealm-in-shiro-with-spring. ([n. d.]).
  * key ([n. d.]b) [n. d.]b.  Basic Program for encrypt/Decrypt : javax.crypto.BadPaddingException: Decryption error.  https://stackoverflow.com/questions/39518979/basic-program-for-encrypt-decrypt-javax-crypto-badpaddingexception-decryption. ([n. d.]).
  * key ([n. d.]c) [n. d.]c.  BigInteger to Key.  https://stackoverflow.com/questions/10271164/biginteger-to-key. ([n. d.]).
  * bc ([n. d.]) [n. d.].  Bouncy Castle.  https://www.bouncycastle.org. ([n. d.]).
  * ref ([n. d.]) [n. d.].  Can a secret be hidden in a ’safe’ java class offering access credentials?  https://stackoverflow.com/questions/5761519/can-a-secret-be-hidden-in-a-safe-java-class-offering-access-credentials. ([n. d.]).
  * key ([n. d.]d) [n. d.]d.  Compare two Public Key values in java [duplicate].  https://stackoverflow.com/questions/37439695/compare-two-public-key-values-in-java. ([n. d.]).
  * xml ([n. d.]) [n. d.].  Configure Spring Security without XML in Spring 4.  https://stackoverflow.com/questions/20961600/configure-spring-security-without-xml-in-spring-4. ([n. d.]).
  * con ([n. d.]a) [n. d.]a.  @Context injection in Stateless EJB used by JAX-RS.  https://stackoverflow.com/questions/29132547/context-injection-in-stateless-ejb-used-by-jax-rs. ([n. d.]).
  * key ([n. d.]e) [n. d.]e.  Converted secret key into bytes, how to convert it back to secrect key?  https://stackoverflow.com/questions/5364338/converted-secret-key-into-bytes-how-to-convert-it-back-to-secrect-key. ([n. d.]).
  * cwe ([n. d.]) [n. d.].  CWE-227: Improper Fulfillment of API Contract (’API Abuse’).  https://cwe.mitre.org/data/definitions/227.html. ([n. d.]).
  * dic ([n. d.]) [n. d.].  Dictionary Attacks 101.  https://blog.codinghorror.com/dictionary-attacks-101/. ([n. d.]).
  * key ([n. d.]f) [n. d.]f.  Edit code sample to specify DES key value.  EditcodesampletospecifyDESkeyvalue. ([n. d.]).
  * com ([n. d.]) [n. d.].  Encryption PHP, Decryption Java.  https://stackoverflow.com/questions/15639442/encryption-php-decryption-java. ([n. d.]).
  * key ([n. d.]g) [n. d.]g.  Get public and private key from ASN1 encrypted pem certificate.  https://stackoverflow.com/questions/30392114/get-public-and-private-key-from-asn1-encrypted-pem-certificate. ([n. d.]).
  * gla ([n. d.]) [n. d.].  GlassFish.  https://javaee.github.io/glassfish/. ([n. d.]).
  * nis ([n. d.]) [n. d.].  Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations.  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf. ([n. d.]).
  * lim ([n. d.]a) [n. d.]a.  Hiding my security key from java reflection.  https://stackoverflow.com/questions/14903318/hiding-my-security-key-from-java-reflection. ([n. d.]).
  * app ([n. d.]) [n. d.].  How can I get a signed Java Applet to perform privileged operations when called from unsigned Javascript?  https://stackoverflow.com/questions/1006674/how-can-i-get-a-signed-java-applet-to-perform-privileged-operations-when-called. ([n. d.]).
  * 152 ([n. d.]) [n. d.].  How does Java string being immutable increase security?  https://stackoverflow.com/questions/15274874/how-does-java-string-being-immutable-increase-security. ([n. d.]).
  * ssl ([n. d.]a) [n. d.]a.  how to accept self-signed certificates for JNDI/LDAP connections?  https://stackoverflow.com/questions/4615163/how-to-accept-self-signed-certificates-for-jndi-ldap-connections. ([n. d.]).
  * rep ([n. d.]) [n. d.].  How to add MD5 or SHA hash to spring security?  https://stackoverflow.com/questions/18581463/how-to-add-md5-or-sha-hash-to-spring-security. ([n. d.]).
  * sec ([n. d.]a) [n. d.]a.  How to apply spring security filter only on secured endpoints?  https://stackoverflow.com/questions/36795894/how-to-apply-spring-security-filter-only-on-secured-endpoints. ([n. d.]).
  * key ([n. d.]h) [n. d.]h.  How to generate secret key using SecureRandom.getInstanceStrong()?  https://stackoverflow.com/questions/37244064/how-to-generate-secret-key-using-securerandom-getinstancestrong. ([n. d.]).
  * spr ([n. d.]a) [n. d.]a.  How to override Spring Security default configuration in Spring Boot.  https://stackoverflow.com/questions/35600488/how-to-override-spring-security-default-configuration-in-spring-boot. ([n. d.]).
  * spr ([n. d.]b) [n. d.]b.  HttpSecurity (Spring Security 4.2.3.RELEASE API).  https://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/config/annotation/web/builders/HttpSecurity.html. ([n. d.]).
  * rmi ([n. d.]a) [n. d.]a.  Implementing a Remote Interface.  http://docs.oracle.com/javase/tutorial/rmi/implementing.html. ([n. d.]).
  * pkc ([n. d.]) [n. d.].  InvalidKeySpecException : algid parse error, not a sequence.  https://stackoverflow.com/questions/31941413/invalidkeyspecexception-algid-parse-error-not-a-sequence. ([n. d.]).
  * csr ([n. d.]a) [n. d.]a.  java - Simple example of Spring Security with Thymeleaf.  https://stackoverflow.com/questions/25692735/simple-example-of-spring-security-with-thymeleaf. ([n. d.]).
  * jaa ([n. d.]) [n. d.].  Java Authentication and Authorization Service (JAAS) Reference Guide.  https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html. ([n. d.]).
  * pos ([n. d.]) [n. d.].  java class to trust all for sending file to https web service.  https://stackoverflow.com/questions/21156929/java-class-to-trust-all-for-sending-file-to-https-web-service. ([n. d.]).
  * jca ([n. d.]) [n. d.].  Java Cryptography Architecture.  http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html. ([n. d.]).
  * con ([n. d.]b) [n. d.]b.  Java EE 7 EJB Security not working.  https://stackoverflow.com/questions/30504131/java-ee-7-ejb-security-not-working. ([n. d.]).
  * est ([n. d.]) [n. d.].  Java Mail get mails with pop3 from exchange server =¿ Exception in thread “main” javax.mail.MessagingException.  https://stackoverflow.com/questions/25017050/java-mail-get-mails-with-pop3-from-exchange-server-exception-in-thread-main. ([n. d.]).
  * rmi ([n. d.]b) [n. d.]b.  Java RMI / access denied.  https://stackoverflow.com/questions/36570012/java-rmi-access-denied. ([n. d.]).
  * key ([n. d.]i) [n. d.]i.  Java Security - RSA Public Key & Private Key Code Issue.  https://stackoverflow.com/questions/18757114/java-security-rsa-public-key-private-key-code-issue. ([n. d.]).
  * key ([n. d.]j) [n. d.]j.  Java security init Cipher from SecretKeySpec properly.  https://stackoverflow.com/questions/14230096/java-security-init-cipher-from-secretkeyspec-properly. ([n. d.]).
  * lim ([n. d.]b) [n. d.]b.  Java Security Manager completely disable reflection.  https://stackoverflow.com/questions/40218973/java-security-manager-completely-disable-reflection. ([n. d.]).
  * jSe ([n. d.]) [n. d.].  Java Security Overview.  http://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html. ([n. d.]).
  * lim ([n. d.]c) [n. d.]c.  Java security: Sandboxing plugins loaded via URLClassLoader.  https://stackoverflow.com/questions/3947558/java-security-sandboxing-plugins-loaded-via-urlclassloader. ([n. d.]).
  * ssl ([n. d.]b) [n. d.]b.  Java SSL - InstallCert recognizes certificate, but still “unable to find valid certification path” error?  https://stackoverflow.com/questions/11087121/java-ssl-installcert-recognizes-certificate-but-still-unable-to-find-valid-c. ([n. d.]).
  * jee ([n. d.]) [n. d.].  JSR-000366 Java Platform, Enterprise Edition 8 Public Review Specification.  http://download.oracle.com/otndocs/jcp/java_ee-8-pr-spec/. ([n. d.]).
  * csr ([n. d.]b) [n. d.]b.  logout call - Spring security logout call.  https://stackoverflow.com/questions/24530603/spring-security-logout-call. ([n. d.]).
  * md5 ([n. d.]) [n. d.].  MD5 hashing in Android.  https://stackoverflow.com/questions/4846484/md5-hashing-in-android. ([n. d.]).
  * con ([n. d.]c) [n. d.]c.  PicketLink / Deltaspike security does not work in SOAP (JAX-WS) layer (CDI vs EJB?).  https://stackoverflow.com/questions/32392702/picketlink-deltaspike-security-does-not-work-in-soap-jax-ws-layer-cdi-vs-ej. ([n. d.]).
  * jav ([n. d.]) [n. d.].  Resteasy Authorization design - check a user owns a resource.  https://stackoverflow.com/questions/34315838/resteasy-authorization-design-check-a-user-owns-a-resource. ([n. d.]).
  * rfs ([n. d.]) [n. d.].  RF 6101 - The Secure Sockets Layer (SSL) Protocol Version 3.0.  https://tools.ietf.org/html/rfc6101. ([n. d.]).
  * scr ([n. d.]) [n. d.].  Scrapy — A Fast and Powerful Scraping and Web Crawling Framework.  https://scrapy.org. ([n. d.]).
  * ssl ([n. d.]c) [n. d.]c.  security - Allowing Java to use an untrusted certificate for SSL/HTTPS connection.  https://stackoverflow.com/questions/1201048/allowing-java-to-use-an-untrusted-certificate-for-ssl-https-connection. ([n. d.]).
  * all ([n. d.]) [n. d.].  security exception when loading web image in jar.  https://stackoverflow.com/questions/2011407/security-exception-when-loading-web-image-in-jar. ([n. d.]).
  * spr ([n. d.]c) [n. d.]c.  Spring Security.  https://projects.spring.io/spring-security/. ([n. d.]).
  * sec ([n. d.]b) [n. d.]b.  Spring Security 4 xml configuration UserDetailsService authentication not working.  https://stackoverflow.com/questions/41321176/spring-security-4-xml-configuration-userdetailsservice-authentication-not-workin. ([n. d.]).
  * spr ([n. d.]d) [n. d.]d.  Spring security JDK based proxy issue while using @Secured annotation on Controller method.  https://stackoverflow.com/questions/35860442/spring-security-jdk-based-proxy-issue-while-using-secured-annotation-on-control. ([n. d.]).
  * spr ([n. d.]e) [n. d.]e.  Spring Security Reference.  http://docs.spring.io/spring-security/site/docs/3.2.4.RELEASE/reference/htmlsingle/#jc-httpsecurity. ([n. d.]).
  * spr ([n. d.]f) [n. d.]f.  Spring Security Tutorial.  http://www.mkyong.com/tutorials/spring-security-tutorials/. ([n. d.]).
  * spr ([n. d.]g) [n. d.]g.  Spring Security using JBoss ¡security-domain¿.  https://stackoverflow.com/questions/28172056/spring-security-using-jboss-security-domain. ([n. d.]).
  * cer ([n. d.]a) [n. d.]a.  SSL Certificate Verification : javax.net.ssl.SSLHandshakeException.  https://stackoverflow.com/questions/25079751/ssl-certificate-verification-javax-net-ssl-sslhandshakeexception. ([n. d.]).
  * ssl ([n. d.]d) [n. d.]d.  Ssl handshake fails with unable to find valid certification path to requested target.  https://stackoverflow.com/questions/40977556/ssl-handshake-fails-with-unable-to-find-valid-certification-path-to-requested-ta. ([n. d.]).
  * cer ([n. d.]b) [n. d.]b.  SSL Socket Connection working even though client is not sending certificate?  https://stackoverflow.com/questions/26761966/ssl-socket-connection-working-even-though-client-is-not-sending-certificate. ([n. d.]).
  * sta ([n. d.]) [n. d.].  StackOverflow.  https://stackoverflow.com. ([n. d.]).
  * ver ([n. d.]) [n. d.].  STATE OF SOFTWARE SECURITY.  https://www.veracode.com/sites/default/files/Resources/Reports/state-of-software-security-volume-7-veracode-report.pdf. ([n. d.]).
  * cer ([n. d.]c) [n. d.]c.  The Webserver I talk to updated its SSL cert and now my app can’t talk to it.  https://stackoverflow.com/questions/5758812/the-webserver-i-talk-to-updated-its-ssl-cert-and-now-my-app-cant-talk-to-it. ([n. d.]).
  * ssl ([n. d.]e) [n. d.]e.  Trusting all certificates using HttpClient over HTTPS.  https://stackoverflow.com/questions/2642777/trusting-all-certificates-using-httpclient-over-https. ([n. d.]).
  * key ([n. d.]k) [n. d.]k.  Use of ECC in Java SE 1.7.  https://stackoverflow.com/questions/24383637/use-of-ecc-in-java-se-1-7. ([n. d.]).
  * key ([n. d.]l) [n. d.]l.  Using public key from authorized_keys with Java security.  https://stackoverflow.com/questions/3531506/using-public-key-from-authorized-keys-with-java-security. ([n. d.]).
  * spr ([n. d.]h) [n. d.]h.  Web Security Samples.  https://github.com/spring-projects/spring-security-javaconfig/blob/master/samples-web.md#sample-multi-http-web-configuration. ([n. d.]).
  * web ([n. d.]b) [n. d.]b.  WebSphere Application Server - IBM.  http://www-03.ibm.com/software/products/en/appserv-was. ([n. d.]).
  * ssl ([n. d.]f) [n. d.]f.  When a TrustManagerFactory is not a TrustManagerFactory (Java).  https://stackoverflow.com/questions/14654639/when-a-trustmanagerfactory-is-not-a-trustmanagerfactory-java. ([n. d.]).
  * wil ([n. d.]) [n. d.].  WildFly.  http://wildfly.org. ([n. d.]).
  * con ([n. d.]d) [n. d.]d.  Wildfly 9 security domains won’t work.  https://stackoverflow.com/questions/37425056/wildfly-9-security-domains-wont-work. ([n. d.]).
  * 412 ([n. d.]) [n. d.].  Your implementation of PreferenceActivity is vulnerable to fragment injection.  https://stackoverflow.com/questions/41278592/your-implementation-of-preferenceactivity-is-vulnerable-to-fragment-injection. ([n. d.]).
  * Boonkrong (2012) Sirapat Boonkrong. 2012\.  Security of passwords.  Information Technology Journal 8, 2 (2012), 112–117.
  * Chatzikonstantinou et al. (2016) Alexia Chatzikonstantinou, Christoforos Ntantogian, Georgios Karopoulos, and Christos Xenakis. 2016\.  Evaluation of Cryptography Usage in Android Applications. In Proceedings of the 9th EAI International Conference on Bio-inspired Information and Communications Technologies (Formerly BIONETICS) (BICT’15). ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), ICST, Brussels, Belgium, Belgium, 83–90.  https://doi.org/10.4108/eai.3-12-2015.2262471
  * Datta et al. (2007) Anupam Datta, Ante Derek, John C. Mitchell, and Arnab Roy. 2007\.  Protocol Composition Logic (PCL).  Electronic Notes in Theoretical Computer Science 172 (2007), 311 – 358.  https://doi.org/10.1016/j.entcs.2007.02.012 Computation, Meaning, and Logic: Articles dedicated to Gordon Plotkin.
  * Dey and Weis ([n. d.]) Arkajit Dey and Stephen Weis. [n. d.].  Keyczar: A Cryptographic Toolkit.
  * Egele et al. (2013) Manuel Egele, David Brumley, Yanick Fratantonio, and Christopher Kruegel. 2013.  An Empirical Study of Cryptographic Misuse in Android Applications. In Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security (CCS ’13). ACM, New York, NY, USA, 73–84.  https://doi.org/10.1145/2508859.2516693
  * Erkök and Matthews (2008) Levent Erkök and John Matthews. 2008.  Pragmatic Equivalence and Safety Checking in Cryptol. In Proceedings of the 3rd Workshop on Programming Languages Meets Program Verification (PLPV ’09). ACM, New York, NY, USA, 73–82.  https://doi.org/10.1145/1481848.1481860
  * Fahl et al. (2012) Sascha Fahl, Marian Harbach, Thomas Muders, Lars Baumgärtner, Bernd Freisleben, and Matthew Smith. 2012.  Why Eve and Mallory Love Android: An Analysis of Android SSL (in)Security. In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS ’12). ACM, New York, NY, USA, 50–61.  https://doi.org/10.1145/2382196.2382205
  * Fischer et al. (2017) Felix Fischer, Konstantin B¨ottinger, Huang Xiao, Christian Stransky, Yasemin Acar, Michael Backes, and Sascha Fahl. 2017.  Stack Overflow Considered Harmful? The Impact of Copy&Paste on Android Application Security. In 38th IEEE Symposium on Security and Privacy (S&P ’17) (2017-05-22).
  * Gackenheimer (2013) Cory Gackenheimer. 2013\.  Implementing Security and Cryptography.  In Node. js Recipes. Springer, 133–160.
  * Georgiev et al. (2012) Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov. 2012\.  The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software. In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS ’12). ACM, New York, NY, USA, 38–49.  https://doi.org/10.1145/2382196.2382204
  * Gong and Ellison (2003) Li Gong and Gary Ellison. 2003.  Inside Java(TM) 2 Platform Security: Architecture, API Design, and Implementation (2nd ed.).  Pearson Education.
  * He et al. (2015) B. He, V. Rastogi, Y. Cao, Y. Chen, V. N. Venkatakrishnan, R. Yang, and Z. Zhang. 2015.  Vetting SSL Usage in Applications with SSLINT. In 2015 IEEE Symposium on Security and Privacy. 519–534.  https://doi.org/10.1109/SP.2015.38
  * Lazar et al. (2014) David Lazar, Haogang Chen, Xi Wang, and Nickolai Zeldovich. 2014.  Why Does Cryptographic Software Fail?: A Case Study and Open Problems. In Proceedings of 5th Asia-Pacific Workshop on Systems (APSys ’14). ACM, New York, NY, USA, Article 7, 7 pages.  https://doi.org/10.1145/2637166.2637237
  * Li et al. (2014) Yong Li, Yuanyuan Zhang, Juanru Li, and Dawu Gu. 2014\.  iCryptoTracer: Dynamic Analysis on Misuse of Cryptography Functions in iOS Applications.  Springer International Publishing, Cham, 349–362.  https://doi.org/10.1007/978-3-319-11698-3_27
  * Long (2005) Fred Long. 2005\.  Software Vulnerabilities in Java.  Technical Report CMU/SEI-2005-TN-044. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA.  http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=7573
  * Mettler et al. (2010) Adrian Mettler, David Wagner, and Tyler Close. 2010\.  Joe-E: A Security-Oriented Subset of Java. In Network and Distributed Systems Symposium. Internet Society.  http://www.truststc.org/pubs/652.html
  * Mitchell et al. (1997) J. C. Mitchell, M. Mitchell, and U. Stern. 1997\.  Automated Analysis of Cryptographic Protocols Using Mur/Spl Phi/. In Proceedings of the 1997 IEEE Symposium on Security and Privacy (SP ’97). IEEE Computer Society, Washington, DC, USA, 141–.  http://dl.acm.org/citation.cfm?id=882493.884384
  * Möller et al. (2014) Bodo Möller, Thai Duong, and Krzysztof Kotowicz. 2014\.  This POODLE bites: exploiting the SSL 3.0 fallback.  PDF online (2014), 1–4.
  * Nadi et al. (2016) Sarah Nadi, Stefan Krüger, Mira Mezini, and Eric Bodden. 2016.  Jumping Through Hoops: Why Do Java Developers Struggle with Cryptography APIs?. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16). ACM, New York, NY, USA, 935–946.  https://doi.org/10.1145/2884781.2884790
  * Oaks (1998) Scott Oaks. 1998\.  Java Security.  O’Reilly & Associates, Inc., Sebastopol, CA, USA.
  * Onwuzurike and De Cristofaro (2015) Lucky Onwuzurike and Emiliano De Cristofaro. 2015.  Danger is My Middle Name: Experimenting with SSL Vulnerabilities in Android Apps. In Proceedings of the 8th ACM Conference on Security & Privacy in Wireless and Mobile Networks (WiSec ’15). ACM, New York, NY, USA, Article 15, 6 pages.  https://doi.org/10.1145/2766498.2766522
  * Rashid ([n. d.]) Fahmida Y. Rashid. [n. d.].  Library misuse exposes leading Java platforms to attack.  http://www.infoworld.com/article/3003197/security/library-misuse-exposes-leading-java-platforms-to-attack.html. ([n. d.]).
  * Shuai et al. (2014) Shao Shuai, Dong Guowei, Guo Tao, Yang Tianchang, and Shi Chenjie. 2014.  Modelling Analysis and Auto-detection of Cryptographic Misuse in Android Applications. In Proceedings of the 2014 IEEE 12th International Conference on Dependable, Autonomic and Secure Computing (DASC ’14). IEEE Computer Society, Washington, DC, USA, 75–80.  https://doi.org/10.1109/DASC.2014.22
  * Smith and Dill (2008) E. Smith and D. L. Dill. 2008.  Automatic Formal Verification of Block Cipher Implementations. In 2008 Formal Methods in Computer-Aided Design. 1–7.  https://doi.org/10.1109/FMCAD.2008.ECP.10
  * Steven (2017) J Steven. 2017.  Password storage cheat sheet.  (2017).  https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
  * Stevens et al. (2017) Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. 2017\.  The first collision for full SHA-1.  IACR Cryptology ePrint Archive 2017 (2017), 190.
  * Wang et al. (2004) Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu. 2004\.  Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD.  IACR Cryptology ePrint Archive 2004 (2004), 199.
  * Yang et al. (2016) Xin-Li Yang, David Lo, Xin Xia, Zhi-Yuan Wan, and Jian-Ling Sun. 2016.  What Security Questions Do Developers Ask? A Large-Scale Study of Stack Overflow Posts.  Journal of Computer Science and Technology 31, 5 (01 Sep 2016), 910–924.  https://doi.org/10.1007/s11390-016-1672-0
  * Zeller and Felten ([n. d.]) William Zeller and Edward W Felten. [n. d.].  Cross-Site Request Forgeries: Exploitation and prevention, 2008.  ([n. d.]).