Application Security - Myth or Fact Slides

Editor's Notes

• #2: Site notes:http://msdn.microsoft.com/en-us/library/ff648636.aspxhttps://www.owasp.org/index.php/Main_PageSetup:Close all task bar notifiers, chat, tweetdeckCFBuilder: Twister_preso workspaceMake sure font is at 18Select demo app and “go into”Open a cfc and a cfm just to init builder… then close files.Have no code opened.. But have task window availableOpen chrome to demo site http://local.demoapp.com/Open tab to local cfadminOpen firefox to demo site (then hide)
• #6: Reducing downtime,
• #7: An asset can be anything, database data, files on a server, the server itself.
• #15: The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.
• #16: Slide 15 - I think you should point out that the Top 10 gets updated every three years. It was last updated in 2010. Perhaps bringing this up when you take about staying current later int he press would be a good place for it. Open Web Application Security Project (OWASP)
• #19: Slide 18 - Many times people forget that SSL is about more than just encrypting data. Using SSL to verify the authenticity of a server's identity is just as important as encrypting the data. I think it is impotent to point this out. And to point out that self-signed certs are only good for development. Even though they encrypt the data just as well, you lose the server identification that is so important. 
• #21: First showing of demp app…. Explain basics of app (FW\\1, ORM, ColdSpring)FIXME: 20 LOGIN1: Login and show admin section.2: Logout and show how you can still get to admin3: Login protected the navigation… not the actual pages.4: Update code to check for login globally to prevent intrusion remove when done as future demo needs exploit available5: Show severity using session hijacking… login using chrome then copy cookies to firefox6: Click on "home" on menu. Login button should turn orange.7: Go to admin screen
• #23: Slide 22 - I think it would be accurate to say that frameworks (MVC, IoC, DI etc) do not typically provide any protection on their own, but they make writing secure software easier. The one exception to that would be ORM, which offers some built-in security, but that covers a small fraction of the vulnerabilities that code could contain.
• #25: Complicated demo.. Take your time…Make sure that CF console is showing in builder… need to show orm output1: Show search.. Show how using “;” in an injection string doesn’t work as orm hates it.2: inject into search to return all items… %' or 1 = 1 and 1 = '% Show query in console to see how it was built. Show code FIXME24 INJECTION Swap code out for param… should return nothing.. Show query to illustrate param3: using previous session hijack, go to admin in firefox. Go to delete screen and delete an item use url to add “ or 1 = 1” to url to wipe all data. go back to chrome and go to admin edit screen… should also show no recordsFIXME: 24.1INJECTION show how could have been avoided using entityload / delete or param
• #27: Slide 28 - I disagree with your assessment that this statement is fact (even kind). I think it should be Myth. What I point out to people is that if their site contains any kind of user data at all (even just email and a password) that it contains data that needs to be protected. Because we all know that 80% of those users are using the same password for your book club site and they are for their web mail. If your site is compromised, so could be many of your users email accounts, bank accounts, etc.  Even if your site is a completely open, read-only system, I doubt that you want your data compromised or want your site DoS'd because of bad programming. If the site is dynamic then it needs to have protections in place, period.
• #29: No code to show in this demo1: Use previous session hijack to access admin (alternatively use a non-logged in browser to access admin)2: Show CFAdmin and make sure script protect is off.3: Create new weapon and add code below in name. Use code that would be blocked and create new weapon. search for weapon to show exploit4: enable script protection. Use blocked code first to show how script protect works.5: use unblocked code with protection still on to create weapon. load search screen to show it still made it though.6: disable script protect in admin at end.blocked<script>alert('congrats! you are a victom of XSS')"></script>not blocked<body onload="alert('congrats! you are a victom of XSS')"></body>
• #35: Now the demo fun begins.Without changing anything… First open up app cfc to enable fuseguard. FIXME34 FuseGuard1: got to home screen in chrome. Attempt to load home screen in FF… fuseguard should block request as a session hijack.2: on chrome with screen still at admin try same sql delete inject… should get blocked3: try directory traversal “../../” Should get blocked.4: Show XXS block when creating weapon Show both previously blocked and unblocked to show FG blocking both.4: Open FG manager and show intrusion blocks
• #40: Use multiple gatekeepers to keep attackers at bay. Defense in depth means you do not rely on a single layer of security, or you consider that one of your layers may be bypassed or compromised.
• #41: Your application's user input is the attacker's primary weapon when targeting your application. Assume all input is malicious until proven otherwise, and apply a defense in depth strategy to input validation, taking particular precautions to make sure that input is validated whenever a trust boundary in your application is crossed.Slide 40 - Treat data from the client as bad, always. I think saying "until proven otherwise" might encourage people to think that if they "sanitize" input that they can then go without properly encoding output. I don't think there is any point at which it is OK to stop treating user provided data as untrusted.Use previous XXS exploit as example. Bad data might have been added prior to protection being enabled.
• #44: Site notes:http://msdn.microsoft.com/en-us/library/ff648636.aspxhttps://www.owasp.org/index.php/Main_Page