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

Securing Legacy Applications

Chris Cornutt
February 04, 2017

Securing Legacy Applications

It’s common to hear people preach “plan in security from the start” and in an ideal world you can. Here in the real world, though, we have legacy code that’s gathered over time and comes with a host of problems - (in)security included. What do you do when you’ve been commissioned with securing an application that’s showing its age? Follow along with me as a I step you through a list of tips and tricks you can use to discover security issues in your application and effectively fix them and secure your application.

Topics will include some of the most common vulnerability types, key places to look for potential issues and arm you with the tools and knowledge you’ll need to refactor that legacy application into something secure.

Presented at Sunshine PHP 2017

Chris Cornutt

February 04, 2017
Tweet

More Decks by Chris Cornutt

Other Decks in Technology

Transcript

  1. Securing Legacy
    Applications
    A Developer’s Guide
    Sunshine PHP 2017 @enygma

    View full-size slide

  2. Simplify
    Simplify
    Simplify
    Complexity is the enemy of
    security.
    Refactor for simplicity.

    View full-size slide

  3. Understand the Scope

    View full-size slide

  4. Understand the Scope
    AUTH OUTPUT
    INPUT
    BUSINESS
    LOGIC
    DATA
    BACKEND

    View full-size slide

  5. Understand the Scope
    AUTH OUTPUT
    INPUT
    BUSINESS
    LOGIC
    DATA
    BACKEND
    APP

    View full-size slide

  6. Understand the Scope
    Work from the outside in (general),
    then introduce security
    Identify and document where data changes hands

    View full-size slide

  7. Quick Hits: Globals
    Look for global use deeper in code
    In PHP, that’s superglobals first
    $_POST, $_GET, $_SERVER, $_COOKIE
    $_FILES, $_SESSION
    Get rid of these right now:
    $GLOBALS, $_REQUEST

    View full-size slide

  8. Quick Hits: Unfiltered Data
    Using values directly, no filtering/validation
    Also
    getRequestParam()
    Input::get()
    _request->getQuery()
    Dangerous concatenation
    Injection issues
    Solution:
    filter_var or filtering/validation libraries

    View full-size slide

  9. Quick Hits: Sensitive Logging
    User PII, credentials, tokens
    Logs are output too
    Log servers are often less secured
    Solution:
    Remove the sensitive information
    (and purge the logs!)
    Log only identifiers and hard-coded strings

    View full-size slide

  10. Quick Hits: Drop Catch-Alls
    Fallbacks are nice, until they’re not
    Be specific, like in routing
    Catch-alls make for sloppy code and difficult to manage
    dependencies.
    Solution:
    Remove them.
    Specify exact matches & functionality

    View full-size slide

  11. Quick Hits: Action Splitting
    REST-ey principle:
    GET reads, POST/PUT/DELETE updates
    Never the two (or three…or more?) shall meet
    Take advantage of framework-specific handling
    $app->get()
    requirements.sf_method
    Solution:
    Abstract out the handling by action
    Ensure proper protection (CSRF)

    View full-size slide

  12. Input Handling

    View full-size slide

  13. Input Handling: Input Points
    Locating input points (remember your threat model?)
    grep is your best friend (naming conventions)
    Do you really need it or is it just lazy?
    Solution:
    Avoid user-controllable data sources
    Use the force….er filter.

    View full-size slide

  14. Input Handling: Determine
    Risk
    Reducing inputs reduces risk
    Examine context (especially mixed)
    Example: is it used in evaluation and output?
    Document risk points (threat model)
    Solution:
    Maintain data via stateful sources (sessions)
    All external data is tainted. Never forget.

    View full-size slide

  15. Validation
    (Add & Update)

    View full-size slide

  16. Validation: Do You?
    Not a priority, sadly.
    Same Origin Fallacy
    “It’s mine! All mine!”
    Libraries vs internal methods
    like filter_var or Respect\Validation
    Solution:
    Assess validation needs across application (do they repeat?)
    Remember the threat model for inputs.
    Fail fast.

    View full-size slide

  17. Validation: Sanitize
    Don’t use as a replacement for input validation.
    The more assumptions you make,
    the higher the risk factor.
    Consider output contexts too (HTML, JS, XML…)
    Solution:
    Validate first, then sanitize.
    Don’t try too hard.

    View full-size slide

  18. Templating: PHP
    PHP is not a templating language…no really.
    Largest refactor point in most legacy applications.
    Using methods to escape output? That’s templating.
    Evaluate options: template it all vs spot checks.

    View full-size slide

  19. Templating: Manual
    Prone to mistakes.
    Hard to manage effectively.
    Beware copy and paste all the things.
    Move slowly, replace most used first.
    Based on logging

    View full-size slide

  20. Templating: Special Output
    HTML is not the only context.
    Javascript, CSS, HTML attribute, plain-text, log output.
    Template (escape) for the context.
    HTML htmlspecialchars
    CSS Replace with [num]
    Javascript Replace with \x
    URL url encode

    View full-size slide

  21. Access Control

    View full-size slide

  22. Access Control: Now
    Determine current controls (Auth*)
    Determine coverage of controls
    Threat model!
    Look for over-engineering

    View full-size slide

  23. Access Control: Credentials
    Look for hard-coded values
    username, token, password
    Extract the values and protect
    Think about protection levels
    External tool, external file, external service

    View full-size slide

  24. Access Control: Endpoints
    Public, Private, Conditional
    Different protection levels
    Start with most used
    Protect at different levels
    router, endpoint, server - defense in depth!
    See if there’s a simpler way

    View full-size slide

  25. Access Control: User
    Determine user types
    Create a grid of types and endpoints
    Features == users?
    Administrator vs user

    View full-size slide

  26. Adding New Controls

    View full-size slide

  27. Adding New Controls
    Can tools be consolidated (or removed)?
    Determine missing controls
    Are there 3rd party tools/libraries you can reuse?
    Simple is good, but sometimes complex is needed
    Are there interfaces with other systems

    View full-size slide

  28. Adding New Controls:
    Examples
    CSRF tokens injected automatically on render
    Encryption of data via libraries (ex: libsodium, defuse-php)
    Implementing a templating library
    Access control types:
    Access control list (ACL)
    Role-based access control (RBAC)
    Property-based access control
    Multi-factor authentication

    View full-size slide

  29. Changing Development
    Practices

    View full-size slide

  30. Changing Dev Process
    Hardest part in the whole process
    New code needs security guidance
    Manual code review
    Establish a pattern of security refactoring

    View full-size slide

  31. Changing Dev Process
    Integrate tools and services
    Scanners
    3rd party services
    Pentesting
    Bug Bounty
    Refactor bite-size pieces,
    related to current development
    Build a culture of security

    View full-size slide

  32. It doesn’t require a security expert, just
    a security mindset.

    View full-size slide

  33. Thanks! Questions?
    @enygma @securingphp
    http://websec.io
    https://joind.in/talk/1ba66

    View full-size slide