whitelist checker: an eclipse plugin to improve application security
TRANSCRIPT
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