Securing Legacy Applications - Longhorn PHP 2018

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Security Risk

Slide 5

Slide 5 text

Understand the Scope

Slide 6

Slide 6 text

Understand the Scope AUTH OUTPUT INPUT BUSINESS LOGIC DATA BACKEND

Slide 7

Slide 7 text

Understand the Scope AUTH OUTPUT INPUT BUSINESS LOGIC DATA BACKEND APP

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Quick Hits

Slide 10

Slide 10 text

Quick Hits: Globals Look for global use deeper in code In PHP, that’s superglobals ﬁrst $_POST, $_GET, $_SERVER, $_COOKIE $_FILES, $_SESSION Get rid of these right now: $GLOBALS, $_REQUEST EGPCS: Environment, Get, Post, Cookie, and Server

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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 identiﬁers and hard-coded strings

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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-speciﬁc handling $app->get() requirements.sf_method Solution: Abstract out the handling by action Ensure proper protection (CSRF/HMAC)

Slide 15

Slide 15 text

Input Handling

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

Validation (Add & Update)

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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 ﬁrst, then sanitize. Don’t try too hard.

Slide 21

Slide 21 text

Templating

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

Templating: Manual Prone to mistakes. Hard to manage effectively. Beware the copy and paste (and context changes). Move slowly, replace most used ﬁrst. Based on logging

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Access Control

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Adding New Controls

Slide 31

Slide 31 text

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?

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Changing Development Practices

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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