• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
WhiteList Checker: An Eclipse Plugin to Improve Application Security
 

WhiteList Checker: An Eclipse Plugin to Improve Application Security

on

  • 2,741 views

 

Statistics

Views

Total Views
2,741
Views on SlideShare
2,503
Embed Views
238

Actions

Likes
0
Downloads
38
Comments
0

4 Embeds 238

http://www.eclipsecon.org 220
http://eclipsecon.org 9
http://www.slideshare.net 8
https://www.eclipsecon.org 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    WhiteList Checker: An Eclipse Plugin to Improve Application Security WhiteList Checker: An Eclipse Plugin to Improve Application Security Presentation 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
      • 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
      String username = request.getParameter( “ username ” ); String username = request.getParameter( “ username ” ); try{ Validation.validate(username, “ safe_text ” ); }catch(InputValidationException e) { username = “ safe text ” ; }
    • 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