Defensive Coding Crash Course - ZendCon 2017

Defensive Coding 
Crash Course
Mark Niebergall
https://joind.in/talk/d4c29

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

Defensive Coding 
Crash Course

Defensive Coding 
Crash Course
• Why defensive coding
• How to code defensively
• Community trends with best practices

Why Defensive Coding
• Denver Broncos
- 2 recent Super Bowl appearances: 2013 and 2015
- What was the difference?

• Rogue One - The Empire
- Single point of failure
- No encryption of sensitive data
- Missing authentication
- Bad error handling

• The Three R’s:
- Reliability
- Resiliency
- Recoverability

• Reliability
- Predictable behavior
- Likelihood of failure is low
- Achieved by writing resilient code

• Resiliency
- Ability to recover from problems
- How errors are handled

• Resiliency
- Avoid assumptions

• Resiliency
- Use correct data types
- Use type hinting
- Use return types
- Use visibility modiﬁers

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

• Recoverability
- Application can come back from crashes and
failures

• Recoverability
- Good exception handling
- try { … } catch (SomeException $exception) { … }
- Hope for the best, code for the worst

• Good code qualities

- Efﬁcient
‣ High performance
‣ foreach ($array as $thing) { 
$db = new $Db; 
$db->update(‘thing’, $thing); 
}

- Efﬁcient
‣ Separation of services
‣ class Pet 
{ 
public function walkDog(Dog $dog) {…} 
public function feedFish(Fish $ﬁsh) {…} 
public function cleanDishes(Dish $dish) {…} 
}

- Efﬁcient
‣ Loosely coupled
‣ protected function driveCar() 
{ 
$car = new Car; 
$driver = new Person; 
… 
}

- Secure
‣ Strong cryptography
• password_hash and password_verify
‣ Proven approaches to reduce vulnerabilities
‣ Secure architecture

- Maintain
‣ Good code organization, ﬁle structure, domains
‣ Documentation, doc blocks
‣ Adaptability

• Achieved by practicing effective defensive coding

How to Code Defensively
• Cover a variety of techniques

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

• Attack surfaces
- Measurement of exposure of being exploited by
threats
- Part of threat modeling
- Ability of software to be attacked

• Attack surfaces
- Each accessible entry and exit point
‣ Everything in public/
‣ Every route
- Every feature is an attack vector

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

• Attack surfaces
- Relative Attack Surface Quotient (RASQ)
‣ 3 Dimensions
• Targets and Enablers (resources)
• Channels and Protocols (communication)
• Access Rights (privileges)

• Attack surfaces
- High value resources
‣ Data
‣ Functionality

- 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_x functions
‣ Name then all?

- Type
‣ is_string($name)
‣ is_int($age)
‣ is_ﬂoat($percentage)
‣ is_bool($isAccepted)
‣ is_null($questionableThing)
‣ is_array($keyValueData)
‣ is_object($jsonDecoded)
‣ is_resource($ﬁleHandle)

- Type
‣ if ($thing instanceof SomeThing) {…}
• class
• abstract
• interface
• trait

- Format
‣ Phone number: preg_match(/^d{10}$/, $phone)
‣ Email address (complicated)
‣ Country code: preg_match(/^[A-Z]{2}$/, $code)
‣ Character patterns

- Length
‣ Minimum: strlen($string) >= 5
‣ Maximum: preg_match(/^[a-zA-Z0-9]{1,10}$/,
$number)
‣ Is it required?

- Range
‣ Between 1 and 10: $value >= 1 && $value <= 10
‣ Date range
‣ AA to ZZ
‣ Start and end values

- Values
‣ Whitelist: in_array($checking, [1, 2, 3], true)
‣ Blacklist: !in_array($checking, [‘X’, ‘Y’, ‘Z’])
‣ 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)

- Techniques
‣ Filtration
• filter_input(TYPE, $variableName, $filter [,
$options])
• boolean false if filter fails
• NULL if variable is not set
• variable upon success

- Techniques
‣ Filtration
• ﬁlter_input(INPUT_POST, ‘key’,
FILTER_VALIDATE_INT)
• ﬁlter_input(INPUT_GET, ‘search’,
FILTER_VALIDATE_REGEXP, [‘options’ =>
[‘regexp’ => ‘/^d{10}$/‘]])

- Techniques
‣ Filtration
• filter_var($email, FILTER_VALIDATE_EMAIL)
• filter_var($id, FILTER_VALIDATE_INT)
• filter_var($bool, FILTER_VALIDATE_BOOLEAN)

- Techniques
‣ Sanitization
• Remove unwanted characters or patterns
• str_replace([‘ ‘, ‘-‘, ‘(‘, ‘)’], ‘’, $phone)
• preg_replace([‘/A/‘, ‘/B/‘, ‘/C/‘], [1, 2, 3],
$subject)
• strip_tags($text, ‘<marquee>’)
• Clean up the data

- Techniques
‣ Sanitization
• ﬁlter_input(INPUT_POST, ‘user_email’,
FILTER_SANITIZE_EMAIL)
• ﬁlter_input(INPUT_COOKIE, ‘some_url’,
FILTER_SANITIZE_URL)

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

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

‣ 2017-08-17
‣ 8/17/17
‣ 17/8/17
‣ Thursday, August 17, 2017

‣ Yes
‣ On
‣ 1
‣ true
‣ T

‣ Free text vs pre-deﬁned choices
• Proper foreign keys in relational data
• Utilize database integrity checks and
normalization
• Denormalize to an extent for optimizations

- 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 overﬂow

- Apply PHP security patches
- Vet third-party libraries

- Security
- Quality

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

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

- 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

- 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

• Code reviews
- Static
- Dynamic

• Code reviews
- Peers reviewing code changes
‣ Web-based tools
‣ Manual/static code review
- Automatic code review
‣ Commit hooks
‣ Coding standards
‣ Run tests

• Code reviews
- Constructive feedback

• Code reviews
- Architecture direction

• Code reviews
- Coding standards

• Code reviews
- Security issues
‣ Cryptographic agility
‣ Injection ﬂaws
- Business rules
- Related functionality
- Exception handling

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

• Code reviews
- Automatic code reviews
‣ Statistics
‣ Security
‣ Design patterns

• Unit and behavioral testing
- Unit tests to ensure logic
‣ PHPUnit
- Behavioral tests to ensure functionality
‣ behat
‣ codeception

• Tips and Tricks

• Tips and Tricks
- Hope for the best, plan for the worst

• Tips and Tricks
- Abuse cases
‣ Harmful interactions
‣ Help identify threats
- Misuse cases
‣ Inverse of use case
‣ Highlights malicious acts

• Tips and Tricks
- Limit class functionality
- Limit function lines of code

• Tips and Tricks
- Leverage framework functionality
- Leverage built-in PHP functionality

• Tips and Tricks
- 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

• Tips and Tricks
- 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

• Community movements

- PHP Standards Recommendations (PSR)
‣ 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

• Considerations

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

• Considerations
- What will you do differently?

• Considerations
- Make a plan
- Make a change

• Questions?
- Rate on joind.in
‣ https://joind.in/talk/d4c29

Defensive Coding Crash Course - ZendCon 2017

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Defensive Coding Crash Course - ZendCon 2017

Ähnlich wie Defensive Coding Crash Course - ZendCon 2017 (20)

Mehr von Mark Niebergall

Mehr von Mark Niebergall (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Defensive Coding Crash Course - ZendCon 2017