15

15 (Photo credit: el frijole)

Secure By Design is a simple concept in the security world where software is designed from the ground up to be as secure as possible regardless of whether or not it imposes a disadvantage to the end user. The purpose of this principle is to ensure that users who are not security experts can use the software without necessarily being obliged to jump through hoops to learn how to secure their usage or, much worse, being tempted into ignoring security concerns which expose unaddressed security vulnerabilities due to ignorance, inexperience or laziness. The crux of the principle therefore is to promote trust in the software while, somewhat paradoxically, avoiding too much complexity for the end user.

Odd though it may seem, this principle explains some of PHP’s greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I’m sure its in the back of developers’ minds just as I’m sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers.

The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as “By-Default Vulnerabilities”. It also means that defending against key types of attacks is undermined by PHP not offering sufficient native functionality and I’ll refer to these as “Flawed Assumptions”. Combining the two sets of shortcomings, we can establish PHP as existing in an environment where security is being compromised by delegating too much security responsibility to end programmers.

This is the focus of the argument I make in this article: Responsibility. When an application is designed and built only to fall victim to a by-default vulnerability inherited from PHP or due to user-land defenses based on flawed assumptions about what PHP offers in terms of security defenses, who bears the responsibility? Pointing the finger at the programmer isn’t wrong but it also doesn’t tell the whole story, and neither will it improve the security environment for other programmers. At some point, PHP needs to be held accountable for security issues that it has a direct influence on though its settings, its default function parameters, its documentation and its lack thereof. And, at that point, questions need to be asked as to when the blurry line between PHP’s default behaviour and a security vulnerability sharpens into focus.

Please read the rest of my article hosted on readthedocs.org.

Enhanced by Zemanta

Related posts:

  1. HTML Sanitisation: The Devil’s In The Details (And The Vulnerabilities)
  2. Storing Session Data In Cookies: Problems And Security Concerns To Be Aware Of
  3. CodeIgniter 2.0.2: Cross-Site Scripting (XSS) Fixes And Recommendations
  4. Regex HTML Sanitisation: Off With Its Head!
  5. Open Letter to Gareth Heyes: Regex HTML Sanitisation Doesn’t Work