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

Securing Legacy Applications - Longhorn PHP 2018

Securing Legacy Applications - Longhorn PHP 2018

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 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.

Chris Cornutt

April 20, 2018

More Decks by Chris Cornutt

Other Decks in Programming


  1. Securing Legacy Applications A Developer’s Guide Longhorn PHP 2018 @enygma

  2. None
  3. Simplify Simplify Simplify Complexity is the enemy of security. Refactor

    for simplicity.
  4. Security Risk

  5. Understand the Scope



  8. Understand the Scope Work from the outside in (general), then

    introduce security Identify and document where data changes hands
  9. Quick Hits

  10. 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 EGPCS: Environment, Get, Post, Cookie, and Server
  11. Quick Hits: Unfiltered Data Using values directly, no filtering/validation Also

    getRequestParam() Input::get() _request->getQuery() getParam() Dangerous concatenation Injection issues Solution: filter_var or filtering/validation libraries
  12. 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
  13. 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
  14. 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/HMAC)
  15. Input Handling

  16. 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.
  17. 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.
  18. Validation (Add & Update)

  19. Validation: Do You Even? Not a priority in many apps,

    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.
  20. 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.
  21. Templating

  22. Templating: PHP PHP is not a templating language…no really. Largest

    refactor point in legacy applications. Using methods to escape output? That’s templating. Evaluate options: template it all vs spot checks.
  23. Templating: Manual Prone to mistakes. Hard to manage effectively. Beware

    the copy and paste (and context changes). Move slowly, replace most used first. Based on logging
  24. 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
  25. Access Control

  26. Access Control: Now Determine current controls (Auth*) Determine coverage of

    controls Threat model! Look for over-engineering
  27. 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
  28. Access Control: Endpoints Public, Private, Conditional Different protection levels Start

    with most used (logs as a guide) Protect at different levels router, endpoint, server - defense in depth! See if there’s a simpler way
  29. Access Control: User Determine user types Create a grid of

    types and endpoints Features == users? Administrator vs user
  30. Adding New Controls

  31. 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?
  32. 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
  33. Changing Development Practices

  34. Changing Dev Process Hardest part in the whole process New

    code needs security guidance Manual (security) code review Establish a pattern of security refactoring
  35. 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
  36. It doesn’t require a security expert, just a security mindset.

  37. Thanks! Questions? @enygma @securingphp https://websec.io