$30 off During Our Annual Pro Sale. View Details »

Build Security In

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!

Chris Cornutt

February 01, 2017
Tweet

More Decks by Chris Cornutt

Other Decks in Technology

Transcript

  1. Build Security In
    Chris Cornutt - @enygma Sunshine PHP 2017.02
    composer create-project enygma/sunphp17 app

    View Slide

  2. “Secure from the start”

    View Slide

  3. Security is not 100%
    Security is not an “add on”
    Security is not as hard as you think…

    View Slide

  4. Risk
    Not just a four letter word…

    View Slide

  5. Basic Concepts

    View Slide

  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.

    View Slide

  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

    View Slide

  8. Threat Modeling
    Web
    App
    Browser
    MySQL
    Database

    View Slide

  9. Threat Modeling
    Web
    App
    Browser
    MySQL
    Database

    View Slide

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

    View Slide

  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

    View Slide

  12. Least Privilege
    - Start at “nothing” and work up
    - Going from very open to closed is much harder
    - Makes audits so much easier

    View Slide

  13. Least Privilege
    Anonymous
    “User”
    HR group
    HR group admin
    Administrator
    Super Administrator

    View Slide

  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?

    View Slide

  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)

    View Slide

  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)

    View Slide

  17. Economy of Mechanism
    - Keep it Simple (Stupid)
    - Don’t Reinvent, Reuse
    - “What if”s are dangerous
    - Think MVSP (Minimum Viable Security Protection)

    View Slide

  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)

    View Slide

  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)

    View Slide

  20. Complete Mediation
    - Check every time, don’t assume
    - Security through obscurity
    - Think about the security of the data/functionality
    - Weigh performance against enforcement

    View Slide

  21. Least Common
    Mechanism
    - Endpoints shared between users
    - Protected according to access level
    - Does it show more for admins?
    - Split versus combined

    View Slide

  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)

    View Slide

  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)

    View Slide

  24. Psychological
    Acceptability
    - Transparent security
    - Usability vs Security (constant struggle)
    - Example: 2FA
    - Example: Reauthentication
    - Secure defaults, then disable

    View Slide

  25. Who’s ready for a
    break?

    View Slide

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

    View Slide

  27. View Slide

  28. Authentication

    View Slide

  29. Authentication
    Proof of Identity

    View Slide

  30. Authorization

    View Slide

  31. Authorization
    Proof of Access

    View Slide

  32. Secure State

    View Slide

  33. Secure State
    Safe Storage

    View Slide

  34. Secure State
    Prevention and Protection

    View Slide

  35. Input Validation

    View Slide

  36. Input Validation
    Proof of Validity

    View Slide

  37. Output Escaping

    View Slide

  38. The Aftermath

    View Slide

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

    View Slide