Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

WhiteList Checker: An Eclipse Plugin to Improve Application Security

2.680 visualizaciones

Publicado el

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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