1. Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License. The OWASP Foundation OWASP AppSec June 2004 NYC http://www.owasp.org Input Validation Jeff Williams, OWASP Chair CEO, Aspect Security jeff.williams@aspectsecurity.comeff.williams@aspectsecurity.com 410-707-1487

2. OWASP AppSec 2004 2 It’s All Jon Postel’s Fault  “TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.” -- Jon Postel, RFC 793, Sept. 1981

3. OWASP AppSec 2004 3 “Sender Validates” Mindset  Assume that data is valid  Or only check a few pathological cases  Common problems with this approach  Buffer overflows  Forced browsing  Cookie poisoning  SQL injection  Command injection  Format string

4. OWASP AppSec 2004 4 Common Validation Approaches  Deep Packet Inspection  Web Application Firewall  Server Plugin  J2EE Filter  Validation Component  Validation Pattern in Code  Validate Everywhere Completely outside application Completely within application

5. OWASP AppSec 2004 5 Confusing Terms  Filter  Often used synonymously with “Validate,” but implies stripping out something bad.  Blacklist  Validation done against a list of known bad patterns in the input. Generally considered bad practice.  Whitelist  Validation done against a list of known good patterns in the input. Generally considered good practice.

6. OWASP AppSec 2004 6 Architecture  Needs  Nonbypassable control point  Access to the “rules”  Access to any required contextual information  Requirements  Positive security model (deny all)  Easy to maintain for developers

7. OWASP AppSec 2004 7 “Boundary Validation”  Validate at reasonable system boundaries  Between client and business logic  Between business logic and database (e.g.)  Between application and major libraries  Between major subsystems within an application  A better “principle of robustness”  Modified Postel’s Law…  “…be liberal in what you accept from others, then validate the hell out of it.”

8. OWASP AppSec 2004 8 What Are the “Rules”?  Examples:  What punctuation is allowed in a textbox?  What is the zipcode format?  What are the header rules? Cookies?  What are all the possible responses to an error?  How can we detect an attack in progress?  Extra, Missing, Duplicate, and Malformed

9. OWASP AppSec 2004 9 What “Actions” Can You Take?  log "Extra cookie detected, value = $value."  message "Extra cookie detected."  invalidate  delete  sanitize  replace "new_value"  email jeff.williams@owasp.org "Extra cookie detected"  errorpage "Extra cookie detected"  redirect error.jsp?message="Extra cookie detected"  sleep 2000  shutdown

10. OWASP AppSec 2004 10 What “Severity” Applies?  Some errors are “fatal”  Almost certainly an attack  Stop validating, invalidate session (go away)  You can “continue” after some errors  Sanitize, use default, log  Continue validating  Some conditions you just want to “ignore”  Unexpected header

11. OWASP AppSec 2004 11 How to Capture a Rule JSESSIONID cookie ^[A-F0-9]{32}$ fatal invalidate log verbose "Cookie tampering detected." continue log "Cookie missing." redirect “/login”

12. OWASP AppSec 2004 12 How to Assemble a Ruleset Validation rules for the login form /login true …

13. OWASP AppSec 2004 13 How To Review Code for Validation  Trace the “taint” from all calls used to get input  HttpServletRequest.getParameter()  HttpServletRequest.getCookies()  HttpServletRequest.getHeader()  Etc…  Bad Patterns  Input -> Output == cross-site scripting  Input -> System == command injection  Input -> Query == SQL injection  Input -> Fixed buffer or format string == overflow  Input -> Integer == overflow

14. OWASP AppSec 2004 14 Validation Checklist  Is your validation centralized?  Is your validation mandatory?  Do you canonicalize before validating?  Are you validating URL params, cookies, and other headers  NOT just forms? (Struts fails this)  Do you catch extra, missing, and duplicate input?  NOT just corrupt input?  Do you have options for handling validation problems?  Can you detect an attack based on repeated failed input validation?  Is what you log different than what you show the user?  Do your requirements specify all the stuff above?  Do your requirements or detailed design docs specify all the validation rules?  Does you use HTML Entity encoding (e.g. <) on output?

15. OWASP AppSec 2004 15 Simple Audit Exercise public class HelloWorld extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(" "); out.println(" Hello World "); out.println(" "); out.println("Hello, " + request.getParameter("name")); out.println(" "); }

16. OWASP AppSec 2004 16 Harder Audit Exercise public class DamagedStrutsForm extends ActionForm { public void doForm( HttpServletRequest request) { UserBean u = session.getUserBean(); u.setName(request.getParameter("name")); u.setFavoriteColor(request.getParameter("color")); } public boolean validate( HttpServletRequest request) { try { if ( request.getParameter("Name").indexOf("<script") != -1 ) { logger.log("Script detected" ); return false; } } catch( Exception e ) {} return true; }

17. OWASP AppSec 2004 17 Haystack Full of Needles  Validation is incredibly important  Difficult to get correct  Spend some time designing your approach  Consider participating in or sponsoring the OWASP Stinger project