1. 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

2. 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

3. 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

4. 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)

5. 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

6. IDE based support for input validation
•Identify untrusted input
• Interactively notify
String username = request.getParameter(“username”);
developer (similar to syntax
error)
• Present choice of input
types String username = request.getParameter(“username”);
try{
• Generate validation code Validation.validate(username, “safe_text”);
}catch(InputValidationException e){
• Encourage developers to username = “safe text”;
perform input validation at }
the earliest possible time

7. Trust boundary definition
 API calls
 HttpServletRequest.getParameter()
 System.getProperty()
 ResultSet.getString()
 ServletContext.getInitParameter()
 Parameters / Variables
 main (String[] args)

11. 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

12. 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

13. Future work
 Programmer mental model for secure programming
 Technical tool support
 Add critical features for input validation
 Additional support for other secure programming tasks

14. 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

15. 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

16. 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

17. 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?

18. Demo