Fixing Vulnerabilities Automatically with Linters

Abstract

Static analysis is a tried-and-tested approach to eliminate vulnerabilities in software. However, despite decades of successful use by experts, mainstream programmers often deem static analysis too costly to use. Mainstream programmers do routinely use linters, which are static analysis tools geared towards identifying simple bugs and stylistic issues in software. Can linters serve as a medium for delivering vulnerability detection to mainstream programmers?

We investigate the extent of which linters can be leveraged to help programmers write secure software. We present new rules for ESLint that detect—and automatically fix—certain classes of cross-site scripting, SQL injection, and misconfiguration vulnerabilities in JavaScript. Evaluating our experience, we find that there is enormous potential in using linters to eliminate vulnerabilities in software, due to the relative ease with which linter rules can be implemented and shared to the community. We identify several open challenges, including third-party library dependencies and linter configuration, and propose ways to address them.

A ESLint

1.1 A.1 How ESLint Works

ESLint builds on Node.js and can be installed through npm. After that a configuration file is created, ESLint can be run on source files, e.g. from the command line or within an IDE  [46]. ESLint takes as parameters which source file to lint and a configuration which e.g. specifies which rules to use.

First, ESLint parses the source file to render an abstract syntax tree (AST) from it. Each node in the resulting AST is a record which contains, amongst others, the type of the syntactic element it represents (e.g. , , , etc.), and information about where in the source file the syntactic element is located (for blame assignment). In case the information in this AST is insufficient (e.g. when writing advanced rules), ESLint lets one specify a different parser from the default one (i.e. Espree [38]), to construct an AST that stores additional information.

Next, ESLint traverses this AST to check that all rules are upheld. Each rule in ESLint is represented by an object. A rule object maintains its own state and exports methods which ESLint calls while traversing the AST. At each node, both while going down and up the AST, ESLint invokes, on each rule object, a method representing the type of the node ( , etc.; see above) and code paths ( , , etc.). If a rule detects an issue, then the rule reports the issue to a , which ESLint passes as a parameter when it creates the rule object.

1.2 A.2 Rules

Each rule in ESLint consists of three files(See footnote 3): a source file, a test file, and a documentation file.

Fig. 2.

no-constructor-return source file.no-constructor-return source file.

Source files²,(e.g. Fig. 2), are stored in lib/rules. They have the following format³. A source file exports an object with two properties.

The objects $meta$ and $docs$ have four properties.

In $docs$, is a description of what the rule checks. is the URL to the rule’s documentation. specifies whether this rule should be added to the list of recommended ESLint rules (which can all be turned on with a single option in the configuration). specifies where this rule should appear in the rules index; valid values include , , , & . In $meta$, specifies the type of the rule; valid values are for a rule that identifies bad behavior, for a rule that provides improvement suggestions, and for a rule that provides stylistic tips. If a rule does not automatically fix an issue, then the property should be omitted. Otherwise, should be set to if it only affects whitespace, and otherwise. $schema$ specifies which configuration options the rule accepts and should be omitted if the rule accepts no such options. $create$, called when the rule object is created, returns an object which contains the functions that ESLint calls while traversing the AST (see above). The rule in Figure 2 gives an example of how a rule can maintain state and traverse the AST. Its state is a stack of code paths, which it uses, upon encountering a statement, to examine the AST to see if the statement is occurring within a constructor.

Test files are stored in tests/lib/rules. The test file contains sample inputs, along with the expected result of applying the rule on said input (valid, invalid). The unit test can then be run using the testing facility built in ESLint. Documentation files, stored in docs/rules, are written in Markdown syntax, and provide a description of what rules check, and how to configure them.

Plugins. Additional rules can be added to ESLint by downloading ESLint plugins. A plugin is a collection of ESLint rules. Plugins are routinely created by individuals and organizations, and shared as packages on npm. At present, npm contains thousands of ESLint plugins, each of which often contains tens of rules.