WhiteList Checker: An Eclipse Plugin to

Improve Application Security

Bill Chu, Jing Xie, Will Stranathan

Department of Software and Information Systems

University of North Carolina at Charlotte

Motivation There is a gap in tool support for secure programming

Analysis tools (e.g. Fortify, ESC/Java, CodeHawk) work in batch mode

The process is the same early compilers

Manually diagnose and fix problems

Developers have heavy cognitive load while programming

IDEs have dramatically eased the programming task and let developers

focus on difficult logic tasks

Gap: no such interactive tool support exist for secure programming

It is insufficient to rely on secure coding training and manual enforcement

of coding standards alone

Motivation There is a gap in secure programming research

Mental model: how programmers address security concerns

while programming?

What types of tool support should be designed to help

programmers give adequate attention / considerations to

security issues while programming?

Code generation

Annotation

Case study: input validation

Lack of proper input validation is a leading cause of software

vulnerabilities

Detection: static analysis

Late in the development cycle

Does not help fixing the problem, i.e. how to validate

Action: programmer training, paper standards, program

libraries, no methodological support

White list vs. Black list validation

White list input validation is not easy to do, even for common input types

(e.g. names)

Sample input validation issues

Where in the program should validation take place?

When data enters the system

When data is used in sensitive system calls (Fortify default rules)

How to enforce enterprise wide input validation standards?

What needs to be validated

What is the standard validation

Auditing and tracking

When in the development cycle to address input validation?

Design: setting enterprise/project standards

Coding: ?

Security Auditing: penetration test/static analysis

IDE based support for input validation

String username = request.getParameter(“username”);

String username = request.getParameter(“username”);try{

Validation.validate(username, “safe_text”);}catch(InputValidationException e){

username = “safe text”; }

•Identify untrusted input

• Interactively notify

developer (similar to syntax

error)

• Present choice of input

types

• Generate validation code

• Encourage developers to

perform input validation at

the earliest possible time

Trust boundary definition

API calls

HttpServletRequest.getParameter()

System.getProperty()

ResultSet.getString()

ServletContext.getInitParameter()

Parameters / Variables

main (String[] args)

Input validation rules Initialized with a set of regular expressions developed by

OWASP for input validation

Syntactic rules

Regular expressions

e.g. email, full path file name

Semantic rules

Specific to input type

e.g. files under /usr/billchu

User defined rules

Regular expression

Customized routines

Benefits Set enterprise-wide standards

Identify and track untrusted input

where they are input into the application

validation actions taken ( it might be okay to ignore compiler warnings,

but do not ignore input validations)

Interesting queries

How many places in this application do we accept credit card numbers

from the user?

Does this application accept sensitive information from the customer?

Reduce false positives in analysis

Generate (Fortify) rules that remove taints to reduce false positives

Future work

Programmer mental model for secure programming

Technical tool support

Add critical features for input validation

Additional support for other secure programming tasks

Mental model for secure programming

How do programmers juggle security concerns

among many others concerns?

Use input validation as case study

Identify programmer strategies /behavior

Evaluate our tool as constructed

Improvement / identify new tool support needed

Additional features for input validation support

Input of composite type

Ad hoc structures (e.g. ParameterMap, hash tables)

Perform data flow analysis (including across developer

boundary)

Valid elements when used

Specialized data types (e.g. sparse matrix, JNI objects)

Standardized validation routines

Dynamic data types

User intervention

Semantic rules

Refinements

e.g. filepath -> under certain directories

e.g. price -> less than $1,000

Relationship rules

e.g. endTime > startTime

e.g. “constraint”

Challenge: an effective and simple specification

language

Interactive tool support for other secure

programming issues

Start with rules that might be used in static analysis

e.g. broken authentication / authorization

Types of help

Code generation

Annotation

Challenge: must have very low false positive rates

We cannot ignore compiler errors

How often do we ignore compiler warnings?

Demo