Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Real World Security Testing

Matt Konda
September 16, 2015

Real World Security Testing

A talk about the role of QA testers in identifying security issues. Identifying opportunities for testers to contribute to application security.

Matt Konda

September 16, 2015

More Decks by Matt Konda

Other Decks in Programming


  1. Introduction 1997 2006 2014 Consultant Engineer Software Architect Director of

    Engineering Rabble Rouser: Perl Java Applet C++ J2EE J2EE
 Spring Analytics Certificate Authority Vulnerability Scanner Penetration Test Manager Pricing Retail Banking Manufacturing Pharma Healthcare Research Ruby Rails Chicago BSides 2011, 2012 Defcon Skytalk OWASP Chicago, MSP 2013 AppSec USA 2012, 2013 ChicagoRuby 2013 Secure 360 Lone Star Ruby 2013 WindyCityRails 2013 Chicago JUG 2014 RailsConf 2014 Converge 2014 MS in CS Founder Consultant Agile Clojure Graph Database Trying to hack a business model that succeeds while helping developers. Domains: Projects: Training Coaching Code Review Plugged in to SDLC Consulting Assessments @mkonda [email protected]
  2. Agenda • Intro (We just did this) • Talking about

    Testing • Talk about scenarios from tester perspectives • Understanding security tools (and limitations) • Building Security Into Your SDLC • Wrap up
  3. Injection • Attacker supplies unexpected input that gets executed at

    some point. • Can result in system commands running, data being dumped, and code running in places it shouldn’t.
  4. Injection • Can often be detected by looking at code.

    • Can also be detected by testing different inputs and seeing what happens in relatively predictable ways. • In short, tools (both security and test automation) can often find this.
  5. Fraud • Of course there are many many different paths

    through which fraud can take place. • Consider: An attacker uses someone else’s account info that was leaked in a public break to make a transaction and send the purchase to a new address.
  6. Fraud • In very few cases can fraud be detected

    by security tools. At least not without big custom implementation work. • A tester could try adding a purchase to a new shipping address and verify that the application prompts for the user’s credit card. (What Amazon does)
  7. The interesting thing to think about here is that who

    is better situated to see fraud use cases than testers?
  8. Reflected XSS User input is displayed back to the logged

    in user. Classic example is a search box. You search for XYZ but we couldn’t find it. OR Here are your results for XYZ
  9. Persistent XSS User input is saved for later in a

    DB or storage. When later shown it is treated like code.
  10. Note that there are many XSS contexts. In the page

    In a path CSS directive Anywhere dynamic user input is put in the page without properly sanitizing it.
  11. It can help, but with data coming from many different

    places the correct way to prevent XSS is with output encoding.
  12. Manual testing strategies Test in Firefox. Try adding different scripts

    to form inputs: <script>alert(3)</script> <img src=”x” onerror=”alert(4)”/> <svg/onload=alert(5)</svg>
  13. Manual testing strategies Still testing in Firefox. See if you

    can manipulate the DOM and break CODE with user input: “/><img src=x onerror=”alert(4)”;/> '';!--"=&{()}
  14. Insecure Direct Object Reference • Enumerate and access resources that

    are not referenced by the application or intended to be accessible to the user Dennis Jim Salary Record Salary Record ?
  15. Insecure Direct Object Reference • In many apps, it is

    often easy to predict URL patterns. (Because of REST) • It is also extremely easy to REPLAY or resend a request that has been tampered with. • Therefore, it is always important to check that the logged in user has permissions to perform the action requested.
  16. Insecure Direct Object Reference • If you’re like me, you

    might be doing this: • Listing methods • Delete methods • Update methods • Business Operation Methods
  17. Insecure Direct Object Reference • Typically requires custom logic to

    implement rules. • Beware of the product that says it can find this automatically!
  18. Security in the SDLC • Building software is a process.

    • The best way to make software secure is to make security part of the process. • There are many ways to do this - none is perfect. • Find a way to make the security fit your process.
  19. DevOps Stats •High performers •2x success rate. •12x faster MTTR.

    •30x more deployments •8000x faster lead times •2x more like to exceed profitability, market share, productivity goals •50% market cap growth
  20. Agenda • Intro • Talking about Testing • Talk about

    scenarios from tester perspectives • Understanding security tools (and limitations) • Building Security Into Your SDLC • Wrap up (We’re doing this)
  21. Takeaways • Channel a villain • Ask security questions in

    requirements • Test for XSS, Injection, Authorization • Leverage automation where possible • Know some of the limits of security tools • Visit owasp.org to find more resources!