Securing Legacy
Applications
A Developer’s Guide
Sunshine PHP 2017 @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
Understand the Scope
Slide 5
Slide 5 text
Understand the Scope
AUTH OUTPUT
INPUT
BUSINESS
LOGIC
DATA
BACKEND
Slide 6
Slide 6 text
Understand the Scope
AUTH OUTPUT
INPUT
BUSINESS
LOGIC
DATA
BACKEND
APP
Slide 7
Slide 7 text
Understand the Scope
Work from the outside in (general),
then introduce security
Identify and document where data changes hands
Slide 8
Slide 8 text
Quick Hits
Slide 9
Slide 9 text
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
Slide 10
Slide 10 text
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
Slide 11
Slide 11 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 identifiers and hard-coded strings
Slide 12
Slide 12 text
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
Slide 13
Slide 13 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-specific handling
$app->get()
requirements.sf_method
Solution:
Abstract out the handling by action
Ensure proper protection (CSRF)
Slide 14
Slide 14 text
Input Handling
Slide 15
Slide 15 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 filter.
Slide 16
Slide 16 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 17
Slide 17 text
Validation
(Add & Update)
Slide 18
Slide 18 text
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.
Slide 19
Slide 19 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 first, then sanitize.
Don’t try too hard.
Slide 20
Slide 20 text
Templating
Slide 21
Slide 21 text
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.
Slide 22
Slide 22 text
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
Slide 23
Slide 23 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 24
Slide 24 text
Access Control
Slide 25
Slide 25 text
Access Control: Now
Determine current controls (Auth*)
Determine coverage of controls
Threat model!
Look for over-engineering
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
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
Slide 28
Slide 28 text
Access Control: User
Determine user types
Create a grid of types and endpoints
Features == users?
Administrator vs user
Slide 29
Slide 29 text
Adding New Controls
Slide 30
Slide 30 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 31
Slide 31 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 32
Slide 32 text
Changing Development
Practices
Slide 33
Slide 33 text
Changing Dev Process
Hardest part in the whole process
New code needs security guidance
Manual code review
Establish a pattern of security refactoring
Slide 34
Slide 34 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
Slide 35
Slide 35 text
It doesn’t require a security expert, just
a security mindset.