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.

Security vulnerabilities for grown ups - GOTOcon 2012


Published on

Dealing with product security vulnerabilities in startups. Talk at GOTOcon Aarhus May 2012

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Security vulnerabilities for grown ups - GOTOcon 2012

  1. 1. Security vulnerabilities for grown-ups Vitaly Osipov Atlassian
  2. 2. Or: 7 product securitylessons I learned @Atlassian
  3. 3. Disclaimer All good parts of this talk Are learned from my colleagues Any errors Are all mine
  4. 4. Lesson 1Sea of vulnerabilities
  5. 5. Security vulnerability? Not a security feature - e.g. login Security of other features Bug in your code that can lead to unauthorised view / change of information downtime
  6. 6. Typical product Web(-ish) applications >100 kloc Dozen third party libraries A couple of Web frameworks Enterprise customers
  7. 7. Learned:If you’re a mid-size software vendorYou will learn your code has vulnerabilitiesThis year...More than once…Remember, only 50% products can be “aboveaverage”The current industry average is far from good
  8. 8. Levels of “oops” You find the vulnerability yourself Customer reports their findings “Security researcher” contacts you You are compromised Customer is compromised
  9. 9. Clouds and silver lining Someone gives a damn, hurray! A culture shift - “loss of innocence” Growing up Stages of grief
  10. 10. 5 stages of grief Denial: “This cannot be happening” Anger: “Why me? It is not fair!” Bargaining: “Perhaps it is not as bad as it seems?” Depression: “Man, nobody will ever buy from us again!” Acceptance: “We can fix this!”
  11. 11. Lesson 2Small bugs, big incidents
  12. 12. Debian OpenSSL
  13. 13. Apache / JIRA 2010“ive got this error while browsing some projects in jira”Change attachment pathInstall JSP shell and password interceptor...
  14. 14. Learned:Often one vulnerability is all it takesSeveral “non-critcial” issues combine into one bigtrouble
  15. 15. Lesson 3But this is not my code!
  16. 16. Is thissufficient?
  17. 17. XML BombKnown since 2002, yet you probably have this10^9 lols
  18. 18. XXE Local Entities
  19. 19. XXEOther recent examples:
  20. 20. Aside: where to start withXXE in Java DocumentBuilderFactory SAXParserFactory XMLInputFactory nu.xom.Builder  SAXBuilder
  21. 21. OGNL - StrutsSee Struts advisories
  22. 22. More OGNL
  23. 23. Ruby/triggerpath?search[instance_eval]=%60touch%20%2ftmp%2fcommand_exec%60touch /tmp/command_exec“Ruby on Rails from a code auditors perspective”,Hackito Ergo Sum 2011 by @joernchen
  24. 24. ...On RailsMass assignment is a feature
  25. 25. LearnedPast decisions will bite you...and decisions of other people will bite you tooWhen you least expect it
  26. 26. Lesson 4Why all this matters
  27. 27. Here to stay
  28. 28. Do you like…Coding features?Fixing bugs?...bugs that are not triggered by normal use?...rare bugs reported by people who are intentionallyusing your software not to the specs? Also known as security vulnerabilities
  29. 29. Security is difficult “Everyone knows that debugging is twice as hard as writing a program in the first place. So if youre as clever as you can be when you write it, how will you ever debug it?” Brian Kernigan
  30. 30. Normal dev reaction“Please make it go away and let mecreate exciting new features for mycustomers!” (not an actual quote)
  31. 31. Learned:Security is counterintuitiveMost companies do not think security (or, say,architecture) until a while into the project“Fixing” security becomes much harder as the productgrows
  32. 32. Lesson 5What can we do?
  33. 33. Three things1.Product security response2.Priority fixing3.“Prevention”
  34. 34. Lesson 6Response and Validation
  35. 35. 1. Responsea.k.a. PSIRTSmall effort that goes a long waySanity in a
  36. 36. Learned:Research is exciting for developersFixing is less soEspecially when patches are involved And you do not do patches as a rule
  37. 37. Learned:Advisory / security alert?External dependencies Products Services InfrastructureChecking, double-checking, triple-checking
  38. 38. Lesson 7Fixing
  39. 39. 2. Fixing
  40. 40. Learned:Find vuln reports proactivelyFix fast and keep the reporter in the loop Even if the issue does not look serious “Where else does this appear?”Be very nice“Responsible disclosure” debate
  41. 41. 3. “Preventing” Difficult and endless battle Especially in Agile shops Microsoft has some papers about Agile SDL Ask me next year
  42. 42. IdeasUse framework features if you can (auto-encoding forXSS)Stripped-down Java Security Manager (codeexecution, file reads)Reduce complexity of inputs (no OGNL!)
  43. 43. IdeasTrain QA in security Training a security pro in QA is harderDevelopers will learn from them Depends on how QA/Dev is set up“Blind spots” - missing classes of vulnerabilities
  44. 44. IdeasTesting toolsBurp SuiteOnly a help, not a magic scannerMany false positives and false negatives from allautomated scanners - source code or web
  45. 45. Watch out“Each of these endeavours resulted in a significant andbrief improvement, which was quickly overcome by theentropy of unstructured coding.” Somewhere in PragProg mag
  46. 46. Do I have to? Response and fixing are the basics Bad PR and stolen data are worse than any short term savings Emergency fixing is very expensive “Past results do not guarantee future success”
  47. 47. But it cannot happen to me!
  48. 48. TODOMake someone accountable for responseSet up and monitor security@Train QA in securityPrioritise fixing security issuesThink about prevention / risk management...
  49. 49.