Build Security In

224dac66704579d941e927965a6220a2?s=47 Chris Cornutt
February 01, 2017

Build Security In

There's a classic mantra when it comes to security in applications: "build in security from the start". This is easy to say but much more difficult to put into practice, especially when first starting out. In this tutorial session let me guide you though some of the basic concepts and how to apply them in your code to ensure the security of your application is well architected and effective against your ultimate adversary: the hacker.

I'll start with some of the basic topics, like authorization/authentication and input validation, before moving on to good security principles like "defense in depth", fault-tolerant development and tools and techniques to ensure the security of your application. Come get your hands dirty and learn to secure your applications from the start!

224dac66704579d941e927965a6220a2?s=128

Chris Cornutt

February 01, 2017
Tweet

Transcript

  1. Build Security In Chris Cornutt - @enygma Sunshine PHP 2017.02

    composer create-project enygma/sunphp17 app
  2. “Secure from the start”

  3. Security is not 100% Security is not an “add on”

    Security is not as hard as you think…
  4. Risk Not just a four letter word…

  5. Basic Concepts

  6. Threat Modeling Threat modeling is a procedure for optimizing network

    security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. - searchsecurity.techtarget.com Sounds complicated, right? It’s not.
  7. Threat Modeling Entity People Other systems Remote sites Process Components

    Internal services Command line tools Data Flow Function calls Network traffic Data Store Database Files Registry Trust Boundary Where data changes hands
  8. Threat Modeling Web App Browser MySQL Database

  9. Threat Modeling Web App Browser MySQL Database

  10. Threat Modeling Web App Browser MySQL Database REST Interface Stripe

    API
  11. Least Privilege In information security, computer science, and other fields,

    the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose. - Wikipedia
  12. Least Privilege - Start at “nothing” and work up -

    Going from very open to closed is much harder - Makes audits so much easier
  13. Least Privilege Anonymous “User” HR group HR group admin Administrator

    Super Administrator
  14. Separation of Privilege In computer programming and computer security, privilege

    separation is a technique in which a program is divided into parts which are limited to the specific privileges they require in order to perform a specific task. This is used to mitigate the potential damage of a computer security attack. - A generic “user” is okay, but don’t let them run amok - Different kinds of “users”? - Should the admin even be in the same application?
  15. Economy of Mechanism One factor in evaluating a system's security

    is its complexity. If the design, implementation, or security mechanisms are highly complex, then the likelihood of security vulnerabilities increases. Subtle problems in complex systems may be difficult to find, especially in copious amounts of code. For instance, analyzing the source code that is responsible for the normal execution of a functionality can be a difficult task, but checking for alternate behaviors in the remaining code that can achieve the same functionality can be even more difficult. One strategy for simplifying code is the use of choke points, where shared functionality reduces the amount of source code required for an operation. Simplifying design or code is not always easy, but developers should strive for implementing simpler systems when possible. - US-CERT (Computer Emergency Readiness Team)
  16. Economy of Mechanism One factor in evaluating a system's security

    is its complexity. If the design, implementation, or security mechanisms are highly complex, then the likelihood of security vulnerabilities increases. Subtle problems in complex systems may be difficult to find, especially in copious amounts of code. For instance, analyzing the source code that is responsible for the normal execution of a functionality can be a difficult task, but checking for alternate behaviors in the remaining code that can achieve the same functionality can be even more difficult. One strategy for simplifying code is the use of choke points, where shared functionality reduces the amount of source code required for an operation. Simplifying design or code is not always easy, but developers should strive for implementing simpler systems when possible. - US-CERT (Computer Emergency Readiness Team)
  17. Economy of Mechanism - Keep it Simple (Stupid) - Don’t

    Reinvent, Reuse - “What if”s are dangerous - Think MVSP (Minimum Viable Security Protection)
  18. Complete Mediation A software system that requires access checks to

    an object each time a subject requests access, especially for security-critical objects, decreases the chances of mistakenly giving elevated permissions to that subject. A system that checks the subject's permissions to an object only once can invite attackers to exploit that system. If the access control rights of a subject are decreased after the first time the rights are granted and the system does not check the next access to that object, then a permissions violation can occur. Caching permissions can increase the performance of a system, but at the cost of allowing secured objects to be accessed. - US-CERT (Computer Emergency Readiness Team)
  19. Complete Mediation A software system that requires access checks to

    an object each time a subject requests access, especially for security-critical objects, decreases the chances of mistakenly giving elevated permissions to that subject. A system that checks the subject's permissions to an object only once can invite attackers to exploit that system. If the access control rights of a subject are decreased after the first time the rights are granted and the system does not check the next access to that object, then a permissions violation can occur. Caching permissions can increase the performance of a system, but at the cost of allowing secured objects to be accessed. - US-CERT (Computer Emergency Readiness Team)
  20. Complete Mediation - Check every time, don’t assume - Security

    through obscurity - Think about the security of the data/functionality - Weigh performance against enforcement
  21. Least Common Mechanism - Endpoints shared between users - Protected

    according to access level - Does it show more for admins? - Split versus combined
  22. Psychological Acceptability Accessibility to resources should not be inhibited by

    security mechanisms. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms. Where possible, security mechanisms should be transparent to the users of the system or at most introduce minimal obstruction. Security mechanisms should be user friendly to facilitate their use and understanding in a software application. - US-CERT (Computer Emergency Readiness Team)
  23. Psychological Acceptability Accessibility to resources should not be inhibited by

    security mechanisms. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms. Where possible, security mechanisms should be transparent to the users of the system or at most introduce minimal obstruction. Security mechanisms should be user friendly to facilitate their use and understanding in a software application. - US-CERT (Computer Emergency Readiness Team)
  24. Psychological Acceptability - Transparent security - Usability vs Security (constant

    struggle) - Example: 2FA - Example: Reauthentication - Secure defaults, then disable
  25. Who’s ready for a break?

  26. composer create-project enygma/sunphp17 ./setup

  27. None
  28. Authentication

  29. Authentication Proof of Identity

  30. Authorization

  31. Authorization Proof of Access

  32. Secure State

  33. Secure State Safe Storage

  34. Secure State Prevention and Protection

  35. Input Validation

  36. Input Validation Proof of Validity

  37. Output Escaping

  38. The Aftermath

  39. Thanks! Chris Cornutt @enygma https://websec.io https://securingphp.com https://joind.in/talk/8cf8b