150 likes | 195 Views
OWASP Top Ten. #1 Unvalidated Input. Agenda. What is the OWASP Top 10? Where can I find it? What is Unvalidated Input? What environments are effected? How to determine if you are vulnerable How to protect yourself Demonstration. What is the OWASP Top 10?.
E N D
OWASP Top Ten #1 Unvalidated Input
Agenda • What is the OWASP Top 10? • Where can I find it? • What is Unvalidated Input? • What environments are effected? • How to determine if you are vulnerable • How to protect yourself • Demonstration
What is the OWASP Top 10? • Provides minimum standard for web app security. • Broad consensus about what the most critical web application security flaws are. • Compiled by a variety of security experts from around the world. • Available in multiple languages.
Where is the Top Ten List • Provided on the OWASP web site • OWASP Sanctioned Project • http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project • Available either online (for browsing), in word format, or in PDF format.
What is Unvalidated Input? • In order for a web application to be useful it must pass information from the client to the server and then back again. • The input passed from the client to the server helps the server determine how to respond to the client. • Although the client side has been programmed with a certain understanding of process flow in mind, malicious users can modify information before it is passed back to the server. In a vulnerable application this could cause problems if the malicious input is not handled properly.
What is Unvalidated Input? • A surprisingly large number of applications rely only on client side validation of data. • The client side data transmission is susceptible to manipulation. • There is the possibility that this manipulation could cause problems on the server. • Cross Site Scripting Flaws • Buffer Overflows • Injection Flaws
Effected Environments • All: • Web Servers • Application Servers • And Web Applications
Are you vulnerable? • Any parameter passed through HTTP that is not carefully validated is thought to be “tainted.” • Therefore all HTTP parameters (both GET and POST) must be processed before anything is done with the variable. • There are libraries built into certain web packages and OWASP packages available for other packages. • Check to see if you are vulnerable. • Use a package like WebScarab to input a multitude of unexpected input to your web application. See what happens.
Bad code: <?php $myvar = $_POST[‘fieldName’]; ?> Better code: <?php $myvar = validate($_POST[‘fieldName’]); ?> Are you vulnerable?
How to Protect Yourself • Ensure that all parameters are validated before use. • An effective way of doing this is to write a centralized library to do the validate. • This library should use “positive” filtering specifications. In other words filter for data that should be there and ignore everything else.
How to Protect Yourself • Definitions for positive filtering: • Data type (string, integer, real, etc.) • Allowed character set • Min and max field length • Null check (are nulls allowed?) • Required parameter check • Numeric range check • Is this a member of an enumeration • Regex patterns
How to Protect Yourself • Third party Unvalidated Input Protection: • Web application firewalls • Configurable security “device” used to do input validation. • Is not called from the application nor is it part of the application. • Black-box style security.
How to Protect Yourself • Third party Unvalidated Input Protection continued: • The OWASP Filters Project • Project is designed to be a group of re-usable filters for input validation • The Stinger HTTP request validation engine is an example of this implementation developed by OWASP for J2EE validation. • http://www.owasp.org/index.php/OWASP_Stinger_Project • Other projects are in the works (PHP for example).
How to Protect Yourself • Be very careful about what you put into web forms • Use hidden inputs sparingly and smartly • Don’t always trust cookie data • Try to store persistent data other ways • Session • Database
Unvalidated Input Demo • Demo will show two simple vulnerabilities: • SQL Injection Flaws • Cross Site Scripting Flaws