1 / 71

10 8 Ways to Protect Users of Your Web Applications

SESSION CODE: WEB301. 10 8 Ways to Protect Users of Your Web Applications. Pete LePage Senior Product Manager Microsoft Corporation. Agenda. A Little History. Securing Your Infrastructure. Trust User Input At Your Own Peril. SQL Injection Attacks. Cross Site Scripting Attacks.

macy
Download Presentation

10 8 Ways to Protect Users of Your Web Applications

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. SESSION CODE: WEB301 10 8 Ways to Protect Users of Your Web Applications Pete LePage Senior Product Manager Microsoft Corporation

  2. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  3. The security architecture of the web platform, until recently was largely an afterthought.

  4. We could block nearly 100% of exploits by removing one component from the system…

  5. Or, we could block a majority of exploits by removing a different component from the system…

  6. Making The Correct Tradeoffs is Hard

  7. Internet Explorer 8 Security Vision Internet Explorer 8: Secure by default • Security Feature Improvements • Secure Features • Provide Security and Compatibility • Reduce attack surface of existing code by closing legacy holes • Users understand that improved security is a reason to upgrade • Create security features that address the top vulnerabilities today and in the future • Apply security-focused rigors against new code

  8. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  9. Creating Secure Connections

  10. Domain Highlighting Help users to quickly and accurately determine whether or not they are visiting the expected site

  11. Extended Validation Supported by all major browsers 7+ 3+ 9+ 3+ 3+ Over 10,000 sites with extended validation certificates

  12. Insecure Login Form?

  13. Certificate Mismatch

  14. Be Aware of Mixed Content

  15. Mixed Content Example <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <link rel="shortcut icon" href="/favicon.ico" /> <link href="http://example.com/CssReset.css" rel="stylesheet" type="text/css" /> <link href="styles.css" rel="stylesheet" /> <title> ...

  16. MIME-Sniffing No upsniff from image/* X-Content-Type-Options: nosniff Option to force file save:Content-Disposition: attachment;filename=“foo.doc”; X-Download-Options: NoOpen

  17. Keep Your Servers Secure

  18. Best Practices Ensure you’re using SSL when appropriate Check users aren’t being prompted for mixed content? Make sure you’re servers up to date Use best-practices for user accounts, and passwords

  19. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  20. Assume All User Input is Evil

  21. toStaticHTML() function Client-side string sanitization, based on the Microsoft Anti-XSS Library. • window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!"); • Returns: • This is some <b>HTML</b> with embedded script following... !

  22. Best Practices Don’t rely on client side validation for input Use toStaticHTML() as one method to sanitize data

  23. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  24. SQL Injection Attacks Source: http://xkcd.com/327/

  25. Protecting Against SQL Injection Constrain User Input Use Type Safe SQL Parameters SqlDataAdaptermyCommand = new SqlDataAdapter("AuthorLogin", conn); myCommand.SelectCommand.CommandType= CommandType.StoredProcedure; SqlParameterparm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value= Login.Text; Using Escape Routines private string SafeSqlLiteral(string inputSQL) { return inputSQL.Replace("'", "''"); }

  26. Best Practices Assume all user input is evil! Use parameterized statements instead of building queries

  27. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  28. “XSS is the new buffer overflow” Researcher Bryan Sullivan • Steal cookies Launch CSRF Steal browser history • Log keystrokes Abuse browser/AX vulnerabilities • Deface sites Evade phishing filters • Steal credentials (of a sort) • Port-scan the Intranet Circumvent HTTPS

  29. Threat Landscape • Website Vulnerabilities by Class Source: Whitehat Security 8/08

  30. CrossSite Scripting Filter Identifies & prevent majority of XSS reflection attacks

  31. XSS Filter • Intercept and prevent majority of Type-1 XSS attacks • Great performance & site compatibility

  32. XSS Filter Original script: <SCRIPT src=http://hackersite.ie8demos.com/snoop.js> Generated Signature: <SC{R}IPT¤src¤=> Neutered Script <SC#IPT src=http://hackersite.ie8demos.com/snoop.js>

  33. Best Practices • Use the ASP.NET Anti-Cross Site Scripting Library • http://msdn.microsoft.com/en-us/security/aa973814.aspx Disable US-ASCII codepage Disable sniffing of UTF-7 codepage Fix other codepage-related bugs Disable CSS expressions in Standards mode

  34. Agenda A Little History Securing Your Infrastructure Trust User Input At Your Own Peril SQL Injection Attacks Cross Site Scripting Attacks ClickJacking Attacks Native JSON Building Mash-Ups

  35. ClickJacking

  36. ClickJacking DEMO

  37. ClickJacking – Free Avatars?

  38. ClickJacking – The Evil Overlay <iframeAllowTransparency="Yes" style="position:absolute; left:0px; top:30px; width: 581px; height: 1000px; z-index: 5;" id="I1" src="http://example.com" name="I1" border="0" frameborder="0" class="style2"> Frames disabled. </iframe> <div style="margin: 10px; position: absolute; top:160px; left:0px; width:600px; height:380px; background: white; z-index:10"> <img height="380" src="cat.gif" width="760" /> </div>

  39. ClickJacking – The Evil Overlay iFrame

  40. ClickJacking – The Innocent Page

  41. ClickJacking – The Evil Overlay DIV DIV

  42. ClickJacking – Expensive Computers!

  43. ClickJacking - Blocked

  44. ClickJacking - Blocked Blocked By X-Frame-Option

  45. ClickJacking Protection Frame Busting Scripts • Used to determine if site is being rendered in a frame • Can be defeated with a little knowledge and work HTTP Response Header: X-Frame-Options • Supported by Internet Explorer 8+, Opera 10.5+, Safari 4+, Chrome 4+ • Options: • Deny – prevents the page from being rendered if it’s within a frame • SameOrigin – prevents the page from rendering if it’s within a frame from another top level domain

  46. Best Practices Use HTTP Response Header X-Frame-Options Don’t use “sameorigin” if you have any page on your domain which accepts an arbitrary URL to frame

More Related