Transcript Web Application Security

Web Application
Security
ECT 582
Robin Burke
Outline
SSL
 Web appliation flaws

configuration
 application design
 implementation
 state management
 command injection
 cross-site scripting

Secure Sockets Layer
Socket: The Berkeley Unix mechanism
for creating a virtual connection
between processes. Sockets interface
Unix's standard I/O with its network
communication facilities....The socket
has associated with it a socket
address, consisting of a port number
and the local host's network address.
-- FOLDOC
Network Layers
Session Layer

Not normally part of the "big four"


A session layer establishes a connection
between client and server



part of the original OSI 7-layer picture
extends beyond individual TCP/IP
connections
not part of any particular application
Precisely where web encryption should
reside


no need to change application
can be used over an extended interaction
SSL (now TLS)
Establishes how a client and server
can exchange encrypted content
 Goals

Cryptographic security
 Interoperability
 Extensibility
 Relative efficiency

Protocol phases

ClientHello
 request to use SSL/TLS
• https in browser
includes client-generated random number
ServerHello
 confirmation that SSL/TLS is available
 includes server-generated random number
 usually followed by server certificate
ClientKeyExchange
 client computes a secret key and encrypts it



• or client initiates Diffie-Helman key exchange

then both client and server compute a "master secret"
Protocol phases, cont'd


Master secret is key material for different purposes
 client MAC secret,
 server MAC secret,
 client encryption key,
 server encryption key,
 client write IV
 server write IV,
Finished
 server and client exchange encrypted message
 contains a hash of all of the messages exchanged in
the protocol so far
 final verification of "agreed to" parameters
Protocol phases, cont'd

Client can request resumption of previouslynegotiated interaction


server policies on time-out control
Options

Server can request a client certificate
• two-way authentication

Either client or server can request that the
cipher parameters be changed
• can happen at any time
• renegotiation
Overhead

Communication overhead

both sides exchange much more data
• certificates, etc.

Computational overhead



certificate verification
cryptographic operations
In general

protect only those communications where
content must be protected
PKI

SSL/TLS assumes PKI


Certificate authenticates server
In reality

verification path limited to browser
defaults
Web Application Security
"Web application code is part of your
security perimeter"
 Web application security

Cannot be ignored
 A regular site of attacks

Example #1: Updates


75% of all web servers running MS IIS 5.0 are
vulnerable to exploitation.
Microsoft issued a security alert on March 17 2003
regarding a buffer overflow vulnerability which allows
attackers to execute arbitrary code on Windows 2000
machines.
 Netcraft survey found 767,721 IPs running IIS 5.0 and
offering WebDAV and 273,496 IPs running IIS 5.0
with the protocol turned off.
-- Securitystats.com,
http://www.securitystats.com/webdeface.asp:
Example #2: CGI attacks
"CGI attacks are powerful, and the
vulnerabilities are common. Sure it is
possible to write secure CI scripts, but
hardly anyone does. One company
that auits Web sites for appliationlevel bugs like this has never founc a
Web site they could not hack. That's
100 percent vulnerabilities."
-- Schneier, "Secrets and Lies"
Example #3: Session
hijacking
"In a survey of 45 Web applications in
production at client companies, @stake
researchers found that 31% of e-commerce
applications examined were vulnerable to
session replay or hijacking -- the highest
incidence of Web application security
defects encountered in the study. @stake's
Andrew Jaquith (2002) comments, "user
session security remains the Achilles heel of
most e-business applications."
-- Jeni Li "State Management in Web
Applications"
The problem



Design
 little consideration of security in web's origins
Diversity of platforms
 OS (Linux, UNIX, WIndows, Mac OS, ...)
 Servers (IIS, Apache, ...),
 Browsers (Netscape, Mozilla, Internet Explorer,
Safari, Lynx, Opera, WebTV, ...) and custom scripts,
Diversity of technologies
 Application frameworks (Perl, PHP, Python, Java,
Javascript, C, tcl, ...),
 Standards (HTTP, HTML, XML, SSL, SQL, RSS,
encryption, cookies, webcasts, ...),
Web development process
Web developers are (often) not
programmers
 Web developers (often) have no
secure programming experience
 Web developers (often) are adapting
cookie-cutter scripts from books or online libraries
 Web development timeframes exclude
security review

Technology

Browser compensation

browser will correct "errors" on the page
• interpreting a ">" as a "<"
• interpreting a 'Content-Type Content="text/plain"'
metatag as if it were a "text/html".

Embedded browsers and servers

difficult or impossible to patch an embedded
web server.
• the "code red" virus vulnerability disabled many
printers and routers, not just web servers.
Configuration


(OWASP 10)
Web-accessible directories are public hunting grounds



Good practice


separate executable code E from ordinary HTML W
configure server to execute (E) and display (W)
distinct directory tree for executable code
Bad practice

using file extensions to distinguish between regular files and
executable ones
• .pl for Perl executables
• .pl.bak, .pl~ may still be viewable

putting command interpreters in executable directories
• horrors!
Configuration, cont'd

Web-accessible directories are public
hunting grounds


Store sensitive information (passwords,
session data) outside the web-accessible
directory structure
Bad practice


sometimes session id files show up in
Google searches!
scripts often hard-code username and
password information for databases
Configuration cont'd




The web server process is the most likely point of
compromise
Create a separate user for the web server process
 compromise of server gives control of that account,
but not whole machine
 minimize the privileges of the "web server" user
Good practice
 have server configuration files readable but not
writable by the "web server" user
Bad practice
 run the server as root (administrator)
Configuration, cont'd
Some web server capabilities are
inherently dangerous
 Eliminate capabilities that are not
strictly needed

directory listings
 symbolic links
 executable server-side includes

Configuration, cont'd


Users can create backdoors by enabling
Internet services
Good practice



user education
achieving a balance between limiting risk
and allowing individual initiative
Bad practice

creating such draconian policies that users
feel compelled to circumvent them to get
things done
Application design


Input to a web application can use either "GET" or "POST"
GET


POST





information is part of request data, but not shown
Information in GET requests can leak


faster, but information is displayed as part of URL in
browser
prying eyes
browser history
"refer" header
Caching software may handle GET requests differently
Good practice

Use POST for web applications
Application design, cont'd



(OWASP A1)
Input from the browser cannot be trusted
 data passed to the browser may be altered
 your page may not be generating the request
Good practice
 write a specification for valid input
• name field: [A-Za-z0-9] or . or – or '
check against it
Bad practice
 assuming that your Javascript validation code
protects you


Example: Hidden variables

This web page contains a form with a
hidden value
The application is passing the price as
a hidden variable in the form.
 An attacker could easily save the
form, edit it, and use the edited
version

• ordering 100 widgets at 1 cent each
Hidden variables, cont'd

Even easier the attacker
can enter the parameters into the URL
 if the application doesn't test for GET
vs POST


http://josquin.cti.depaul.edu/cgi-bin/buyit.pl?price=0.1&order=10

Not as silly as it sounds

This weakness was actually identified
in 11 shopping applications surveyed
in 2000.
Implementation

Many choices



Good





Perl with "taint" mode
JSP
ASP
Python
Riskier



Perl, Python, PHP, Java servlets, tcl, C, a command shell,
ASP, JSP
Some more secure than others
C
PHP
Dangerous

command shell
State management

Web protocols is stateless


E-commerce applications need state



one connection like any other
user logins
shopping carts
State maintenance

hidden values
• problematic

cookies
Cookies


Files stored with the browser
URL


Cookie data


identifying the originating site
some data string
Expiration date


if no date, the cookie is not permanently
stored
session cookie
3rd party cookies

Scenario
 Site A adds a cookie to your browser
• URL: Site D
• Cookie: visited site A

Site B
• URL: Site D
• Cookie: visited site B
etc.
 Site D can build a cross-site profile of browsing
behavior
Browsers now report if a cookie's URL differs from its
origin
 there are sometimes legitimate reasons for this


State management


(OWASP A3)
Cookie data can be forged


Do not store any user data in the cookie
itself



and in some cases, stolen
store only a session id
associate id with data on the server
Good practice


use a timeout to prevent hijacking
provide a logout option
State management, cont'd

Browser history may leave vulnerabilities



even with logout, replay may still succeed
attacker goes "back" to login page and
resubmits
Good practice



issue hidden random id with each login page
don't allow 2nd login with same id
use "no cache" headers
• but don't rely on browser compliance
Command injection


(OWASP A6)
Web applications may access other
applications resident on the server



data is passed from a user's request to
another application
parameters can be designed to include
commands that would otherwise not be
permitted
Good practice

validate for legal data only
Example: shell escape

Perl program
$address = $query->('address');
open( MAIL, "| /usr/lib/sendmail $address" );
print MAIL "Your application has been
received; thank you.\n";
close MAIL;

What this does



the program /usr/lib/sendmail is run
with $address as a parameter
receiving input from the file handle MAIL
Shell escape, cont'd

If the address parameter is valid


address = '[email protected]'
then the command is
• /usr/lib/sendmail [email protected]

But what if


address = 'nobody@localhost; /bin/rm -r /'
the command becomes
• /usr/lib/sendmail nobody@localhost; /bin/rm –r /

this will attempt to delete the server's
filesystem
Shell escape, cont'd

Solution

Validate the address parameter for
legal email address characters
• letters, numbers, _, ., a single @
• otherwise reject it

Also, don't shell escape
• call programs directly
SQL injection
(OWASP A6)
 Similar to the shell scripting problem



with database access
User input
used to build a database query
 easy for attacker to design input that
changes query semantics

Example: SQL injection
Cross-site scripting (XSS)
(OWASP A4)
 The idea



generate malicious scripting code
Get user to execute

post in an open forum
• guest book

embed in an innocent looking link
Example

Application code
sqlCmd = "insert into names (name) value (' "
+ userName + " ');";
execute (sqlCmd);

If the userName = "Burke", the SQL command is
insert into names (name) value ('Burke');

But what if the value is maliciously designed
userName = "Foo'); delete * from names where (name like '*"

Now the following commands are executed
insert into names (name) value ('Foo');
delete * from names where (name like '*');
XSS, cont'd


Encode dangerous content
 <  &lt
 >  & gt,
 etc
However
 requires a complete list of dangerous characters
• over a dozen, depending on context
assumes a particular character encoding
Good practice
 validate against expected good input
 may cause some non-malicious input to be rejected


Assignment #6

web application analysis