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

Module 3: Validating
User Input

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

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.

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

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.
!

Lab:
30 minutes
Required materials
Preparation tasks
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.
Discuss the various sources that can be used to accept user input in a Web
application. Explain how these sources can be maliciously used by an attacker
to enter a Web application.
Discuss how accepting all user input without performing any validation can be
detrimental to the Web application.
User input can be validated at the server side or the client side. Explain to the
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.
This animation shows the procedure for client-side and server-side processing.
The sequence of steps that occur during this multimedia demonstration is as
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

representation of the resource name exists, which can lead to the security check
being bypassed.
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.
Emphasize that Hypertext Transfer Protocol (HTTP) header values can be
changed and therefore should not be trusted.
Discuss the vulnerabilities that exist in accepting user input using a form.
Emphasize the best practices that must be used before accepting user input.
Use this demonstration to explain how data can be modified maliciously at the
client side.
This topic uses an animated slide to show how a script command injection
attack occurs in four steps. Cover the explanation for the corresponding step as
it appears on the slide.
Use this demonstration to explain how a script command injection attack is
performed on a Web application.
Lesson: Performing Validation
This section describes the instructional methods for teaching each topic in this
lesson.
ASP.NET includes new functionality named Web Server Controls, which
contains five controls that can be used to validate user input. Use examples to
explain when these Web Server Controls should be used.
This topic describes the common properties of Web Server Controls and how
these controls help in preventing user input attacks.
Use this demonstration to explain how a RequiredFieldValidator control can
be used to verify that a TextBox control does not accept blank entries from
users.
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

Web applications by matching the string with the pattern that is defined in
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.
Explain how students can use regular expressions to secure their Active Server
Pages (ASP) Web applications by matching the string with the pattern that is
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.
In this demonstration, students will see how a regular expression can be used to
verify that an input control has a properly formatted social security number.
In this practice, students will attempt to find all of the possible security
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.
Discuss in the class how revealing information to users can benefit attackers.
Explain why it is important to conceal private and implementation details in the
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.
A Web application interacts with users to provide them feedback on their
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.
Detailed error messages can help attackers to find out the implementation

Providing Feedback to
Users
Obscuring Error Details
from Users
Putting Literal Values in
Secured Files
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:
!

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
!

The code samples in this module are provided in both Microsoft
®

Visual Basic
®
.NET and C#.

Introduction
Ob
jectives
Note
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
******************************
In this lesson, you will learn about the sources of user input in a Web

!
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
******************************
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 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 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

user’s browser and local computer environment.

Cookies
HTTP headers
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

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
******************************
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 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.
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
******************************
In this lesson, you will learn about the types of user input attacks that you must
secure Web applications against.
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.

ILLEGAL FOR NON
-
TRAINER USE
******************************
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

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:
!

Parent paths
"
Can access files outside a virtual directory
!
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
http://www.tailspintoys.com/scripts/../../winnt/
!
!!
!
system32/cmd.exe
http://www.tailspintoys.com/scripts/../../winnt/
!
!!
!
system32/cmd.exe

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
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

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.

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.
Disable parent paths
Canonicalize URLs
Module 3: Validating User Input 13 HTTP Cookie Attacks
!
Two types of cookies: persistent and session
!
Persistent cookies can be edited with Notepad.exe
"
C:\Documents and Settings\username\Cookies
!
All cookies can be edited in client-side script
"
document.cookie is in JScript
!
Do not store sensitive data in a cookie
"
Instead store a lookup key
!
Encrypt cookie data if necessary

represent the data. Some cookie formats are obvious to determine, whereas
other formats are more opaque. If you can determine the format, you can then
edit the data.
Both session and persistent cookies can be read and modified in HTML script
by using the cookie property of the document object in Microsoft JScript
®
.
Introduction
Types of cookies
Vulnerabilities
14 Module 3: Validating User Input Do not store sensitive data in cookies. Any data in a cookie can potentially be
compromised.
Here is an example that illustrates the weakness of storing data in a cookie. A
catalog Web application might store the entire user shopping cart in a persistent
cookie. The shopping cart includes product prices and the Web application does
not validate these prices. Using Notepad.exe, a malicious user could change the
price of any product in his or her shopping cart, and those new prices would
then be accepted. Malicious users could effectively give themselves any
discount that they want on any of the Web application’s products.
Instead of storing sensitive data in a cookie, store a lookup key, such as a
globally unique identifier (GUID), and keep the sensitive data on the server, in
a file, or in a database. You can then use the lookup key from the user request to
find the sensitive data in your database. If users change the lookup key in the
cookie, they will lose the cookie data instead of causing malicious changes.
You can also encrypt cookie data before sending it to the client browser.
Encrypting cookie data renders the cookie data opaque to the client.


always refer to their Web application.
Introduction
16 Module 3: Validating User Input Form Data Attacks
!
Form values
"
GET method includes the field values in the URL
"
POST method includes the field values in the body of the request
!
Form fields
"
All form fields and field names are visible in source code
"
Hidden fields are not secure
!
Validate field values and field names
!
Validate field value type and length
!
Use forms for the minimum required data

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************

All form fields and their names are visible in the HTML source of a page. Any
hidden form fields can also be accessed in the source. Form field names and
values can be manually edited.
When form values are sent to the Web server by using a GET or POST method,
form values can easily be edited by anyone. Any user of the Web application
can save the HTML response that contains the form to a file. A user can then
manually modify that HTML file before submitting the data.
The types and lengths of form fields can be modified by attackers. If a Web
application uses a particular data type for a form field, an attacker can attempt
to use other data types to attack. For example, an attacker can save the form
locally and change the values for the form field to be other than what is
specified in the Web application. Similarly, if a Web application has a
particular maximum length that is assigned for a form field, an attacker can
save the form and enter a value that is longer than the specified maximum
length to attack a Web application.
You must validate the field values in a form for the GET or POST method. If
you create scripts from field names or use them in Web application code, you
must also validate the field names.
Do not put unnecessary information in forms and do not assume that hidden
fields are secure from modification by the user.
For example, a catalog Web application could use a hidden form field for the
price of a product. This price can easily be modified by a malicious client. If
you do not validate that price when the form is submitted, you are open to
accepting any price that the user chooses. Therefore, you must validate that
field. Alternatively, as a best practice, do not include the price in the form at all.
Display the price to the user, but rely only on the price that you store in a
database when accepting an order on a product.
Vulnerabilities
Best practices