Module 3: Validating User Input

Chia sẻ: Mai Phuong | Ngày: | Loại File: PDF | Số trang:68

Thêm vào BST

Báo xấu

112
lượt xem 6
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

This module provides students with an explanation of how to manage user input in a Web application in a secure way. The methods for checking user input, and a discussion of the consequences of not performing those checks, are the focus of this module. After completing this module, students will be able to secure their Web applications by validating user input.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Module 3: Validating User Input

Module 3: Validating User Input Contents Overview 1 Lesson: User Input 2 Lesson: Types of User Input Attacks 8 Lesson: Performing Validation 23 Lesson: Revealing As Little Information As Possible to Users 38 Review 46 Lab 3: Verifying User Input 48
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.  2002 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, ActiveX, Active Directory, Authenticode, Hotmail, JScript, Microsoft Press, MSDN, PowerPoint, Visual Basic, Visual C++, Visual Studio, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Module 3: Validating User Input iii Instructor Notes Presentation: This module provides students with an explanation of how to manage user input 90 minutes in a Web application in a secure way. The methods for checking user input, and a discussion of the consequences of not performing those checks, are the focus Lab: of this module. After completing this module, students will be able to secure 30 minutes their Web applications by validating user input. After completing this module, students will be able to: ! Identify the sources of user input in a Web application. ! Describe the different types of user input attacks. ! Implement user input validation. ! Use communications analysis and coding best practices to avoid providing information that can be used for security attacks. Required materials To teach this module, you need the following materials: ! Microsoft® PowerPoint® file 2300A_03.ppt ! HTML and Flash animation files: 2300A_03_A05_1640.htm, 2300A_03_A05_1640.swf Preparation tasks To prepare for this module: ! Read all of the materials for this module. ! Complete the lab. ! Practice the steps for the demonstrations. ! Review the multimedia demonstration. ! Read the TechNet articles, “Cross-site Scripting Overview,” “Cross-Site Scripting Security Exposure Executive Summary,” and “Cross-Site Scripting: Frequently Asked Questions,” which are available at http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/ security/topics/csoverv.asp. ! Read the Microsoft MSDN® article, “HOWTO: Prevent Cross-Site Scripting Security Issues in CGI or ISAPI,” which is available at http://support.microsoft.com/directory/ article.asp?ID=KB; EN-US;Q253165&. ! Read the MSDN article, “RequiredFieldValidator Control,” which is available at http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/cpgenref/html/cpconrequiredfieldvalidatorcontrol.asp. ! Read the MSDN article, “RegularExpressionValidator Control,” which is available at http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/cpgenref/html/cpconregularexpressionvalidatorcontrol.asp. ! Read Chapter 12, “Securing Against Attack,” in Designing Secure Web- Based Applications for Microsoft Windows 2000 by Michael Howard (Redmond, Microsoft Press®), 2000.
iv Module 3: Validating User Input How to Teach This Module This section contains information that will help you to teach this module. Lesson: User Input This section describes the instructional methods for teaching each topic in this lesson. Identifying the Sources Discuss the various sources that can be used to accept user input in a Web of User Input application. Explain how these sources can be maliciously used by an attacker to enter a Web application. Why Validate User Discuss how accepting all user input without performing any validation can be Input? detrimental to the Web application. Types of User Input User input can be validated at the server side or the client side. Explain to the Validation class that although performing client-side validation is important because it reduces round-trips to Web server, it is not secure. Therefore, as a best practice, the validation must also be performed at the server side. Multimedia: Client-Side This animation shows the procedure for client-side and server-side processing. and Server-Side The sequence of steps that occur during this multimedia demonstration is as Processing follows: 1. The client requests a Microsoft ASP.NET page from the Web server. 2. The server returns a page that contains Hypertext Markup Language (HTML) and script to the client. The page includes TextBox and Button controls. The page also contains client-side script that validates the contents of the text box. 3. If the user types invalid information in the text box, the client-side script generates a message box. Because no information has been sent to the server, client-side processing reduces network traffic and response times. 4. The user corrects the information in the text box, and then clicks Submit. 5. The information is validated at the client side and is then sent to the server, where server-side processing can occur. 6. The server repeats the validation and stores the information from the text box in a database. Because the client-side script cannot access server resources, server-side processing offers a greater range of flexibility in data processing.
Module 3: Validating User Input v Lesson: Types of User Input Attacks This section describes the instructional methods for teaching each topic in this lesson. URL Format Attacks Explain how canonical Uniform Resource Locator (URL) formats can become a weakness for a Web application for an attack. Canonicalization mistakes are caused the Web application implements security decisions based on a name (such as a file name, a directory name, or a URL) and more than one representation of the resource name exists, which can lead to the security check being bypassed. HTTP Cookie Attacks Explain the two types of cookies that can be used in a Web application to store data: persistent and session. Emphasize that cookies can be modified, and therefore, storing sensitive data in a cookie can prove to be dangerous for a Web application. HTTP Header Attacks Emphasize that Hypertext Transfer Protocol (HTTP) header values can be changed and therefore should not be trusted. Form Data Attacks Discuss the vulnerabilities that exist in accepting user input using a form. Emphasize the best practices that must be used before accepting user input. Demonstration: A Form Use this demonstration to explain how data can be modified maliciously at the Data Attack client side. Script Command This topic uses an animated slide to show how a script command injection Injection Attacks attack occurs in four steps. Cover the explanation for the corresponding step as it appears on the slide. Demonstration: A Script Use this demonstration to explain how a script command injection attack is Command Injection performed on a Web application. Attack Lesson: Performing Validation This section describes the instructional methods for teaching each topic in this lesson. ASP.NET Validation ASP.NET includes new functionality named Web Server Controls, which Controls contains five controls that can be used to validate user input. Use examples to explain when these Web Server Controls should be used. Using ASP.NET This topic describes the common properties of Web Server Controls and how Validation Controls these controls help in preventing user input attacks. Demonstration: Using Use this demonstration to explain how a RequiredFieldValidator control can Validation Controls be used to verify that a TextBox control does not accept blank entries from users. Regular Expressions Explain the need for regular expressions and briefly discuss the elements of regular expressions that are covered in this topic. Inform students that this topic covers only the commonly used regular expression elements and that the complete list of regular expression elements can be located in Microsoft Visual Studio® .NET Help. Open Visual Studio .NET Help and search for regular expressions. Open the page that provides a comprehensive list of regular expression elements and show that list to the students in the class.
vi Module 3: Validating User Input Using Regular Explain how students can use regular expressions to secure their ASP.NET Expression Validation in Web applications by matching the string with the pattern that is defined in ASP.NET regular expressions. ASP.NET uses two different classes that are used for creating and using regular expressions: RegularExpressionValidator and Regex. Show the code examples for implementing both of these classes by clicking the code example link that is provided on the bottom of the slide. Using Regular Explain how students can use regular expressions to secure their Active Server Expression Validation in Pages (ASP) Web applications by matching the string with the pattern that is ASP defined in regular expressions. Use the code example link that is provided on the bottom of the slide to show the two different implementations of regular expressions in ASP Web applications. Demonstration: Using In this demonstration, students will see how a regular expression can be used to Regular Expressions verify that an input control has a properly formatted social security number. Practice: Break This In this practice, students will attempt to find all of the possible security Page weaknesses on an existing Web page. Lesson: Revealing As Little Information As Possible to Users This section describes the instructional methods for teaching each topic in this lesson. Concealing Private and Discuss in the class how revealing information to users can benefit attackers. Implementation Explain why it is important to conceal private and implementation details in the Information messages that are sent back to users. You can use the example that a Web application might use a user logon name to greet users, which is a bad security practice. If the students need to provide personalization in their Web application, they should use the user’s first name or nickname to address the user, rather than using the user’s logon name. Providing Feedback to A Web application interacts with users to provide them feedback on their Users actions. Feedback is provided under normal conditions, such as a verification message and a success message, or under error conditions, such as an error message. Emphasize to the class that the feedback message should be generic, and concise. Obscuring Error Details Detailed error messages can help attackers to find out the implementation from Users details of an organization’s Web application and can also help the attackers to determine the vulnerabilities in the Web application. Therefore, it is important to obscure error details in the messages. This topic covers obscuring error details in ASP Web applications and ASP.NET Web applications. Emphasize to the class that detailed error messages are helpful during Web application development because they help Web developers in debugging. Therefore, most of the Web applications may be configured to display detailed error messages during the Web application development phase. However, it is then important to ensure that detailed error messages are obscured before moving the Web application to the production server. Putting Literal Values in Discuss how storing literal values in script or source code can be dangerous for Secured Files a Web application. Inform students that they must never store the literal values in script or source code. Instead, they must store literal values in secured configuration files or in the Microsoft Windows® registry.
Module 3: Validating User Input vii Lab 3: Verifying User Input Introduce the lab by stating that the labs for Course 2300, Developing Secure Web Applications, create two Web applications, TailspinToys and TailspinToysAdmin. By accessing the TailspinToys Web application, users will be able to get a list of the products that are created by Tailspin Toys, and resellers will be able to view the status of their orders. By accessing the TailspinToysAdmin Web application, employees will be able to create new reseller accounts and update the status of reseller orders. This lab edits the logon page of the Tailspin Toys Web application to use a strong password. For this lab, a strong password must have at least one number, one lowercase letter, and one uppercase letter, and must be at least 8 characters long, but not more than 20 characters long. Customization Information This section identifies the lab setup requirements for a module and the configuration changes that occur on student computers during the labs. This information is provided to assist you in replicating or customizing Microsoft Official Curriculum (MOC) courseware. Lab Setup To complete this lab, you will use the following Visual Studio .NET solutions and projects: ! Two Visual Studio .NET solutions, 2300Labs and 2300Labs.NET, which are in the \My Documents\Visual Studio Projects folder. ! Four Web application projects, TailspinToys, TailspinToysAdmin, TailspinToys.NET, and TailspinToysAdmin.NET, which are in the \Inetpub\wwwroot folder. You will use the 2300Labs solution and the TailspinToys and TailspinToysAdmin Web applications to complete the ASP exercises in this lab. You will use the 2300Labs.NET solution and the TailspinToys.NET and TailspinToysAdmin.NET Web applications to complete the ASP.NET exercises in this lab.
viii Module 3: Validating User Input You must assign each student a TailspinToys account to use for the labs. The following is a list of the accounts that exist in the TailspinToys database. These names correspond to the student computer names, so you can tell each student to use his or her respective user name when accessing the TailspinToys Web application throughout the labs in the Course 2300, Developing Secure Web Applications. User name Password Acapulco P@ssword8 Auckland P@ssword8 Bangalore P@ssword8 Bonn P@ssword8 Brisbane P@ssword8 Caracas P@ssword8 Casablanca P@ssword8 Denver P@ssword8 Glasgow P@ssword8 Khartoum P@ssword8 Lima P@ssword8 Lisbon P@ssword8 London P@ssword8 Manila P@ssword8 Miami P@ssword8 Montevideo P@ssword8 Moscow P@ssword8 Nairobi P@ssword8 Perth P@ssword8 Santiago P@ssword8 Singapore P@ssword8 Stockholm P@ssword8 Suva P@ssword8 Tokyo P@ssword8 Tunis P@ssword8 Vancouver P@ssword8 Lab Results There are no configuration changes on student computers that affect replication or customization.
Module 3: Validating User Input 1 Overview ! User Input ! Types of User Input Attacks ! Performing Validation ! Revealing As Little Information As Possible to Users *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In this module, you will learn how to manage user input in a secure way. An important security best practice that you must follow is to never trust user input. If you trust a user’s input in a Web application, you are making your Web application vulnerable to attack. If your Web application accepts input from users, it is imperative that the Web application validate the input before processing it. The methods for checking user input, and an explanation of the consequences of not performing those checks, are the focus of this module. Objectives After completing this module, you will be able to: ! Identify the sources of user input in a Web application. ! Explain the different types of user input attacks. ! Implement user input validation. ! Use communications analysis and coding best practices to avoid providing information that can be used for security attacks. Note The code samples in this module are provided in both Microsoft® Visual Basic® .NET and C#.
2 Module 3: Validating User Input Lesson: User Input ! Identifying the Sources of User Input ! Why Validate User Input? ! Types of User Input Validation ! Multimedia: Client-Side and Server-Side Processing *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In this lesson, you will learn about the sources of user input in a Web application. You will also be introduced to the reasons for validating user input and the various ways to perform input validation. Lesson objectives After completing this lesson, you will be able to: ! Identify the sources of user input. ! Decide when user input validation is necessary. ! Describe the different types of user input validation methods.
Module 3: Validating User Input 3 Identifying the Sources of User Input ! URLs " Request individual resources of a Web application ! GET data " Parameters and values that a client passes to a Web application to satisfy a GET request ! POST data " Parameters and values that a client passes to a Web application to satisfy a POST request ! Cookies " Store data on the client computer ! HTTP headers " Provide numerous HTTP request header values to describe the client environment to the server *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction All Web applications receive most of their input from users and then perform some actions on that user input. The user input can be as simple as Hypertext Transfer Protocol (HTTP) GET requests for pages or can include uploaded data from the user. The user input has five forms: Uniform Resource Locators (URLs), GET data, POST data, cookies, and HTTP headers. URLs URLs are used to request the individual resources of a Web application. URL formats can range from simple .htm file requests to complicated formats that include GET parameters, as shown in the following example: http://www.tailspintoys.com/products.aspx?id=4&view=detail The URL shown in the preceding example passes two GET parameters, id and view, with values 4 and detail, respectively, to the Web application. GET data GET data contains parameters and values that a user passes to a Web application to satisfy a GET request. These parameters and values appear in the URL for the GET request. Often, a Hypertext Markup Language (HTML) form is used to request the data from the user. POST data POST data contains parameters and values that a client passes to a Web application to satisfy a POST request. These parameters and values are sent in the body portion of the request and are not visible in the URL. Often, an HTML form is used to request the data from the user.
4 Module 3: Validating User Input Cookies Cookies are used to store data on the client computer. A cookie is associated with a URL. A server can request a browser to store particular data in a cookie, for a URL, by using an HTTP Set-Cookie header. If a client browser has a cookie that is already associated with a URL, each time a request is made to that URL, the client browser includes the cookie as the part of the HTTP request. Cookies can also be read and written from the HTML script that runs on the client browser. HTTP headers Client browsers provide numerous HTTP request header values to describe the client environment to the server. These request headers include the fields that are shown in the following table. HTTP request header name Description Authorization Contains the authentication credentials for the requesting user. From Contains the e-mail address of the requesting user. Referer Contains the address of the resource where the current URL was obtained. User-Agent Contains the information about the requesting user’s browser and local computer environment.
Module 3: Validating User Input 5 Why Validate User Input? ! User input can be used to attack a Web application to: " Reveal implementation details " Create malicious data " Execute malicious script " Access restricted resources ! To avoid a user input attack: " Do not accept user input without validating " Define valid input and write code to accept data within a valid range *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction User input can potentially be used to attack a Web application. The reason for the attack can be to reveal implementation details about the Web application, to cause the Web application to create malicious data, to execute malicious script on the Web application, or to access restricted resources on the Web application. Any implementation details that are revealed can then be further used to attack the Web application repeatedly. Malicious data can be used to gain unauthorized access to the Web application. Malicious script can be used to manipulate the Web application or to attack the users of the Web application. User input attacks can also target restricted resources to gain access to secured information on the Web application. Countermeasures You must deal with all user input as if it is potentially part of an attack. against user input attack Whenever you receive input from the user, you must clearly define a narrow range of valid input values. You then must write code to accept only data within that valid range. It is important to validate input by allowing only the known valid values, rather than explicitly rejecting known invalid values. In the former case, you are guaranteed to reject all invalid formats, whereas in the latter case, you are rejecting only those invalid formats that you are aware of.
6 Module 3: Validating User Input Types of User Input Validation ! Client-side validation " Executes validation code, in a script, within the user’s browser " Minimizes server round-trips for data validation ! Server-side validation " Executes data validation code on the server " Validation errors need to be sent back to the client, resulting in more server round-trips ! ASP.NET validation controls " Support both client-side and server-side validation *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Validation code that is needed to check the user input can be executed either at the client side or at the server side. Client-side validation Client-side validation code is contained in a script, which is included with the HTML that is sent to the client. This client-side validation code then runs on the browser on the client computer. The client-side validation code validates the user data, typically from field values, before sending the data to the server. Any errors in the validation must be resolved by the user before the data is sent to the server. Client-side validation code minimizes server round-trips for data validation. Server-side validation Server-side validation code runs on the Web application server, and it validates the data that the user sent as part of a request. Any validation errors necessitate sending a response, with the corresponding validation error messages, to the client. Server-side validation requires several server round-trips for data validation errors. Microsoft ASP.NET includes special Web controls for validation. One of the best features of these controls is that they support both client-side and server- side validation. If the client browser supports script execution, the ASP.NET validation controls generate the HTML that includes client-side validation script. Regardless of the client browser capabilities, the ASP.NET validation controls also always perform validation at the server side.
Module 3: Validating User Input 7 Multimedia: Client-Side and Server-Side Processing *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction This multimedia presentation describes the differences between client-side and server-side processing.
8 Module 3: Validating User Input Lesson: Types of User Input Attacks ! URL Format Attacks ! HTTP Cookie Attacks ! HTTP Header Attacks ! Form Data Attacks ! Demonstration: A Form Data Attack ! Script Command Injection Attacks ! Demonstration: A Script Command Injection Attack *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In this lesson, you will learn about the types of user input attacks that you must secure Web applications against. Lesson objectives After completing this lesson, you will be able to: ! Describe the types of user input attacks against a Web application. ! Use best practices for securing a Web application against user input attacks. ! Avoid script command injection attacks.
Module 3: Validating User Input 9 URL Format Attacks ! Different URL formats are referred to as canonical forms ! Canonical forms for URLs can become a weakness for a Web application ! ::$DATA format " Returned the script source instead of the HTML response http://www.tailspintoys.com/default.asp::$DATA http://www.tailspintoys.com/default.asp::$DATA ! Dotless IP Addresses " Previously considered part of intranet http://031713501415 http://031713501415 *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction URLs are used to name resources within a Web application, and they can have many formats. You have already learned about the URL format that contains GET parameters at the end. Different URL formats are referred to as canonical forms. A canonical form for a name is a standard or conventional format for that name. For example, a computer name has three canonical forms: the Domain Name System (DNS) name (for example, tailspintoys.com), the network basic input/output system (NetBIOS) name (for example, \\tailspintoys), and the Internet Protocol (IP) address (for example, 192.168.0.1). The term canonicalization can also be used for referring to the process of transferring a name to a canonical form. Canonical forms for URLs can become a weakness for a Web application because some URL formats are vulnerable, and therefore, can become a security threat. Attackers can exploit the URLs to gain access to the Web application’s resources. For example, if you allow parent paths or special characters at the end of the URL, an attacker might enter one of the following URLs and gain access to a command prompt or the c:\boot.ini file: ! http://www.tailspintoys.com/scripts/../../winnt/system32/cmd.exe ! http://www.tailspintoys.com/samples/showcode.asp?file=../../../boot.ini ::$DATA Microsoft Internet Information Services (IIS) version 4.0 and earlier had a weakness that allowed URLs ending in special characters or character sequences to return the script source instead of the HTML response. The URLs had formats such as: ! http://www.tailspintoys.com/default.asp::$DATA ! http://www.tailspintoys.com/default.asp. Notice the trailing "::$DATA" in the first example and the trailing "." in the second example. These weaknesses permitted anyone with a browser to view the script source for a Web application.
10 Module 3: Validating User Input Dotless IP addresses An IP address has two forms: the dotted notation (for example, 192.158.0.1) and the dotless notation (for example, 3231580161). The canonical form for an IP address is the dotted notation, because it is more easily read by humans. The dotless notation is a valid form, but it is not a canonical form. To convert a dotted IP address of the form a.b.c.d to the dotless form, use the following formula: dotlessIP = (a * 16777216) + (b * 65536) + (c * 256) + d Microsoft Internet Explorer version 4 and earlier had a vulnerability with dotless IP addresses. Those versions of Internet Explorer considered a dotless IP address to be part of the intranet zone, and therefore, ran that address under more lax security restrictions. Microsoft Internet Explorer version 5 and later consider dotless IP addresses to be part of the Internet zone.
Module 3: Validating User Input 11 URL Format Attacks (continued) ! Parent paths " Can access files outside a virtual directory http://www.tailspintoys.com/scripts/../../winnt/! http://www.tailspintoys.com/scripts/../../winnt/! system32/cmd.exe system32/cmd.exe ! Do not use a parent path in a Web application; instead, use an absolute path ! Configure IIS to disable parent paths ! Canonicalize URLs " Parse the URL into a standard format *****************************ILLEGAL FOR NON-TRAINER USE****************************** Parent path Parent path URLs contain ".." characters, which refer to the parent folders of a Web application. Parent path URLs can be used to navigate between virtual roots or folders that are outside a virtual directory in IIS. Parent paths can also be used to attack a Web application. There are many forms of URLs that use parent paths to access files that are outside a virtual root. The following URL attempts to access the Microsoft Windows® 2000 command prompt: http://www.tailspintoys.com/scripts/../../winnt/system32/cmd.exe The preceding URL assumes that the /scripts folder is in the default location, namely C:\Inetpub\wwwroot. This relative URL is then trying to access cmd.exe within its default location, namely C:\WinNT\System32\. This URL format can also be used to send arguments and commands to cmd.exe. IIS 4.0 included a sample application that would return the source code of a file to the client. Parent paths, as shown below, can also be used to exploit such applications: http://www.tailspintoys.com/samples/showcode.asp?file=../../../boot.ini
12 Module 3: Validating User Input Disable parent paths Do not use parent paths within your Web application. Instead, use absolute paths to reference Web pages. To secure IIS version 5.0 against parent path attacks, you should configure IIS to not permit ".." to appear in URLs. To configure a virtual root directory: 1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager. 2. Right-click the virtual root directory, and then click Properties. 3. In the Properties dialog box, on the Virtual Directory tab, click Configuration. 4. In the Application Configuration dialog box, on the App Options tab, clear the Enable parent paths check box, as shown in the following illustration, and then click OK. 5. Click OK to close the Properties dialog box. Canonicalize URLs In the rare case when you write code that makes execution choices based on the format of a URL, you must first parse the URL into a standard format. Then, you can reject any URLs that cannot be parsed into that format.