OWASP Top Ten Unvalidated Input By Yvan Boily
OWASP Top Ten Unvalidated Input By Yvan Boily March, 2005 yboily@gmail. com OWASP 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 http: //www. owasp. org
Agenda < The OWASP Top Ten < Issue #1: Unvalidated Input 4 What is unvalidated input? 4 Why it is an issue? 4 How does it work? 4 How does it happen? 4 How can we solve the problem? <Discussion Discuss anything during the presentation! 29 slides. OWASP 2
OWASP Top 10 – What is it? <Top 10 Web Application Security Vulnerabilities 4 A list of the 10 most severe security issues 4 Updated on a yearly basis 4 Address issues with applications on the perimeter 4 Growing industry acceptance § Federal Trade Commission (US Gov) § US Defense Information Systems Agency § VISA (Cardholder Information Security Program) 4 Strong push to present as a standard OWASP 3
OWASP Top 10 – What are the issues? <Current Top Ten Issues A 01. A 02. A 03. A 04. A 05. A 06. A 07. A 08. A 09. A 10. Unvalidated Input Broken Access Controls Broken Authentication and Session Management Cross Site Scripting Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management OWASP 4
OWASP Top 10 – Learning about them <Addressing the Top Ten 4 In Presentation (Future Meetings) § One hour presentations will be hosted on each topic 4 On the Mailing List § The mailing list is a public forum, and as such is suitable for asking questions in general § Specific application issues should be discussed in private, especially with regards to business projects 4 Focus Groups § If there is sufficient interest, focus groups can be created to discuss specific issues (e. g. Data Validation, Session Management, Access Controls) OWASP 5
Issue #1: Unvalidated Input <What does it mean? 4 From the OWASP Top 10: A 1 Unvalidated Input Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application OWASP 6
What does it all mean? <Data submitted via HTTP request is not sanitized before being used by the application <This includes: 4 Constructing dynamic SQL queries (SQL Injection) 4 Path/Filename resolution (Directory Traversal) 4 Displaying data to other users (Cross Site Scripting) <Other Types of Attacks: 4 Buffer over flows 4 Cookie poisoning 4 Format string attacks 4 Field manipulation OWASP 7
Why is it an issue? <Unvalidated Input is the #1 issue 4 User input (i. e. Request variables) are the only interaction a user has with a web application 4 Allows untrusted data to be control execution path of a (reasonably) trusted system 4 Web Application Input is used for security mechanisms § Identification, Authorization & Access Controls § Session & Credential Management 4 Depending on the platform § Can cause denial of service § Permit remote execution § Allow theft of information OWASP 8
Why is it so critical? <Serious impact on A-I-C Components 4 Availability § Malicious input can cause an server to lock up, crash, restart, or simply slow down (Buffer Overflows, Denial of Service) 4 Integrity § Malicious input can cause data to be deleted, modified, or corrupted (SQL Injection, Cross Site Scripting) 4 Confidentiality § Malicious input can be used to circumvent privacy and confidentiality controls causing information leakage and disclosure (Session Hijacking, SQL Injection) OWASP 9
How does it work? <Tainted Data Attacks 4 Attempts by attackers to compromise web applications 4 Some common web attacks § Cross Site Scripting § SQL Injection Attacks § Hidden Field Manipulation 4 All use tainted data to alter execution paths, modify data, or bypass access controls 4 Many, many types of attacks; as varied as the type of data you can submit to a web server OWASP 10
What is Cross Site Scripting? <Cross Site Scripting (XSS) 4 Attack which allows malicious user to § Embed control characters, markup language, etc into data fields § This then impacts the layout and functionality of the end user interface 4 Two primary types of attacks § Stored XSS Attack § Reflective XSS Attack OWASP 11
What types of XSS attacks exist? < Stored Cross Site Scripting Attack 4 The user submits data to a site which is presented to other users without modification 4 Allows execution of Javascript code, injection of malicious HTML tags (e. g. Internet Explorer IFRAME vulnerability) 4 Allows user to embed Active. X, Java, etc objects which may compromise security of the end user < Reflective Cross Site Scripting Attack 4 The user submits data which is presented to users via another media (e. g. Email) or web service 4 Allows the attacker to inject data that will impact end user applications (Outlook/Outlook Express) OWASP 12
What is SQL Injection? <SQL Injection Attack 4 Malicious input is used to assemble SQL Queries; when executed, these queries allow an attacker to modify the operation of the SQL query 4 Very common attack 4 A number of ways to resolve the issue 4 Proper data validation is a partial approach 4 Many, many papers have been written on the topic OWASP 13
What is Hidden Field Manipulation? <Hidden Field Manipulation 4 Form fields used to control execution are exchanged between the client and server 4 Even though data is received from the client it is trusted by the server 4 Easy to modify for even a basic attacker 4 Commonly affected scripts: § § Guestbook components Web counters Email and Feedback forms Opinion poll forms OWASP 14
How does it work – Let’s see! <Web. Goat Examples 4 Using Web. Goat § Open source educational tool from OWASP – http: //www. owasp. org/software/webgoat. html § § Provides training on security issues How to exploit them (basic cases) How to find them How to correct them 4 Vulnerabilities in Action § Cross Site Scripting § Hidden Field Manipulation OWASP 15
How does it happen? <Typically a design flaw 4 No design level consideration was made for malicious input <Lack of data validation processes 4 Missing server side validation 4 Improper canonical conversions 4 Client side validation 4 This is not an exhaustive list! OWASP 16
How does it happen? <Missing server side validation 4 The number one reason these vulnerabilities exist 4 Many software developers are unaware 4 Not a recognized issue until recent times 4 Affects many applications § § Oracle Reports Server SAP Applications Squirrel. Mail php. BB (Santy Worm!) 4 Not going to go away § Requires awareness of the problem § Requires technical controls OWASP 17
How does it happen? <Improper canonical conversions 4 Data submitted to Web Applications can come in a number of formats, Unicode (UTF-[7, 8, 16]), HTML Entities, Binary data, Hex Encoding, etc 4 Conversion errors abound! § Common libraries used often have errors § Custom written code is notoriously unreliable § Internationalization and Localization are growing fields 4 Many, many ways to inject XSS attacks § http: //www. shocking. com/~rsnake/xss. html § One site documents >50 ways to set up XSS attacks OWASP 18
How does it happen? < Client side validation 4 Many developers offload the processing cost of data validation to the end user (i. e. client) 4 Advantages § § Fewer server requests results in less bandwidth consumption Server does not experience load associated with complex validation routines 4 Disadvantages § It does not work! 1. Data validation performed on the client is optional – Requires browser support (i. e. Java/VB script) 2. Very few attackers will use a web browser to attack a system – More commonly will use proxy servers (Paros, Web. Scarab, etc) – Advanced attackers will use protocol level tools (curl, etc) OWASP 19
How do we solve the problem? <Several Solutions are available: 4 Fix the code! § Suitable for open source or in-house projects 4 Application Layer Firewalls § Suitable for closed applications, IDS/IPS , or other requirements 4 Trusted Environments § Optimal solution; typically used for paranoid environments – i. e. Military systems, 3 -letter agencies, etc § Gaining industry acceptance OWASP 20
Solve the problem – Fix the code! <Data Validation 4 Implementing data validation within applications is a non-trivial task, but it is not a show-stopper 4 Tools such as regular expressions allow powerful data validation techniques to be developed rapidly 4 Not a viable solution for 3 rd party or closed source software § Vendors control development cycles, including patching § No industry standard disclosure practices § Reactive (Crack & Patch) security is not good security! OWASP 21
Solve the problem – Fix the code! <Two major data validation approaches 4 Negative Matching § Filter out input which meets a specific criteria § E. g. if data contains a quotation mark, filter it! § Not very effective – Too many False positives – Maintaining signatures is time consuming 4 Positive Matching § Pass in data which meets a specific criteria § E. g. if data matches this regex, allow it § Highly effective – Ensures data exists in a normal form – Easier to describe good data than it is to describe bad data OWASP 22
Solve the problem – Fix the code! <Available Toolkits 4 Java J 2 EE § Struts Validator Framework § Springs Framework Validation classes § OWASP Stinger Project 4. NET Validation § Web Forms (Validation Controls) 4 Other Languages § Regular Expressions § Basic data validation techniques – Type, range, enumeration checking OWASP 23
Solve the problem – Use a device! <Application Layer Firewalls 4 Two major approaches (again) § Proxies – Software such as mod_security designed to filter out requests containing signature based data – ‘Easy’ to add on to existing infrastructure § Application Layer Firewalls – Devices provided by vendors to perform deep-packet inspection – Solutions provided by » Fortinet » Mc. Afee » Many, many vendors offer solutions – Can be used in detective or preventative roles OWASP 24
Solve the problem – Use a device! <Application Layer Firewalls 4 mod_security § Standalone software or apache module § Provides HTTP validation § If used in tandem with Apache, it can be used with SSL – SSL connections must otherwise be decrypted § Provides – – Request filtering Anti-evasion Payload analysis Audit logging § GPL Open Source – Free to use, free to modify OWASP 25
Solve the problem – Use a device! < Application Layer Firewalls 4 Vendor Solutions 4 Advantages § Support! § Easy to illustrate ‘due diligence’ § Easier than installing open source tools 4 Disadvantages § § § As many solutions as there are vendors Combined IDS/IPS functionality Signature based, may not be customizable for specific applications Subscription and licensing fees can be prohibitive Typically require dedicated devices adding another point of failure OWASP 26
Fix the problem – Trusted Environments! <Trusted Environments 4 Huh? § Most people don’t know about them § Many operating systems have related features § Extremely challenging to work with 4 Trusted Environments § Systems which have such strong controls that even if hacked, they are immutable § Examples – Mandatory Access Controls – Trusted Execution Systems – Jail/Container/Prison environments OWASP 27
Fix the problem – Trusted Environments! <Trusted Environments 4 Mandatory Access Controls § Stronger access control systems typically oriented to greater protection of one of confidentiality, integrity, or availability 4 Trusted Execution Systems § Systems which prevent execution of untrusted software – Microsoft Authenticode is a poor example – Other systems emerging on Linux, Free. BSD 4 Jails/Containers/Prisoned environments § Systems which provide heavily controlled environments for specific applications – Examples include chroot, Free. BSD Jails, Solaris Containers – Vary widely with operating systems – Typically very complex to securely implement OWASP 28
Discussion <Recommended Reading 4 OWASP Top Ten § http: //www. owasp. org/documentation/topten. html 4 OWASP Guide to Building Secure Web Applications § http: //www. owasp. org/documentation/guide. html 4 How to Build an HTTP Request Validation Engine for your J 2 EE Application § http: //www. owasp. org/columns/jwilliams 2. html 4 Have your cake and eat it too (. NET) § http: //www. owasp. org/columns/jpoteet 2. html OWASP 29
- Slides: 29