Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Security - Myth or Fact Slides


Published on

Slides from cf.Objective 2012

Published in: Technology
  • Be the first to comment

Application Security - Myth or Fact Slides

  1. 1. Application SecurityMyth or Fact? Dave Ferguson @dfgrumpy
  2. 2. 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 )
  3. 3. If you have a question please ask it anytime
  4. 4. Why should you care aboutAPPLICATION SECURITY?(isn’t that the network guy’s problem?)
  5. 5. At its core, Security is about riskmanagement
  6. 6. Security is fundamentallyabout protecting “assets”
  7. 7. Most applications don’t haveenough protection
  8. 8. Any protection in place isprobably insufficient
  9. 9. Security implementation is usuallyin place to protect server /network, not application
  10. 10. Using captcha to protect a form isnot the same as anti-intrusion
  11. 11. Once you understand theperceived value of yourapplication, you will betterunderstand how to protect it
  12. 12. What does it mean to have a secured application?
  13. 13. Some stuff for the“Network Guy” Viruses Worms Network intrusion OS Compromise
  14. 14. OWASPOpen Web Application Security Project
  15. 15. OWASP Top 10(as of 2010)• A1: Injection• A2: Cross-Site Scripting (XSS)• A3: Broken Authentication and Session Management• A4: Insecure Direct Object References• A5: Cross-Site Request Forgery (CSRF)• A6: Security Misconfiguration• A7: Insecure Cryptographic Storage• A8: Failure to Restrict URL Access• A9: Insufficient Transport Layer Protection• A10: Unvalidated Redirects and Forwards
  16. 16. GAME TIME!
  17. 17. “I use SSL so my application is secure”
  18. 18. 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.
  19. 19. “My application is secure because I have a login screen”
  20. 20. MYTH (for the most part) If not implemented correctly, then this becomes a myth. Demo time…
  21. 21. “I don’t need to worry about security because I am using (insert framework here)”
  22. 22. 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.
  23. 23. “Our data access layer is ORM so we are safe from sql injection”
  24. 24. MYTH Properly implemented ORM does protect against injection. However, utilizing HQL can expose the system to injection. Demo Time…
  25. 25. “We don’t need to worry about security because our site has nothing of value“
  26. 26. 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.
  27. 27. “The Global Script Protection setting in the ColdFusion admin is sufficient”
  28. 28. 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…
  29. 29. “Our URL / form variables are encrypted so they can’t be tampered with”
  30. 30. MYTH If a loose encryption is used, the encryption could be predicted.
  31. 31. “Thinking like an attacker will help protect my system”
  32. 32. 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.
  33. 33. “We are using anti-intrusion software so we are just fine”
  34. 34. 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…
  35. 35. Tips for the future:A Couple of things to always thinkabout when writing code
  36. 36. If a section is supposed to besecure, make sure security ischecked on all pages, not justentry points
  37. 37. Compartmentalize yourapplication to minimize exposureif system is compromised
  38. 38. Reduce the attack surface andremove unused sections or code
  39. 39. Don’t rely on a single securitylayer, use “defense in depth” andemploy multiple security layers
  40. 40. Treat all data from a client asbad until ... Forever.
  41. 41. Don’t leave security for theother guy to handle
  42. 42. Security by obscurity gives youa false sense of security
  43. 43. Thank You AnyQuestions? Dave Ferguson @dfgrumpy