Secure Coding Practices in Java: Challenges and Vulnerabilities∗

Secure Coding Practices in Java: Challenges and Vulnerabilities∗

Secure Coding Practices in Java: Challenges and Vulnerabilities∗ Na Meng Stefan Nagy Danfeng (Daphne) Yao Wenjie Zhuang Gustavo Arango Argoty Department of Computer Science Virginia Tech Blacksburg, Virginia {nm8247,snagy2,danfeng,kaito,gustavo1}@vt.edu ABSTRACT 1 INTRODUCTION The Java platform and its third-party libraries provide useful fea- The Java platform and third-party libraries (e.g., BouncyCastle [9]) tures to facilitate secure coding. However, misusing them can cost provide useful features to support secure coding. Misusing these developers time and effort, as well as introduce security vulnerabili- libraries and frameworks not only slows down code development, ties in software. We conducted an empirical study on StackOverflow but also leads to security vulnerabilities in software [19, 74, 80, 98]. posts, aiming to understand developers’ concerns on Java secure Prior research has mostly focused on the specific topics of mis- coding, their programming obstacles, and insecure coding practices. using cryptography and secure socket layer (SSL) APIs [23, 26, 29, We observed a wide adoption of the authentication and autho- 60, 72]. For example, Nadi et al. investigated the obstacles intro- rization features provided by Spring Security—a third-party frame- duced by Java cryptography APIs, developers’ usage of the APIs, work designed to secure enterprise applications. We found that and desired tool support [68]. Lazar et al. manually examined 269 programming challenges are usually related to APIs or libraries, published cryptographic vulnerabilities in the CVE database, and including the complicated cross-language data handling of cryptog- found that 83% of them were resulted from cryptography API mis- raphy APIs, and the complex Java-based or XML-based approaches use [60]. Fahl et al. [26] and Georgiev et al. [29] separately reported to configure Spring Security. In addition, we reported multiple se- vulnerable Android applications and software libraries that mis- curity vulnerabilities in the suggested code of accepted answers on use SSL APIs and demonstrated how these vulnerabilities cause the StackOverflow forum. The vulnerabilities included disabling man-in-the-middle attacks. Rahaman and Yao recently introduced the default protection against Cross-Site Request Forgery (CSRF) cryptographic program analysis (CPA) [72], which detects crypto- attacks, breaking SSL/TLS security through bypassing certificate graphic coding errors in C/C++ programs with static taint analysis. validation, and using insecure cryptographic hash functions. Our All these studies on improving cryptography and SSL coding secu- findings reveal the insufficiency of secure coding assistance and rity are timely and important. documentation, as well as the huge gap between security theory In this work, we conducted an in-depth investigation on Java and coding practices. secure coding problems. Our analysis is not limited to cryptography or SSL APIs. We inspected 503 StackOverflow (SO) posts that are CCS CONCEPTS related to Java security. The majority (87%) of the posts are about • General and reference → Empirical studies; non-crypto libraries. For each post, we thoroughly examined the entire thread, including the question and all the responses. We KEYWORDS chose StackOverflow [91] because (1) it is an extremely popular online platform for developers to share and discuss programming Secure coding, Spring Security, CSRF, SSL/TLS, certificate valida- issues and solutions, and (2) SO plays an important role in educating tion, cryptographic hash functions, authentication, authorization, developers and shaping their daily coding practices. StackOverflow, cryptography Our analysis was conducted at the code level, as code-level in- ACM Reference Format: vestigation has the potential to bring deeper insights. The technical Na Meng Stefan Nagy Danfeng (Daphne) Yao Wenjie Zhuang challenge is how to interpret the short and brief posts within the Gustavo Arango Argoty. 2018. Secure Coding Practices in Java: Chal- appropriate programming context in order to understand the security ICSE ’18: ICSE ’18: 40th International Conference lenges and Vulnerabilities. In impact. To comprehend each post’s program context, we studied the on Software Engineering , May 27-June 3, 2018, Gothenburg, Sweden. ACM, context related to the source code, configuration files, and execution New York, NY, USA, 12 pages. https://doi.org/10.1145/3180155.3180201 environments. We aimed to identify the root causes and solutions ∗This work was supported by NSF Grant CCF-1565827 and ONR Grant N00014-17-1- of each problem. To comprehend each post’s security context, we 2498. inferred developers’ implementation intents from their problem descriptions and the involved security libraries. We also leveraged Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed our security expertise to assess whether the accepted solutions for profit or commercial advantage and that copies bear this notice and the full citation fulfilled their original intents. These analysis and reasoning tasks on the first page. Copyrights for components of this work owned by others than ACM require expertise in both software engineering and cyber security. must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a In our analysis of the 503 StackOverflow posts, we investigated fee. Request permissions from [email protected]. the following three research questions (RQs): ICSE ’18, May 27-June 3, 2018, Gothenburg, Sweden © 2018 Association for Computing Machinery. RQ1 What are the common concerns in Java secure coding? We ACM ISBN 978-1-4503-5638-1/18/05...$15.00 https://doi.org/10.1145/3180155.3180201 aimed to identify the libraries and functionalities (e.g., [3, ICSE ’18, May 27-June 3, 2018, Gothenburg, Sweden N. Meng et al. 32, 45, 47, 69, 85]) that were most frequently asked about 2 BACKGROUND by developers. Our scope covers all topics related to Java The examined posts cover three topics on Java security: Java plat- security, not limited to cryptography and SSL. form security, Java EE security, and third-party frameworks. This RQ2 What are the common programming challenges? We aimed section introduces the key terminologies used throughout the paper. to identify the common obstacles that hinder secure cod- ing. Such information can provide software engineering re- 2.1 Java Platform Security searchers actionable insights for designing tools and help The platform defines APIs spanning major security areas, including close the gap between correct API usage and the practice. cryptography, access control, and secure communication [54]. The RQ3 What are the common security vulnerabilities? The high popu- Java Cryptography Architecture (JCA) contains APIs for crypto- larity of StackOverflow may cause insecure code to be shared graphic hashes, keys and certificates, digital signatures, and and used in real-world implementations. This effort helps encryption [47]. Nine cryptographic engines are defined to pro- raise the security awareness among software developers. vide either cryptographic operations (encryption, digital signatures, Our work provides empirical evidences for many significant hashes), generators or converters of cryptographic material (keys secure coding issues that have not been previously reported. The and algorithm parameters), or objects (keystores or certificates) that major findings are summarized as follows. encapsulate the cryptographic data. The access control architecture • There were security vulnerabilities in the recommended code protects the access to sensitive resources (e.g., local files) or sensi- of some accepted answers. For example, when encountering tive application code (e.g., methods in a class). All access control errors during implementing Spring Security authentication, decisions are mediated by a security manager. By default, the developers were suggested a workaround to disable the de- security manager uses the AccessController class for access control fault security protection against Cross-Site Request Forgery operations and decisions. Secure communication ensures that the (CSRF) attacks. Also for example, some posts advised devel- data traveling across a network is sent to the appropriate party, opers to trust all incoming SSL/TLS certificates as a fix to cer- without being modified during the transmission. The Java platform tificate verification errors. Such a setup completely destroys provides API support for standard secure communication protocols the security guarantees of SSL/TLS. Although this insecure like SSL/TLS. HTTPS, or “HTTP secure”, is an application-specific practice was reported by security researchers in 2012 [26, 29], implementation that is a combination of HTTP and SSL/TLS. some SO users still view this option as acceptable. In addi- tion, MD5 or SHA-1 algorithms was repeatedly suggested, 2.2 Java EE Security even though these cryptographic hashing algorithms are Java EE is a standard specification for enterprise Java extensions [59]. weak and should not be used for hashing passwords. For the Various application servers are built to implement this specification, 17 problematic posts (5 on CSRF, 9 on SSL/TLS, and 3 on such as JBoss or WildFly [104], Glassfish [31], WebSphere [101], 1 password hashing), the total view count is 622,922

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    12 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us