Defensive Coding Crash Course

Defensive CodingCrash Course

Mark Niebergall

About Mark Niebergall• PHP since 2005 • Masters degree in MIS • Senior Software Engineer • Drug screening project • UPHPU President • CSSLP, SSCP Certified and SME • Drones, fishing, skiing, father, husband


• Why defensive coding

• How to code defensively

• Community trends with best practices

Why Defensive Coding

Why Defensive Coding• Denver Broncos

- 2 recent Super Bowl appearances: 2013 and 2015

- What was the difference?

Why Defensive Coding• Rogue One - The Empire

- Single point of failure

- No encryption of sensitive data

- Missing authentication

- Bad error handling

Why Defensive Coding• The Three R’s:

- Reliability

- Resiliency

- Recoverability

Why Defensive Coding• Reliability

- Predictable behavior

- Likelihood of failure is low

- Achieved by writing resilient code

Why Defensive Coding• Resiliency

- Ability to recover from problems

- How errors are handled


- Avoid assumptions


- Use correct data types

- Use type hinting

- Use return types

- Use visibility modifiers


- function do_something($thing) { $thing->do_ThatThing(); }

- public function doSomething(Thing $thing) : bool{ return $thing->doThatThing(); }

Why Defensive Coding• Recoverability

- Application can come back from crashes and failures

Why Defensive Coding• Recoverability

- Good exception handling

- try { … } catch (SomeException $exception) { … }

- Hope for the best, code for the worst

Why Defensive Coding• Good code qualities


- Efficient

‣ High performance

‣ Separation of services

‣ Loosely coupled


- Secure

‣ Strong cryptography

‣ Proven approaches to reduce vulnerabilities

‣ Secure architecture


- Maintain

‣ Good code organization

‣ Documentation

‣ Adaptability

Why Defensive Coding• Achieved by practicing effective defensive coding

Why Defensive Coding

How to Code Defensively

How to Code Defensively• Cover a variety of techniques

How to Code Defensively• Attack surfaces • Input validation • Canonicalization • Secure type checking • External library vetting • Cryptographic agility • Exception management • Code reviews • Unit and behavioral testing

How to Code Defensively• Attack surfaces

- Measurement of exposure of being exploited by threats

- Part of threat modeling - Ability of software to be attacked


- Each accessible entry and exit point - Every feature is an attack vector


- Attack surface evaluation ‣ Features that may be exploited ‣ Given a weight based on severity of impact ‣ Controls prioritized based on weight


- Relative Attack Surface Quotient (RASQ) ‣ 3 Dimensions

• Targets and Enablers (resources) • Channels and Protocols (communication) • Access Rights (privileges)


- High value resources ‣ Data ‣ Functionality

How to Code Defensively• Input validation

- Source - Type - Format - Length - Range - Values - Canonical


- Source ‣ Unsafe superglobals includes $_GET, $_POST,

$_SERVER, $_COOKIE, $_FILES, $_REQUEST ‣ Scrutinize trusted sources ‣ Any user input should be treated as unsafe


- Type ‣ is_int ‣ is_float ‣ is_bool ‣ is_null ‣ is_array ‣ is_object ‣ is_resource


- Type ‣ $thing instanceof SomeThing ‣ class ‣ abstract ‣ interface ‣ trait


- Format ‣ Phone number ‣ Email address (complicated) ‣ Country code ‣ Character patterns


- Length ‣ Minimum ‣ Maximum ‣ Is it required?


- Range ‣ Between 1 and 10 ‣ Date range ‣ AA to ZZ ‣ Start and end values


- Values ‣ Whitelist ‣ Blacklist ‣ Regular expressions ‣ Alphanumeric ‣ Free text ‣ Allowed values


- Injection prevention - Malicious


- Techniques ‣ Filtration ‣ Sanitization


- Techniques ‣ Filtration

• Whitelist and blacklist • Regular expressions with preg_match

• preg_match(/^d{10}$/, $number) • preg_match(/^[a-zA-Z0-9]$/, $string)



• filter_input(TYPE, $variableName, $filter [, $options])

• boolean false if filter fails • NULL if variable is not set • variable upon success



• filter_input(INPUT_POST, ‘key’, FILTER_VALIDATE_INT)

• filter_input(INPUT_GET, ‘search’, FILTER_VALIDATE_REGEXP, [‘options’ => [‘regexp’ => ‘/^d{10}$/‘]])


- Techniques ‣ Sanitization

• Remove unwanted characters or patterns • Clean up the data


- Techniques ‣ Sanitization

• filter_input(INPUT_POST, ‘something’, FILTER_SANITIZE_EMAIL)

• filter_input(INPUT_COOKIE, ‘somewhere’, FILTER_SANITIZE_URL)


- When to validate data ‣ Frontend (client) ‣ Backend (server) ‣ Filter input, escape output

How to Code Defensively• Canonicalization

- Translating input to a standardized value ‣ Encoding ‣ Character set ‣ Aliases ‣ Alternative spellings, formats


- Translating input to a standardized value ‣ 2017-08-17 ‣ 8/17/17 ‣ 17/8/17 ‣ Thursday, August 17, 2017


- Translating input to a standardized value ‣ Yes ‣ On ‣ 1 ‣ true ‣ T


- Translating input to a standardized value ‣ Free text vs pre-defined choices

• Proper foreign keys • Utilize database integrity checks and

normalization

How to Code Defensively• Secure type checking

- Part of Code Access Security (CAS) ‣ Only trusted sources can run application ‣ Prevent trusted sources from compromising

security


- PHP is a type-safe language - C is not a type-safe language


- PHP manages memory use for you - C is unmanaged ‣ Susceptible to attacks like buffer overflow


- Apply PHP security patches - Vet third-party libraries

How to Code Defensively• External library vetting

- Security - Quality


- Security ‣ Secure implementation ‣ Security audit ‣ Handling security issues ‣ Use trusted projects


- Quality ‣ Unit tests ‣ Actively maintained ‣ Popularity ‣ Ease of use ‣ Coding standards

How to Code Defensively• Cryptographic agility

- Ability to stay current


- Use vetted and trusted algorithms - Avoid: ‣ Broken algorithms ‣ Weak algorithms ‣ Custom-made algorithms

• Cryptography is complex, please don’t make your own algorithm


- PHP password_hash and password_verify


- PHP 7.2 includes libsodium in core ‣ Modern security library ‣ Vetted ‣ Passed security audit

- PHP 7.1 deprecated mcrypt ‣ Upgrade to libsodium or openssl

How to Code Defensively• Exception management

- Handle errors with try/catch blocks ‣ try {...} catch (Exception $e) {…}


- Do not display PHP errors except in development environment ‣ dev: display_errors = On ‣ others: display_errors = Off


- Log errors and review them actively ‣ dev: error_reporting = E_ALL ‣ prod: E_ALL & ~E_DEPRECATED & ~E_STRICT ‣ E_ALL ‣ E_NOTICE ‣ E_STRICT ‣ E_DEPRECATED

How to Code Defensively• Code reviews

- Static - Dynamic


- Peers reviewing code changes ‣ Web-based tools ‣ Manual/static code review

- Automatic code review ‣ Commit hooks ‣ Coding standards ‣ Run tests


- Constructive feedback


- Architecture direction


- Coding standards


- Security issues ‣ Cryptographic agility ‣ Injection flaws

- Business rules - Related functionality - Exception handling


- Automatic code reviews ‣ Coding standard enforcement ‣ Run unit and behavioral tests ‣ Continuous integration tools


- Automatic code reviews ‣ Statistics ‣ Security ‣ Design patterns

How to Code Defensively• Unit and behavioral testing

- More on this later

How to Code Defensively• Tips and Tricks


- Hope for the best, plan for the worst


- Abuse cases ‣ Harmful interactions ‣ Help identify threats

- Misuse cases ‣ Inverse of use case ‣ Highlights malicious acts


- Limit class functionality - Limit function lines of code


- Leverage framework functionality - Leverage built-in PHP functionality


- Use type hinting - Use return types - Use correct data types ‣ Bool true or false instead of string ’T' or ‘false’ ‣ Be aware of type casting issues ‣ Use strict type === comparisons when possible ‣ Use is_* checks


- Use database integrity ‣ Have foreign keys ‣ Use correct data types ‣ Normalize data to good level

• Usually 2nd or 3rd level • Beyond that usually slows performance • Denormalize to improve performance but take

up more disk space

How to Code Defensively• Community movements


- PHP Standards Recommendations ‣ Coding standard and style guide ‣ Autoloading ‣ Caching ‣ HTTP Message Interface


- PHP Standards Recommendations ‣ Security issue reporting and handling ‣ Documentation ‣ Extended coding style guide


- Security ‣ New OWASP Top 10 ‣ Security at all parts of SDLC ‣ libsodium with PHP 7.2 ‣ Sophisticated attacks ‣ MD5 sunset ‣ IoT


- Security ‣ Increasing importance ‣ Good skill to complement development ‣ Core software feature ‣ Investment that can save a project


- Conferences help set trends - Magazines focus on topics monthly - Blogs to dispense knowledge - Social media to share ideas - Instant messaging to get live help

How to Code Defensively• Considerations


- How could your project be attacked? - What are weak points in your projects?


- What will you do differently?


- Make a plan - Make a change

How to Code Defensively

How to Code Defensively• Questions?

Defensive Coding Crash Course

Software

Transcript of Defensive Coding Crash Course