Copyright © 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 Input Validation Jeff Williams, OWASP Chair CEO, Aspect Security

OWASP AppSec 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

OWASP AppSec “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

OWASP AppSec 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

OWASP AppSec 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.

OWASP AppSec 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

OWASP AppSec “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.”

OWASP AppSec 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

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

OWASP AppSec 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

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

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

OWASP AppSec 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

OWASP AppSec 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?

OWASP AppSec 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(" "); }

OWASP AppSec 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; }

OWASP AppSec 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