Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WhiteList Checker: An Eclipse Plugin to Improve Application Security

2,666 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

WhiteList Checker: An Eclipse Plugin to Improve Application Security

  1. 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. 2. Motivation <ul><li>There is a gap in tool support for secure programming </li></ul><ul><ul><li>Analysis tools (e.g. Fortify, ESC/Java, CodeHawk) work in batch mode </li></ul></ul><ul><ul><ul><li>The process is the same early compilers </li></ul></ul></ul><ul><ul><ul><li>Manually diagnose and fix problems </li></ul></ul></ul><ul><ul><li>Developers have heavy cognitive load while programming </li></ul></ul><ul><ul><li>IDEs have dramatically eased the programming task and let developers focus on difficult logic tasks </li></ul></ul><ul><ul><li>Gap: no such interactive tool support exist for secure programming </li></ul></ul><ul><ul><li>It is insufficient to rely on secure coding training and manual enforcement of coding standards alone </li></ul></ul>
  3. 3. Motivation <ul><li>There is a gap in secure programming research </li></ul><ul><ul><li>Mental model: how programmers address security concerns while programming? </li></ul></ul><ul><ul><li>What types of tool support should be designed to help programmers give adequate attention / considerations to security issues while programming? </li></ul></ul><ul><ul><ul><li>Code generation </li></ul></ul></ul><ul><ul><ul><li>Annotation </li></ul></ul></ul>
  4. 4. Case study: input validation <ul><li>Lack of proper input validation is a leading cause of software vulnerabilities </li></ul><ul><li>Detection: static analysis </li></ul><ul><ul><li>Late in the development cycle </li></ul></ul><ul><ul><li>Does not help fixing the problem, i.e. how to validate </li></ul></ul><ul><li>Action: programmer training, paper standards, program libraries, no methodological support </li></ul><ul><ul><li>White list vs. Black list validation </li></ul></ul><ul><ul><li>White list input validation is not easy to do, even for common input types (e.g. names) </li></ul></ul>
  5. 5. Sample input validation issues <ul><li>Where in the program should validation take place? </li></ul><ul><ul><li>When data enters the system </li></ul></ul><ul><ul><li>When data is used in sensitive system calls (Fortify default rules) </li></ul></ul><ul><li>How to enforce enterprise wide input validation standards? </li></ul><ul><ul><li>What needs to be validated </li></ul></ul><ul><ul><li>What is the standard validation </li></ul></ul><ul><ul><li>Auditing and tracking </li></ul></ul><ul><li>When in the development cycle to address input validation? </li></ul><ul><ul><li>Design: setting enterprise/project standards </li></ul></ul><ul><ul><li>Coding: ? </li></ul></ul><ul><ul><li>Security Auditing: penetration test/static analysis </li></ul></ul>
  6. 6. IDE based support for input validation <ul><li>Identify untrusted input </li></ul><ul><li>Interactively notify developer (similar to syntax error) </li></ul><ul><li>Present choice of input types </li></ul><ul><li>Generate validation code </li></ul><ul><li>Encourage developers to perform input validation at the earliest possible time </li></ul>String username = request.getParameter( “ username ” ); String username = request.getParameter( “ username ” ); try{ Validation.validate(username, “ safe_text ” ); }catch(InputValidationException e) { username = “ safe text ” ; }
  7. 7. Trust boundary definition <ul><li>API calls </li></ul><ul><ul><li>HttpServletRequest.getParameter() </li></ul></ul><ul><ul><li>System.getProperty() </li></ul></ul><ul><ul><li>ResultSet.getString() </li></ul></ul><ul><ul><li>ServletContext.getInitParameter() </li></ul></ul><ul><li>Parameters / variables </li></ul><ul><ul><li>main (String[] args) </li></ul></ul>
  8. 11. Input validation rules <ul><li>Initialized with a set of regular expressions developed by OWASP for input validation </li></ul><ul><li>Syntactic rules </li></ul><ul><ul><li>Regular expressions </li></ul></ul><ul><ul><ul><li>e.g. email, full path file name </li></ul></ul></ul><ul><li>Semantic rules </li></ul><ul><ul><li>Specific to input type </li></ul></ul><ul><ul><ul><li>e.g. files under /usr/billchu </li></ul></ul></ul><ul><li>User defined rules </li></ul><ul><ul><li>Regular expression </li></ul></ul><ul><ul><li>Customized routines </li></ul></ul>
  9. 12. Benefits <ul><li>Set enterprise-wide standards </li></ul><ul><li>Identify and track untrusted input </li></ul><ul><ul><li>where they are input into the application </li></ul></ul><ul><ul><li>validation actions taken ( it might be okay to ignore compiler warnings, but do not ignore input validations) </li></ul></ul><ul><li>Interesting queries </li></ul><ul><ul><li>How many places in this application do we accept credit card numbers from the user? </li></ul></ul><ul><ul><li>Does this application accept sensitive information from the customer? </li></ul></ul><ul><li>Reduce false positives in analysis </li></ul><ul><ul><li>Generate (Fortify) rules that remove taints to reduce false positives </li></ul></ul>
  10. 13. Future work <ul><li>Programmer mental model for secure programming </li></ul><ul><li>Technical tool support </li></ul><ul><ul><li>Add critical features for input validation </li></ul></ul><ul><ul><li>Additional support for other secure programming tasks </li></ul></ul>
  11. 14. Mental model for secure programming <ul><li>How do programmers juggle security concerns among many others concerns? </li></ul><ul><li>Use input validation as case study </li></ul><ul><ul><li>Identify programmer strategies /behavior </li></ul></ul><ul><ul><li>Evaluate our tool as constructed </li></ul></ul><ul><ul><li>Improvement / identify new tool support needed </li></ul></ul>
  12. 15. Additional features for input validation support <ul><li>Input of composite type </li></ul><ul><ul><li>Ad hoc structures (e.g. ParameterMap, hash tables) </li></ul></ul><ul><ul><ul><li>Perform data flow analysis (including across developer boundary) </li></ul></ul></ul><ul><ul><ul><li>Valid elements when used </li></ul></ul></ul><ul><ul><li>Specialized data types (e.g. sparse matrix, JNI objects) </li></ul></ul><ul><ul><ul><li>Standardized validation routines </li></ul></ul></ul><ul><li>Dynamic data types </li></ul><ul><ul><li>User intervention </li></ul></ul>
  13. 16. Semantic rules <ul><li>Refinements </li></ul><ul><ul><li>e.g. filepath -> under certain directories </li></ul></ul><ul><ul><li>e.g. price -> less than $1,000 </li></ul></ul><ul><li>Relationship rules </li></ul><ul><ul><li>e.g. endTime > startTime </li></ul></ul><ul><ul><li>e.g. “constraint” </li></ul></ul><ul><li>Challenge: an effective and simple specification language </li></ul>
  14. 17. Interactive tool support for other secure programming issues <ul><li>Start with rules that might be used in static analysis </li></ul><ul><ul><li>e.g. broken authentication / authorization </li></ul></ul><ul><li>Types of help </li></ul><ul><ul><li>Code generation </li></ul></ul><ul><ul><li>Annotation </li></ul></ul><ul><li>Challenge: must have very low false positive rates </li></ul><ul><ul><li>We cannot ignore compiler errors </li></ul></ul><ul><ul><li>How often do we ignore compiler warnings? </li></ul></ul>
  15. 18. Demo

×