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)
An asset can be anything, database data, files on a server, the server itself.
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.
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)
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.
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
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.
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
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.
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>
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
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.
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.
Application Security - Myth or Fact Slides
Application SecurityMyth or Fact? Dave Ferguson @dfgrumpy firstname.lastname@example.org blog.dkferguson.com www.cfhour.com
Obligatory “About Me” Slide Working in field for a long, long time (15+ years) Using ColdFusion since version 1.5 Adobe Community Professional Sr. Developer for Nonfat Media One of the voices of the <CFHour> ColdFusion podcast w/ Scott Stroz ( @boyzoid )
MYTH SSL encrypts data in transit. Entry and exit points are still unprotected. Think of a tunnel through a mountain. Anyone can enter either side but once inside you can only interact with what is in the tunnel. SSL will prevent some things, such as a “man in the middle” attack.
“My application is secure because I have a login screen”
MYTH (for the most part) If not implemented correctly, then this becomes a myth. Demo time…
“I don’t need to worry about security because I am using (insert framework here)”
MYTH Frameworks give structure to code. Frameworks make writing secure software easier by inherently enforcing certain coding best practices. Code written in a framework can still have the same security holes as non-framework code Frameworks can add some complexity which requires developers to be more vigilant when looking for possible attack vectors.
“Our data access layer is ORM so we are safe from sql injection”
MYTH Properly implemented ORM does protect against injection. However, utilizing HQL can expose the system to injection. Demo Time…
“We don’t need to worry about security because our site has nothing of value“
MYTH Value is perceptual. The true value of your application is what others deem its value is. If an intruder believes your application is hiding something of value, they may try to find it. Your site may only contain trivial data. However, does it contain data that could allow an attacker to get into other systems? Storing any data about a person makes your site a target.
“The Global Script Protection setting in the ColdFusion admin is sufficient”
MYTH The keyword there is “sufficient”. Relying on script protection to save you is a fool’s errand. Thesetting will strip out some things but should not be treated as a silver bullet. Demo Time…
“Our URL / form variables are encrypted so they can’t be tampered with”
MYTH If a loose encryption is used, the encryption could be predicted.
“Thinking like an attacker will help protect my system”
FACT Keep up to date on current security trends. Takea step back when writing code and evaluate it for possible intrusion. Remember that security is a practice or frame of mind, not a “once in a while” type thing.
“We are using anti-intrusion software so we are just fine”
MYTH Anti-intrusion software blocks known intrusion patterns. They act as a filter to incoming data to stop potentially harmful requests from being processed. Not 100% effective, as intruders will attempt to bypass blocking software. Examples: ModSecurity SecureIIS FuseGuard Demo time…
Tips for the future:A Couple of things to always thinkabout when writing code
If a section is supposed to besecure, make sure security ischecked on all pages, not justentry points
Compartmentalize yourapplication to minimize exposureif system is compromised
Reduce the attack surface andremove unused sections or code
Don’t rely on a single securitylayer, use “defense in depth” andemploy multiple security layers
Treat all data from a client asbad until ... Forever.
Don’t leave security for theother guy to handle
Security by obscurity gives youa false sense of security
Thank You AnyQuestions? Dave Ferguson @dfgrumpy email@example.com http://blog.dkferguson.com http://www.cfhour.com