IBM Zurich Research Laboratory

Web 2.0 Security Considerations

Dr. Andreas Wespi

Mgr. Security & Assurance

Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

IBM Security and Privacy Research

Zurich
Watson • Cryptography • JavaCard
• Biometrics • OS/Linux Security • Business • Privacy Mgmt
• Cryptography • Privacy Processes • Services/ODIS
• Ethical Hacking • Secure HW • Dependability • Storage Security
• Intrusion Defense • Web Services • Identity Mgmt • Web Services
• Language Sec • Wireless
Web 2.0 Security • Intrusion Defense • Risk Management

Beijing

Almaden
• Rights Mgmt Haifa Tokyo
• Privacy • Web Services
Dehli • Web
Crypto
2.0Hardware
• Services/ODIS
Austin

2 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Motivation

3 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Notoriously Difficult and Sticky Problems:

# Vulnerabilities Growing, Time-to-exploit Shrinking

300
35000 Average # of days between
280
Number of vulnerabilities 30480
publication and broad
30000 reported to CERT/CC 250 exploitation of a vulnerability.
since 1995.
25000
200 205
22416

20000

16426 150

15000 12946

100 104
10000
9162 88

5033 50
5000
2596 26
1089 1506
516 827
171 10
0 0
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
1999 2000 2001 2002 2003 2004

Source: CERT/CC Statistics; CERT, Source: Information Security Magazine (based on Foundstone),
http://www.cert.org/stats/ June 2004; http://infosecuritymag.techtarget.com/

4 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Application-level
vulnerabilities [%]
Application Security 80

70

60

50
ƒ Shift towards application-level vulnerabilities:
40

–Lack of security training: 30

• Everybody can program web applications in a scripting language 20

–Lack of security-friendly tooling: 10

0
• Use of weakly typed scripting languages 2002 2003 2004 2005

• Prepared statements relatively new

http://icat.nist.gov/
ƒ Today over 70% of attacks against a company's
Web site or Web application come at the
'Application Layer‘, not the Network or System layer”
(Gartner Group)
ƒ Some application vulnerabilities (OWASP Top Ten report)
–A1: Unvalidated input
–A4: Cross-site scripting (XSS) Flaws
–A6: Injection flaws
ƒ Wietse Venema’s bug count: 1 bug / 1000 lines of code

5 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

What is Web 2.0?

ƒ “Web 2.0 is the business revolution in the

computer industry caused by the move to the
Internet as platform, and an attempt to understand
the rules for success on that new platform. Chief
among those rules is this: Build applications that
harness network effects to get better the more
people use them.”
- Tim O’Reilly

6 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

What is Web 2.0?

ƒ Web 2.0 lacks a precise definition. It is used mainly as a catch-all term to

cover Web sites that are more than just plain, static pages.
ƒ Web 2.0 sites are more interactive, allowing people to tag photos posted
online, for example.
ƒ Rich Internet Applications (RIA) deliver an experience more akin to using a
desktop application.
ƒ There are a few “new” technologies that are linked to Web 2.0:
–AJAX
–Flash / Flex
ƒ Mashups refer to a new breed of Web 2.0 applications that compose multi-
level services, data sources, scripts, and results of other mashups. These
could be from two or more mutually untrusting, and possibly competing,
service providers.
ƒ Web 2.0 applications are expected to have lower development and delivery
costs than traditional applications.

7 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Why is Web 2.0 Security a Concern?

ƒ Web 2.0 applications have all the same problems

as traditional web applications – and more!
ƒ Threats are not well understood
ƒ Practitioners are focused on what they can do
rather than how (or if) they should do it.

http://www.denimgroup.com/media/pdfs/DenimGroup_Web20Security_AJAXWorld_20070321.pdf

8 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

AJAX

ƒ Asynchronous JavaScript and XML

–standards-based presentation using XHTML and CSS (Cascading
Style Sheets)
–dynamic display and interaction using the DOM (Document Object
Model)
–data interchange and manipulation using XML and XSLT (Extensible
Stylesheet Language Transformation)
–asynchronous data retrieval using XMLHttpRequest
–and JavaScript binding everything together

ƒ Google, Amazon, Flickr

ƒ Uses JavaScript on the client and any language on the server

9 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

AJAX user interface

JavaScript call
Browser
HTML+CSS data

Browser user interface Ajax engine

HTTP request HTTP request

HTML + CSS data XML data

web server web and/or XML server

Server Server
datastores, backend datastores, backend
processing, legacy systems processing, legacy systems

http://www.adaptivepath.com/publications/essays/archives/000385.php

10 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Some Atttacks

ƒ Yamanner, Samy and Spaceflash are among the

higher-profile attacks that have surfaced online.
–The Yamanner worm targeted Yahoo Mail, harvesting e-
mail addresses and forwarding itself to all contacts in a
user's Yahoo address book.
–The Samy and Spaceflash worms both spread on MySpace,
changing profiles on the hugely popular social-networking
Web site.

11 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Samy Worm
ƒ Written in JavaSript. The code was first placed in Samy’s profile. Once anyone viewed
Samy’s profile, he would unknowingly execute the code.
ƒ Upon executing the code, it would add Samy as a friend. This normally requires
approval, but this was all done in the background via Ajax.
ƒ Bypassed numerous negative filters against possibly malicious tags, attributes, etc.
ƒ Relied on the same functionality being served from multiple hostnames, supporting the
Same-Origin Policy
–profile.myspace.com and www.myspace.com
ƒ Used a multi-step background combination of GETs and POSTs
–Get the list of friends
–Parse out special post tokens
–Add Samy as new friend
ƒ The most important step is that the code reproduces itself by adding itself to the profile
of the user viewing an infected profile.
ƒ More than 1 Mio. Infected profiles within the first 20 hours.

http://blog.outer-court.com/archive/2005-10-14-n81.html

12 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Injection Vulnerabilities

13 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Injection Vulnerabilities: SQL example

ƒ Programming flaws allowing attacker to manipulate semantics of SQL query
by providing input with syntactic content.

ƒ Example of SQL injection vulnerability:

$query = "SELECT * FROM users WHERE email=" .
$email . " AND pincode=" . $pincode;
$result = mysql_query($query);

ƒ If pincode = “1234 OR 1=1”

$query = “SELECT * FROM users WHERE email=user@test.org AND
pincode=1234 OR 1=1”;
$result = mysql_query($query);

– Query result becomes independent of pincode and thus circumvents

authentication logic

ƒ Defense can be nontrivial and error prone

– Complex syntax: e.g., comments, multiple queries, ...
– Database dependent: MySQL vs. MSSQL vs. DB2
– Context-dependent: strings vs. numeric constants
14 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation
 IBM Zurich Research Laboratory

Injection Vulnerabilities
ƒ Injections are the major class of application-level
vulnerabilities

ƒ Common varieties include: ƒ But there are also:

• SQL injection • XPath injection
• Cross-site scripting (XSS) • Path traversal
• Shell injection • Server-side includes (SSI)
• ...
15 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation
 IBM Zurich Research Laboratory

Injection Vulnerabilities: Root Cause

ƒ Prerequisites for injection vulnerabilities:

• textual representation of output expressions (channel mixing)
• ad-hoc serialization of output expressions
• user-originating data used in the output expressions

16 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Existing defense techniques

ƒ Safe ad-hoc serialization:
• Manual input validation (has to be actively and consistently used)
• Automated input validation (aka filters) [1] (makes assumptions
about usage of expressions, e.g., SQL statement)
• Perl variable tainting [2] (programmer has to write correct filtering
regexp)
• Static analysis [3] (coverage?)

[1] PHP MagicQuotes, http://www.php.net/

[2] Perl tainting, http://www.perl.com/
[3] Finding Security Vulnerabilities in Java Applications with Static Analysis, V. Livshits and M. Lam, Usenix Security '05

17 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Context-Sensitive String Evaluation

ƒ CSSE automatically applies the appropriate checks for

syntactic content in user-provided input

ƒ Therefore it needs to be able to:

•distinguish between user- and developer-provided

parts of the output expressions
(1) Metadata assignment to user-provided input
(2) Metadata-preserving string operations

•determine the appropriate checks on the user-

provided parts before the command execution (e.g.,
SQL command)
(3) Context-sensitive string evaluation

18 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: metadata assignment

(1) Metadata Assignment

– metadata describes which string fragments are user-provided

and which developer-provided
• basic assumption: user-provided input is untrusted
• more fine-grained than Perl tainting (~1 bit/variable)

– interception of all input vectors:

• network input: e.g., HTTP headers
• direct input: e.g., environment variables
• stored input: e.g., db

19 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: example

(1) (2) (3)

20 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: metadata-preserving string operations

(2) Metadata-Preserving String Operations

– all string operations should be intercepted:

• preserve and update metadata
• complexity:
– quite often trivial: copy metadata (e.g., tolower())
– often easy: merge metadata (e.g., concat())
– sometimes more difficult (e.g., regexp matching)

(1) + (2) ability to distinguish between user- and developer-provided

fragments at any point in creation of the output expressions

21 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: example

(1) (2) (3)

22 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: context-sensitive string evaluation

(3) Context-Sensitive String Evaluation

– all output vectors are intercepted:

• appropriate validation function for output vector is called
• validation function will:
– leverage the metadata to determine untrusted fragments
– perform limited syntactic analysis of output expression
– detect syntactic content in untrusted fragments (not
trivial!)
– prevent by escaping, blocking, removing, ... syntactic
content (optional)
(1) + (2) + (3) prevention of injection attacks

23 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: example

(1) (2) (3)

24 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Our CSSE Prototype Implementation

ƒ Modification of the original PHP platform v 5.0.2
ƒ Focus on the network and MySQL db input and output vectors
– metadata framework:
• configuration options and metadata repository
– input vectors:
• network: GET, POST, COOKIE
• MySQL database query
– string operations:
• most commonly used string operations (e.g., concat)
– output vectors:
• echo, print
• MySQL database query
ƒ Total lines of source code added: 587

25 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Validating effectiveness
ƒ Tested on phpBB, a popular bulletin-board application:
• v2.0.x had 12 SQL injection vulnerabilities in BugTraq [8] ...
• ... of which we managed to reproduce seven (Bugtraq 6634,
9122, 9314, 9942, 9896, 9883, 10722 )

ƒ Example vulnerability (BugTraq 9112):

26 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Results
ƒ Results:
– Self-tests passed (as with unpatched)
– Correct operation of phpBB
– All SQL injections detected successfully

ƒ Overhead:
– Performance overhead (CGI): ~2-10%
• the number of affected strings is relatively small
• efficient lookup
– Memory overhead: ~2%

27 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

CSSE: false positives/negatives

ƒ CSSE is an efficient intrusion defense method

ƒ We identified three scenarios in which FP/FN can

occur:
– Incomplete implementations
• not a trivial task, but needs to be done only once
– Incorrect implementations
• not a trivial task, but can be done by security-savvy experts

28 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Cross-Site Request Forgery (XSRF)

Cross-Site Scripting (XSS)

N. Daswani et al., “Foundations of Security: What Every Programmer Needs to Know”, ISBN 978-1590597842

29 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Interactions between Web Pages from Different Domains

ƒ Early days of the Web: plain HTML

ƒ Modern browsers support DHMTL documents that specify content, layout, and
formatting (through CSS)
ƒ Different browsers support different client-side scripting languages as well as different
flavors of the same language although there is an ECMAScript standard
ƒ Web browsers implement the so-called same-origin policy. Scripts can only access
properties (cookies, DOM objects, …) associated with documents from the same origin
as the origin of the documents with which the script is associated.
ƒ Origin considers protocol, hostname, and port
ƒ Equal:
– http://www.examplesite.org/here
– http://www.examplesite.org/there
ƒ Different
– http://www.examplesite.org/here
– https://www.examplesite.org/there
– http://www.examplesite.org:8080/thar
– http://www.hackerhome.org/yonder

30 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

HTTP Request Authentication

ƒ HTTP by itself is a stateless protocol

ƒ There are several techniques that add authentication
–HTTP authentication: The browser requests authentication credentials (username
and password) form the user and then automatically supplies these credentials in a
special HTTP header along with each request to the server
–Cookie authentication: The application requests the user’s authentication credentials
in an HTML form. Once the credentials are validated, the application issues a
session token to the browser in an HTTP cookie.
–Hidden-form authentication: Instead of cookies hidden form fields are used to
transfer the session token.
ƒ Under certain circumstances a malicious page can cause the user’s
browser to make requests to an already visited site, and the requests will be
processed by that site as if they were initiated by the user identified and
authenticated by the credentials in question.
ƒ Temporary / non-persistent cookies vs. persistent cookies

31 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Malicious AJAX Code execution

ƒ AJAX calls are very silent and end-users would not be able to determine
whether or not the browser is making silent calls using the
XMLHTTPRequest object.
ƒ When the browser makes an AJAX call to any Web site it replays cookies
for each request. This can lead to potential opportunities for compromise.
ƒ For example, John has logged in to his bank and authenticated on the
server. After completing the authentication process he gets a session
cookie. His bank’s page has a lot of critical information.
ƒ Now he browses other pages while still logged in to his bank’s account
Web page and lands at an attacker’s Web page.
ƒ On this page the attacker has written silent AJAX code which makes
backend calls to his bank without John’s consent, fetches critical
information from the pages and sends this information to the attacker’s
Web site.
ƒ This leads to a security breach and leakage of confidential information.

32 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Cross-Site Request Forgery (XSRF)

ƒ www.myfavoritesite.com
– <form method=“POST” action=“/update_profile”
…
New Password: <input type=“password” name=“password”>
…
</form>

ƒ www.hackerhome.org
– <form method=“POST” name=“evilform”
target=“hiddenframe”
action=https://www.myfavoritesite.com/update_profile
<input type=“hidden” name=“password” value=“evilpassword”>
</form>
<iframe name=“hiddenframe”
style=“display: none”>
</iframe>
<script>
document.evilform.submit();
</script>

33 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Cross-Site Scripting (XSS)

ƒ Suppose there is the following URL
http://www.myfavoritesite.com/query?question=cookies
that returns an HTML document containing the following fragment:
…
<p>Your query for ‘cookies’ returned the following results:</p>
…
ƒ Now suppose that an attacker manages to cause a user to load the following URL into
his browser – for example by tricking him into clicking a link, or by luring him into
viewing a harmless-looking page that sources this URL in an invisible <iframe>
http://www.myfavoritesite.com/query?question=cookies+%3Cscript%3Emali
cious-script%3C/script%3E
The document loaded into the browser in response to this request will contain the
following HTML fragment:
…
<p>Your query for
‘cookies’ <script>malicious-script</script>’
returned the following results:</p>
…

34 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Some more Web 2.0 related Attacks

http://www.net-security.org/article.php?id=949

35 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

XML Poisoning

ƒ XML traffic goes back and forth between server and browser in
many of the Web 2.0 applications.
ƒ Web applications consume XML blocks coming from AJAX clients.
It is possible to poison these XML blockx
ƒ Not uncommon is the technique to apply recursive payloads to
similar-producing XML nodes multiple times. If the engine’s
handling is poor this may result in a denial of services on the
server.
ƒ Many attackers also produce malformed XML documents that can
disrupt logic depending on parsing mechanisms in use on the
server.
ƒ XML external entity reference is an XML property which can be
manipulated by an attacker. This can lead to arbitrary file or TCP
connection openings that can be leveraged by an attacker.

36 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

RSS / Atom Injection

ƒ RSS feeds are common means of sharing information on

portals and Web applications. These feeds are consumed by
Web applications and sent to the browser on the client-side.
ƒ One can inject literal JavaScripts into the RSS feeds to
generate attacks on the client browser. An end user visits
this particular Web site, loads the page with the RSS feed
and the malicious script – a script that can install software
or steal cookies – gets executed.
ƒ This is a lethal client-side attack. Worse, it can be mutated.
With RSS and ATOM feeds becoming integral part of Web
applications, it is important to filter out certain characters on
the server-side before pushing the data out to the end user.

37 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

WSDL Scanning and Enumeration

ƒ WSDL (Web Services Definition Language) is an interface to

Web services.
ƒ This file provides key information about technologies,
exposed methods, invocation patterns, etc.
ƒ This is very sensitive information and can help in defining
exploitation methods.
ƒ Unnecessary functions or methods kept open can cause
potential disaster for Web services.
ƒ It is important to protect WSDL file or provide limited access
to it. In real case scenarios, it is possible to discover several
vulnerabilities using WSDL scanning.

38 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Web Services Routing Issues

ƒ Web services security protocols have WS-Routing services.

ƒ WS-Routing allows SOAP messages to travel in specific
sequence from various different nodes on the Internet.
ƒ Often encrypted messages traverse these nodes.
ƒ A compromise of any of the intermediate nodes results in
possible access to the SOAP messages traveling between
two end points.
ƒ This can be a serious security breach for SOAP messages.
ƒ As Web applications move to adopt the Web services
framework, focus shifts to these new protocols and new
attack vectors are generated.

39 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

XPATH Injection in SOAP Messages

ƒ XPATH is a language for querying XML documents and is similar to

SQL statements where we can supply certain information
(parameters) and fetch rows from the database.
ƒ XPATH parsing capabilities are supported by many languages. Web
applications consume large XML documents and many times these
applications take inputs from the end user and form XPATH
statements.
ƒ These sections of code are vulnerable to XPATH injection. If
XPATH injection gets executed successfully, an attacker can
bypass authentication mechanisms or cause the loss of
confidential information.
ƒ There are a few known flaws in XPATH that can be leveraged by an
attacker. The only way to block this attack vector is by providing
proper input validation before passing values to an XPATH
statement.

40 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

RIA Thick Client Binary Manipulation

ƒ Rich Internet Applications (RIA) use very rich UI features such as

Flash, ActiveX Controls or Applets as their primary interfaces to
Web applications.
ƒ There are a few security issues with this framework.
ƒ One of the major issues is with session management since it is
running in a browser and sharing the same session.
ƒ At the same time since the entire binary component is downloaded
to the client location, an attacker can reverse engineer the binary
file and decompile the code.
ƒ It is possible to patch these binaries and bypass some of the
authentication logic contained in the code.
ƒ This is another interesting attack vector for Web 2.0 frameworks.

41 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

What have we learned?

42 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

Conclusions

ƒ Security has been overlooked in the rush to adopt Web 2.0 features.
ƒ AJAX itself does not introduce vulnerabilities, it just makes it easier to
make old mistakes.
ƒ The software industry is exiting the desktop applications era, where buffer
overflows were the big security problem. Now it's JavaScript in AJAX that is
raising concerns.
ƒ The Web 2.0 model of integrating partner- and customer-generated
components into your Web site means that administrators now have to
worry not only about the security of their own Web sites, but the security of
those interconnected pieces.
ƒ We have to implement security best practices.
ƒ Tooling is needed that supports the developer.
ƒ Security has to be considered already in the design phase.
ƒ Functionality vs. security.

43 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation

 IBM Zurich Research Laboratory

For more information …

ƒ How to reach me
– Andreas Wespi <anw@zurich.ibm.com>

ƒ IBM Research
– IBM Zurich Research Lab:
• http://www.zurich.ibm.com
– Security research at IBM:
• http://www.research.ibm.com/compsci/security

44 Web 2.0 Security Considerations 6/18/2007 © 2007 IBM Corporation