Java Insecurity: Accounting for Subtleties That Can Compromise Code

Conscientious Java developers are typically aware of the numerous coding guidelines that they should follow when writing code, such as validating inputs, minimizing accessibility to classes and members, and avoiding public static nonfinal fields. Java developers follow such guidelines to avoid common programming pitfalls (often called antipatterns), thereby reducing the likelihood of bugs or security vulnerabilities in their programs.     

Seven pernicious kingdoms: a taxonomy of software security errors

Taxonomies can help software developers and security practitioners understand the common coding mistakes that affect security. The goal is to help developers avoid making these mistakes and more readily identify security problems whenever possible. Because developers today are by and large unaware of the security problems they can (unknowingly) introduce into code, a taxonomy of coding errors should provide a real tangible benefit to the software security community. Although the taxonomy proposed here is incomplete and imperfect, it provides an important first step. It focuses on collecting common errors and explaining them in a way that makes sense to programmers. This new taxonomy is made up of two distinct kinds of sets, which we're stealing from biology: a phylum (a type of coding error, such as illegal pointer value) and a kingdom (a collection of phyla that shares a common theme, such as input validation and representation). Both kingdoms and phyla naturally emerge from a soup of coding rules relevant to enterprise software, and it's for this reason that this taxonomy is likely to be incomplete and might lack certain coding errors. In some cases, it's easier and more effective to talk about a category of errors than to talk about any particular attack. Although categories are certainly related to attacks, they aren't the same as attack patterns.     

Diagnosing and correcting design inconsistencies in source code with logical abduction

Correcting design decay in source code is not a trivial task. Diagnosing and subsequently correcting inconsistencies between a software system’s code and its design rules (e.g., database queries are only allowed in the persistence layer) and coding conventions can be complex, time-consuming and error-prone. Providing support for this process is therefore highly desirable, but of a far greater complexity than suggesting basic corrective actions for simplistic implementation problems (like the “declare a local variable for non-declared variable” suggested by Eclipse).We present an abductive reasoning approach to inconsistency correction that consists of (1) a means for developers to document and verify a system’s design and coding rules, (2) an abductive logic reasoner that hypothesizes possible causes of inconsistencies between the system’s code and the documented rules and (3) a library of corrective actions for each hypothesized cause. This work builds on our previous work, where we expressed design rules as equality relationships between sets of source code artifacts (e.g., the set of methods in the persistence layer is the same as the set of methods that query the database). In this paper, we generalize our approach to design rules expressed as user-defined binary relationships between two sets of source code artifacts (e.g., every state changing method should invoke a persistence method).We illustrate our approach on the design of IntensiVE, a tool suite that enables defining sets of source code artifacts intensionally (by means of logic queries) and verifying relationships between such sets.     

Caution: this product contains security code

Writing functional and error code already is problematic because of context switches that must occur inside the heads of software developers as they progress in their coding task. These distracting context switches lead to coding errors because developers stop thinking about one type of code and start thinking about another. Having to consider a third code type further increases the code development processes' complexity. In this article, we look at today's security coding environment and suggest some research thrusts to advance programmers' capabilities to address modern security programming challenges.     

To var or not to var: how do C# developers use and misuse implicit and explicit typing?

When implicit typing with the “var” keyword was introduced into C#, it prompted contradictory opinions among developers. This paper starts by explaining the difference between implicit and explicit typing and then provides an overview of developers’ opinions and guidelines that are available online. This paper then reports on the results of a study that investigated how C# developers use and misuse implicit and explicit typing. This study involved analyzing the source code of 10 different open-source software projects including more than 16,500,000 lines of code and more than 930,000 variables. This study investigated to what extent developers use a form of typing that affects the readability of a variable’s type and the length of its declaration. It also investigated whether or not there is an adoption of a consistent set of guidelines in general and across each software project. A tool called “Code Analysis and Refactoring Engine for C#” (Care#) was developed and used to conduct the code analysis for this study.

     

代码挖掘中的数据处理方法综述

程序代码中蕴含着软件开发人员最原始的开发理念、设计思想和编程习惯等信息,将数据挖掘用于分析处理这种编码痕迹以便提取出潜藏着的有用知识是一个有着广阔前景的新的研究领域.由于当前的挖掘程序尚无法直接处理这种文本结构的程序代码,因而研究者需要将软件代码抽象成一种更有效的中间表达形式来作为挖掘对象.这种中间表达形式不仅界定了挖掘所使用的算法,更重要的是,它决定了所能挖掘的知识内容.对代码挖掘的一般过程进行了介绍并着重分析了代码挖掘的各种中间表达形式的特点.在此基础上,指出了当前代码挖掘存在的问题及今后的发展方向.     

Software defect prediction using Bayesian networks

There are lots of different software metrics discovered and used for defect prediction in the literature. Instead of dealing with so many metrics, it would be practical and easy if we could determine the set of metrics that are most important and focus on them more to predict defectiveness. We use Bayesian networks to determine the probabilistic influential relationships among software metrics and defect proneness. In addition to the metrics used in Promise data repository, we define two more metrics, i.e. NOD for the number of developers and LOCQ for the source code quality. We extract these metrics by inspecting the source code repositories of the selected Promise data repository data sets. At the end of our modeling, we learn the marginal defect proneness probability of the whole software system, the set of most effective metrics, and the influential relationships among metrics and defectiveness. Our experiments on nine open source Promise data repository data sets show that response for class (RFC), lines of code (LOC), and lack of coding quality (LOCQ) are the most effective metrics whereas coupling between objects (CBO), weighted method per class (WMC), and lack of cohesion of methods (LCOM) are less effective metrics on defect proneness. Furthermore, number of children (NOC) and depth of inheritance tree (DIT) have very limited effect and are untrustworthy. On the other hand, based on the experiments on Poi, Tomcat, and Xalan data sets, we observe that there is a positive correlation between the number of developers (NOD) and the level of defectiveness. However, further investigation involving a greater number of projects is needed to confirm our findings.     

Social4all: Definition of specific adaptations in Web applications to improve accessibility

Web accessibility guidelines help developers to create websites which can more easily be used by people with different limitations. The principles and techniques of accessibility focus on the suitable use of standard Web components, alternative methods to present information, and alternatives to facilitate user interaction. Currently, the biggest part in creating accessible websites is played by Web developers, because they manage the page code. Unfortunately, there are millions of websites which do not follow accessibility guidelines, as this usually requires great effort and knowledge of accessibility issues. This research aims to create a platform, based on a novel approach, which allows a set of accessibility problems to be solved without modifying the original page code. The proposed platform is able to analyse websites and detect many accessibility problems automatically; after this, a guided assistant is used to offer adequate solutions to each detected problem. The assistant tries to abstract references to Web implementation issues and to explain every accessibility problem in an understandable way for non-technical people. This new approach could be useful to improve the level of accessibility of many websites for people besides Web developers.     

Approximate Structural Context Matching: An Approach to Recommend Relevant Examples

When coding to an application programming interface (API), developers often encounter difficulties, unsure of which class to subclass, which objects to instantiate, and which methods to call. Example source code that demonstrates the use of the API can help developers make progress on their task. This paper describes an approach to provide such examples in which the structure of the source code that the developer is writing is matched heuristically to a repository of source code that uses the API. The structural context needed to query the repository is extracted automatically from the code, freeing the developer from learning a query language or from writing their code in a particular style. The repository is generated automatically from existing applications, avoiding the need for handcrafted examples. We demonstrate that the approach is effective, efficient, and more reliable than traditional alternatives through four empirical studies     

Eye movements in software traceability link recovery

Information Retrieval (IR) approaches, such as Latent Semantic Indexing (LSI) and Vector Space Model (VSM), are commonly applied to recover software traceability links. Recently, an approach based on developers’ eye gazes was proposed to retrieve traceability links. This paper presents a comparative study on IR and eye-gaze based approaches. In addition, it reports on the possibility of using eye gaze links as an alternative benchmark in comparison to commits. The study conducted asked developers to perform bug-localization tasks on the open source subject system JabRef. The iTrace environment, which is an eye tracking enabled Eclipse plugin, was used to collect eye gaze data. During the data collection phase, an eye tracker was used to gather the source code entities (SCE’s), developers looked at while solving these tasks. We present an algorithm that uses the collected gaze dataset to produce candidate traceability links related to the tasks. In the evaluation phase, we compared the results of our algorithm with the results of an IR technique, in two different contexts. In the first context, precision and recall metric values are reported for both IR and eye gaze approaches based on commits. In the second context, another set of developers were asked to rate the candidate links from each of the two techniques in terms of how useful they were in fixing the bugs. The eye gaze approach outperforms standard LSI and VSM approaches and reports a 55 % precision and 67 % recall on average for all tasks when compared to how the developers actually fixed the bug. In the second context, the usefulness results show that links generated by our algorithm were considered to be significantly more useful (to fix the bug) than those of the IR technique in a majority of tasks. We discuss the implications of this radically different method of deriving traceability links. Techniques for feature location/bug localization are commonly evaluated on benchmarks formed from commits as is done in the evaluation phase of this study. Although, commits are a reasonable source, they only capture entities that were eventually changed to fix a bug or resolve a feature. We investigate another type of benchmark based on eye tracking data, namely links generated from the bug-localization tasks given to the developers in the data collection phase. The source code entities relevant to subjected bugs recommended from IR methods are evaluated on both commits and links generated from eye gaze. The results of the benchmarking phase show that the use of eye tracking could form an effective (complementary) benchmark and add another interesting perspective in the evaluation of bug-localization techniques.     

Constantine: configurable static analysis tool in Eclipse

Static code analysers help in exposing internal code quality problems. For higher effectiveness, they must be pressed into use early during the development of code. They must support the formulation of new coding constraints with relative ease to better cope with variations in coding standards. We present the design of a static analyser that addresses these twin objectives. Our system provides interactive feedback to programmers on the non‐conformances that occur in response to the changes made to the code. Its rule construction framework empowers programmers to define new conformance rules, which can come into effect immediately after creation. The tool has been realized as an Eclipse plug‐in for the analysis of C, C++ and Java sources. Central to its design is the concept of reusing a set of primitive checks by composing them to form new rules. This renders rule construction accessible to programmers, lowers dependence on tool smiths and accelerates the enforcement of custom checks. We also present our experience in defining rules drawn from an industry standard rule set based on this approach. Copyright © 2012 John Wiley & Sons, Ltd.     

Predicting source code changes by mining change history

Software developers are often faced with modification tasks that involve source which is spread across a code base. Some dependencies between source code, such as those between source code written in different languages, are difficult to determine using existing static and dynamic analyses. To augment existing analyses and to help developers identify relevant source code during a modification task, we have developed an approach that applies data mining techniques to determine change patterns - sets of files that were changed together frequently in the past - from the change history of the code base. Our hypothesis is that the change patterns can be used to recommend potentially relevant source code to a developer performing a modification task. We show that this approach can reveal valuable dependencies by applying the approach to the Eclipse and Mozilla open source projects and by evaluating the predictability and interestingness of the recommendations produced for actual modification tasks on these systems.     

Recording concerns in source code using annotations

A concern can be characterized as a developer׳s intent behind a piece of code, often not explicitly captured in it. We discuss a technique of recording concerns using source code annotations (concern annotations). Using two studies and two controlled experiments, we seek to answer the following 3 research questions: (1) Do programmers׳ mental models overlap? (2) How do developers use shared concern annotations when they are available? (3) Does using annotations created by others improve program comprehension and maintenance correctness, time and confidence? The first study shows that developers׳ mental models, recorded using concern annotations, overlap and thus can be shared. The second study shows that shared concern annotations can be used during program comprehension for the following purposes: hypotheses confirmation, feature location, obtaining new knowledge, finding relationships and maintenance notes. The first controlled experiment with students showed that the presence of annotations significantly reduced program comprehension and maintenance time by 34%. The second controlled experiment was a differentiated replication of the first one, focused on industrial developers. It showed a 33% significant improvement in correctness. We conclude that concern annotations are a viable way to share developers׳ thoughts.     

A field study of how developers locate features in source code

Our current understanding of how programmers perform feature location during software maintenance is based on controlled studies or interviews, which are inherently limited in size, scope and realism. Replicating controlled studies in the field can both explore the findings of these studies in wider contexts and study new factors that have not been previously encountered in the laboratory setting. In this paper, we report on a field study about how software developers perform feature location within source code during their daily development activities. Our study is based on two complementary field data sets: one that reflects complete IDE activity of 67 professional developers over approximately one month, and the other that reflects usage of an IR-based code search tool by nearly 600 developers. Analyzing this data, we report results on how often developers use which type of code search tools, on the types of queries and retreival strategies used by developers, and on patterns of developer feature location behavior following code search. The results of the study suggest that there is (1) a need for helping developers to devise better code search queries; (2) a lack of adoption of niche code search tools; (3) a need for code search tool to handle both lookup and exploratory queries; and (4) a need for better integration between code search, structured navigation, and debugging tools in feature location tasks.     

Over-exposed classes in Java: An empirical study

Java access modifiers regulate interactions among software components. In particular, class modifiers specify which classes from a component are publicly exposed and therefore belong to the component public interface. Restricting the accessibility as specified by a programmer is key to ensure a proper software modularity. It has been said that failing to do so is likely to produce maintenance problems, poor system quality, and architecture decay. However, how developers uses class access modifiers or how inadequate access modifiers affect software systems has not been investigated yet in the literature.In this work, we empirically analyze the use of class access modifiers across a collection of 15 Java libraries and 15 applications, totaling over 3.6M lines of code. We have found that an average of 25% of classes are over-exposed, i.e., classes defined with an accessibility that is broader than necessary. A number of code patterns involving over-exposed classes have been formalized, characterizing programmers׳ habits. Furthermore, we propose an Eclipse plugin to make component public interfaces match with the programmer׳s intent.     

Evaluating the productivity of a reference-based programming approach: A controlled experiment

ContextDomain engineering aims at facilitating software development in an efficient and economical way. One way to measure that is through productivity indicators, which refer to the ability of creating a quality software product in a limited period and with limited resources. Many approaches have been devised to increase productivity; however, these approaches seem to suffer from a tension between expressiveness on the one hand, and applicability (or the lack of it) in providing guidance for developers.ObjectiveThis paper evaluates the applicability and efficiency of adopting a domain engineering approach, called Application-based DOmain Modeling (ADOM), in the context of the programming task with Java, and thus termed ADOM-Java, for improving productivity in terms of code quality and development time.MethodTo achieve that objective we have qualitatively evaluate the approach using questionnaires and following a text analysis procedure. We also set a controlled experiment in which 50 undergraduate students performed a Java-based programming task using either ADOM-Java or Java alone.ResultsThe qualitative evaluation reveal that the approach is easy to uses and provides valuable guidance. Nevertheless, it requires training. The outcomes of the experiment indicate that the approach is applicable and that the students that used ADOM-Java achieved better code quality, as well as better functionality and within less time than the students who used only Java.ConclusionThe results of the experiments imply that by providing a code base equipped with reuse guidelines for programmers can increase programming productivity in terms of quality and development time. These guidelines may also enforce coding standards and architectural design.     

Documenting and sharing software knowledge using screencasts

Screencasts are used to capture a developer’s screen while they narrate how a piece of software works or how the software can be extended. They have recently become a popular alternative to traditional text-based documentation. This paper describes our investigation into how developers produce and share developer-focused screencasts. In this study, we identified and analyzed a set of development screencasts from YouTube to explore what kinds of software knowledge are shared in video walkthroughs of code and what techniques are used for sharing software knowledge. We also interviewed YouTube screencast producers to understand their motivations for creating screencasts as well as to discover the challenges they face while producing code-focused videos. Finally, we compared YouTube screencasts to videos hosted on the professional RailsCasts website to better understand the differences and practices of this more curated ecosystem with the YouTube platform. Our three-phase study showed that video is a useful medium for communicating program knowledge between developers and that developers build their online persona and reputation by sharing videos through social channels. These findings led to a number of best practices for future screencast creators.     

融合结构与语义特征的代码注释决策支持方法

代码注释是辅助编程人员理解源代码的有效手段之一.高质量的注释决策不仅能覆盖软件系统中的核心代码片段,还能避免产生多余的代码注释.然而,在实际开发中,编程人员往往缺乏统一的注释规范,大部分的注释决策都取决于个人经验以及领域知识.对于新手程序员来说,注释决策显然成为了一项重要而艰巨的任务.为了减少编程人员投入过多的精力在注释决策上,文章从大量的代码注释实例中学习出一种通用的注释决策规范,并提出了一种新颖的CommentAdviser方法用以辅助编程人员在代码开发过程中做出恰当的注释决策.由于注释决策与代码本身的上下文信息密切相关,因此,从当前代码行的上下文代码中提取代码结构特征以及代码语义特征作为支持注释决策的主要依据.然后,利用机器学习算法判定当前代码行是否为可能的注释点.在GitHub中的10个大型开源软件的数据集上评估了我们提出的方法,实验结果以及用户调研表明代码注释决策支持方法CommentAdviser的可行性和有效性.     

处理动态行为描述的MDA模型转换技术

模型驱动体系结构MDA(Model Driven Architecture)是OMG组织为解决不同中间件平台间的集成问题而提出的一种开放的、供应商中立的软件开发方法。在MDA框架中,开发者首先构建平台无关模型PIM(Platform Independent Model),然后根据到特定平台或实现语言的映射规则/方法,从平台无关模型转换生成平台相关模型PSM(Platform Specific Model),最终生成应用程序代码。采用了UML类图在平台无关层来描述模型的静态结构,并使用动作语言对模型的动态行为进行描述;选择Java EE作为目标平台,制定出相应的转换规则,实现了从动态行为描述到目标代码的转换。使用这样的方法得到的PSM只需要很少的后期处理就可以在平台上直接运行。研究工作较好地解决了当前大部分MDA模型转换工具不能处理动态行为模型转换的问题。     

Guidelines for Eliciting Usability Functionalities

Like any other quality attribute, usability imposes specific constraints on software components. Features that raise the software system's usability have to be considered from the earliest development stages. But, discovering and documenting usability features is likely to be beyond the usability knowledge of most requirements engineers, developers, and users. We propose an approach based on developing specific guidelines that capitalize upon key elements recurrently intervening in the usability features elicitation and specification process. The use of these guidelines provides requirements analysts with a knowledge repository. They can use this repository to ask the right questions and capture precise usability requirements information.