This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I’ll start by noting two interesting developments in recent months and one long standing best practice.

1. Launch of the SensioLabs Security Advisory Checker

The SensioLabs Security Advisor Checker is described on its website as follows.

You manage your PHP project dependencies with Composer, right? But are you sure that your project does not depend on a package with known security issues? The SensioLabs security advisories checker is a simple tool, available as a web service or as an online application, that uses the information from your composer.lock file to check for known security vulnerabilities. This checker is a frontend for the security advisories database.

The service operates by having people submit vulnerability data, as YAML files, to a centralised Github repository through pull requests. The upside is that the vulnerability data can be peer reviewed and centrally dispersed either online or via a service API. The downside is that you need to find vulnerability disclosures and people to submit them. The service currently covers Symfony, Zend Framework, Doctrine, Twig and FriendsOfSymfony bundles. It’s a tiny sample of packages available through Composer. I’m also not entirely sure if it’s sufficiently fine grained to report vulnerabilities on a project’s sub-packages where you have no direct dependency on the aggregate package (e.g. using zendframework/zend-db instead of zendframework/zendframework). That said, this is a working model of a service for checking your dependencies.

That said, the service exhibits an ambitious idea – projects sharing their vulnerability disclosures or advisories in a way that allows for automatically checking if any of your projects need to have their dependencies updated for security reasons.

2. OWASP‘s Top 10 security risks for 2013 includes “A9 – Using Components with Known Vulnerabilities”

This is a new entry onto OWASP’s Top 10 (which is currently at release candidate status for 2013). In summary, it recognises that applications are becoming ever more dependent on code not developed internally. We’ve had web application frameworks for years. Composer and Github have unleashed a storm of accessible libraries, bundles, modules, and other units of reuse that have revealed Not Invented Here (NIH Syndrome) as a psychological problem in ways not previously possible.

As reliance on externally controlled dependencies increases, so too does the risk of your applications using insecure dependencies. This is a risk that requires a lot of work to mitigate. For each dependency, you need to do a security review (no, I’m not kidding), check for security disclosures (whether voluntary or involuntary) and ensure that you end up rolling out to production with safe versions.

Quoting from the OWASP advice on preventing the use of components with known vulnerabilities…

One option is not to use compone

Truncated by Planet PHP.ie, read more at the original (another 4681 bytes)

I’ve started a website where I intend to sell thousands of products from a number of distributors through drop-shipping (the products go directly to the customer).

For reasons that I don’t understand, the distributors have watermarked their images, and don’t provide unwatermarked versions unless you’re an already well-established customer of theirs.

For the purpose of this demo, a watermark is a constant-colour “stamp” which is given opacity and pasted into the original image.

As I intend to be a good customer, I figured it would be okay for me to simply “unwatermark” the images.

There are a number of instructions online which show how to /fake/ an unwatermaking – by basically smudging the area where the watermark is.

However, as most watermarking appears to follow a single method, it is actually possible to simply reverse the process and remove the watermark, after a little trial and error.

Let’s consider an example. Here is an image, a stamp, and the merge of the two:

(original is here)

• 
• 
• 

To reverse this, you need to know what algorithm was used to create the watermark, and what the original watermark was.

Most people use a fairly simple method to watermark their images:

The stamp is one single colour, usually gray (#808080 in RGB) which will be visible on images which are both light and dark.

The stamp is then given an opacity (30% in my case above), and pasted directly over the original image.

The formula for any particular colour channel (R, G and B) on any pixel is: C₃=(1-p)C₁+pC₂, where p is opacity (0 to 1), C₁ is the colour value for the original image, C₂ is the stamp’s colour value, and C₃ is the resulting image’s colour value.

To reverse the watermarking, you need to convert the formula to see what it is in respect to C₁: C₁=(C₃-pC₂)/(1-p).

As most stamps will be using a middle gray (#808080), you just have to guess at the opacity. .3 is a good start.

For some reason I’m not yet sure of, the code I came up with did unwatermark the image, but too much… the points where the watermark were, ended up being too bright. So I needed to add a darkening aspect, reducing the brightness of the result of the above calculation.

I’m not going to hold your hand if you can’t make this work, but here’s the code I ended up with (assumes the images are exactly 400×400 in size). The original should be ‘original.jpg’, and the stamp should be ‘stamp.png’ (with white where transparent pixels should be).

$p=.3; // opacity

$f1=imagecreatefrompng('stamp.png');
imagepalettetotruecolor($f1);
$f2=imagecreatetruecolor(400, 400);
$f3=imagecreatefromjpeg('original.jpg');
imagepalettetotruecolor($f3);

for ($x=0;$x<400; ++$x) {
  for ($y=0; $y<400; ++$y) {
    $rgb1=imagecolorat($f1, $x, $y);
    $rgb3=imagecolorat($f3, $x, $y);
    $r3 = ($rgb3 >> 16) & 0xFF;
    $g3 = ($rgb3 >> 8) & 0xFF;
    $b3 = $rgb3 & 0xFF;
    if ($rgb1==16777215) { // white. just copy
      $c=imagecolorallocate($f2, $r3, $g3, $b3);
      imagesetpixel($f2, $x, $y, $c);
      continue;
    }
    $r1 = ($rgb1 >> 16) & 0xFF;
    $g1 = ($rgb1 >> 8) & 0xFF;
    $b1 = $rgb1 & 0xFF;
    $r2=c($r1, $r3, $p);
    $g2=c($g1, $g3, $p);
    $b2=c($b1, $b3, $p);
    $c=imagecolorallocate($f2, $r2, $g2, $b2);
    imagesetpixel($f2, $x, $y, $c);
  }
}
imagejpeg($f2, 'unwatermarked.jpg');

function c($c1, $c2, $p) {
  $c=c1($c1, $c2, $p);
  $c3=$c-(255-$c)*.2;
  return $c3<0?0:(int)$c3; 
} 
function c1($c2, $c3, $p) {
  $c=($c3-$c2*$p)/(1-$p);
  return $c>255?255:(int)$c;
}

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It’s not necessarily a complete list – if you think something needs to be added, let everyone know in the comments.

1. Never pass data from untrusted origins into output without either escaping or sanitising it.
2. Never forget to validate data arriving from an untrusted origin using relevant rules for the context it’s used in.
3. Remember that anything not explicitly defined in source code has an untrusted origin.
4. Remember that htmlentities() is incompatible with XML, including HTML5′s XML serialisation – use htmlspecialchars().
5. Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
6. Never use htmlspecialchars() as the primary means of escaping Javascript, CSS or URL parts.
7. Never use json_encode() to escape Javascript strings unless using PHP 5.3 and RTFM.
8. Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
9. Never ever pass escaped or sanitised data from untrusted origins into a Javascript execution context: a string later executed as Javascript, e.g. setAttribute(“onclick”, “PLEASEGODNOTHERE”).
10. Validate all complete URLs if constructed from untrusted data.
11. Never validate URLs using filter_var(). It doesn’t work and allows Javascript and Data URIs through.
12. Never include resources loaded over unsecured HTTP on a page loaded over HTTPS.
13. Sanitise raw HTML from untrusted origins using HTMLPurifier before injecting it into ouput.
14. Sanitise the output of Markdown, BBCode and other HTML replacements using HTMLPurifier before injecting it into output.
15. Remember that HTMLPurifier is the only HTML sanitiser worth using.
16. Adopt the Content Security Policy (CSP) header and abandon the use of inline CSS and Javascript where feasible.
17. Always transmit, with content, a valid Content-Type header referencing a valid character encoding.
18. Ensure that cookies for use solely by the server are marked HttpOnly.
19. Ensure that cookies which must only be transmitted over HTTPS are marked Secure.
20. Always review dependencies and other third party code for potential XSS vulnerabilities and vectors.

Cross-Site Scripting remains, by far, the most common vulnerability in web applications. Things that will sink your application, framework or library become very obvious from the list. There are more than enough naughty applications, frameworks and libraries around that you should have little trouble identifying offenders with grep and some mental acrobatics. Rumour has it that you can now locally search any project on Github without even cloning a repository.

Yes, some entries are reminders. It’s surprising how many people try to avoid HTMLPurifier in favour of the month’s Regular Expression Powered Miracle option which is riddled with holes or have formulated the belief that, contrary to its official syntax rules, Markdown magically prevents Cross-Site Scripting.

I have seen this issue many many times throughout my career so i thought it might be worth to go through it in details and help others.

If you have international content in your database and suddenly you see things like "é" or missing characters like "?" instead of "è" you may be in trouble. It is a symptom of lack of consistency in the ways you write, read and store unicode characters.

I hope my explanation, even that lengthy, will shed some light on the core of the problem and possible solutions :)

read more

I’m very happy to announce the release of Mockery 0.8.0.

Mockery is a simple yet flexible PHP mock object framework for use in unit testing with PHPUnit, PHPSpec or any other testing framework. Its core goal is to offer a test double framework with a succint API capable of clearly defining all possible object operations and interactions using a human readable Domain Specific Language (DSL). Designed as a drop in alternative to PHPUnit’s phpunit-mock-objects library, Mockery is easy to integrate with PHPUnit and can operate alongside phpunit-mock-objects without the World ending.

The new version of Mockery is the first in a year (since 0.7.2) and is packed with new features, bug fixes and even better support for PHP’s OOP model. It’s also the first version to be released with my new co-conspirator, Dave Marshall (@davedevelopment), who threatens to make me redundant as a maintainer! This version focuses primarily on stability but it’s worth reviewing the README for the new sections on Creating Partial Mocks and Behaviour Modifiers for mock objects.

For those who haven’t been using dev-master in their composer.json project file, you can now update to the 0.8.0 stable tag using Composer or grab the 0.8.0 package from the PEAR channel at http://pear.survivethedeepend.com.

A very special thanks to those who opened pull requests and reported issues over the past year.

The Zend Framework team recently released versions 2.0.8 and 2.1.4 to address a number of potential security issues including advisory ZF2013-02 “Potential Information Disclosure and Insufficient Entropy vulnerabilities in Zend\Math\Rand and Zend\Validate\Csrf Components”. Quite the mouthful!

In short, Zend Framework used the mt_rand() function to generate random numbers in situations where neither openssl_pseudo_random_bytes() nor mcrypt_create_iv() were available. This is possible when the openssl and mcrypt extensions are not installed/compiled with PHP. The mt_rand() function is a particularly weak Pseudorandom Number Generator (PRNG) selected for speed over security so it should never be used unless for obviously trivial use cases. Consider the following as food for thought:

if ($_GET['rand'] == mt_rand()) {
    exec($_GET['command']);
}

This example has two characteristics. It has nothing to do with cryptography and it gives attackers something interesting to work with if they can guess what mt_rand() will return. It demonstrates that the concept of reserving good random number generation solely for “cryptographic” purposes is entirely false and misleading. You should use good generators for all but the most trivial purposes. If guessing a random number or string leads to an unauthorised outcome, then using mt_rand() is a security vulnerability. This applies to a whole range of uses for random number generators: session IDs, API tokens, CSRF tokens, nonces and unique ids. These all rely on randomness as do core functions like uniqid() and array_rand(). What happens if they are predictable?

What makes mt_rand() and uniqid() such bad choices for anything when it comes to security? I wrote a new chapter for the slowly expanding security book I’m writing which you can read here online:

http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html

The extremely short and sweet version is that all of PHP’s internally used and externally exposed PRNGs use seeds. Those seeds are based on limited information like current seconds, microseconds, and process PID. These values are not very uncertain and even partially predictable, i.e. they have “insufficient entropy”. If you use the same seed, those PRNGs output the exact same values every time. If you get a random value from a server, you can brute force it to get the seed used (e.g. use HTTP Date head to guess seconds and twinned requests to minimise microsecond deltas). Servers can output brute forcible random numbers either automatically (i.e. Session IDs) or by design (e.g. CSRF Tokens). Now an attacker can predict future values – for the same PHP process! Finally, there’s this thing called KeepAlive that lets an attacker reuse the same PHP process multiple times…and predict random values on future requests. For example, the token generated when resetting an account password that is appended to a secret reset password URL sent by email to the account owner whose account can inject unsanitised HTML into any part of a website.

In any case, take the time to read the longer book chapter

Truncated by Planet PHP.ie, read more at the original (another 753 bytes)

I am very happy to share my first-ever screencast.

Screencast is about my open source project called phpProxyBuilder. It is a PHP library aimed at code reuse and promotion of proxy design pattern in PHP. It is heavily inspired by AOP and helps to implement cross-cutting concerns once and reuse the same code forever. It also promotes some of my favourite design principles like decoupling, testability, single responsibility and code reuse.

I wanted to create some screencasts for a while but I found it difficult to get the right tools. Fortunately screencasting and video editing are much easier on linux now and i hope to share more screencasts about PHP, open source and software design in the future :)

read more

As some of you are likely aware by now, Ruby On Rails posted a security advisory concerning critical remote code execution (RCE) vulnerabilities in its Action Pack for all versions of Rails since 2.0.

This vulnerability can likely be used in a wide variety of potential attacks so you should immediately update any Rails applications you are currently running. There’s a good analysis of the issue over on http://www.insinuator.net/2013/01/rails-yaml/ and it raises the very real risk that the global nature of this vulnerability may make automated attacks or worms feasible. A concrete POC has not been released to give folk more time to update their applications before attackers figure out how to take advantage of this.

Yes, but HOOEY! How does this relate to PHP, Paddy?!

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail’s case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of “buried” code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby’s dark magic, e.g. eval(), include(), require_once(), system() and, let’s not forget, unserialize(). Anyone can perform a mini-audit using grep searches just by checking for instances of these and similar functions and then identifying whether they are in unusual places or accepting variable inputs that could be exploited. For example, a few years back many applications were found to be unserializing user inputs which allowed for code execution attacks by manipulating parameters to __wakeup() and __destruct() method calls.

Rails is a battle hardened framework but all frameworks will suffer from unanticipated security vulnerabilities. You just won’t see them become as well publicised as Rails! It’s the nature of programming for programmers to err or fail to foresee unintended uses for their code. PHP applications and libraries are already suffering from any number of obviously pervasive ills including three security problems I called the Three Ugly Sisters in my recent article for December’s Web Advent series (SSL Peerjacking, XMl Injection and Cross-Site Scripting). We all have the capacity to do better on the security front.

No PHP project is immune to security vulnerabilities simply because of its size, user base, or funding. Even a good security audit is not immune to the blind spots of the reviewer, emerging security issues still flying under the radar and the continuing assault by researchers on practices and techniques we take for granted.

One part of being prepared for unexpected vulnerabilities is to find common ground with your competitors. Ruby on Rails is a web application framework. If you are a PHP framework developer and not monitoring Rails’ or Django’s security woes then it’s time to start. We can learn a lot because, despite the barri

Truncated by Planet PHP.ie, read more at the original (another 4060 bytes)

There are various reasons why wp-cron does not work, one of the most common ones being a misconfigured network or firewall. However, due to the way wp-cron works, anything that prevents WordPress opening a http connection to itself will cause wp-cron to fail. In my case I had a .htaccess password set on the development [...]

Since the dawn of time, circa 1995 AD, PHP and Security have been at constant loggerheads over what priorities programmers should cling to. Programmers, by their very nature, are drawn to getting shit done inexpensively. Building tools, libraries and applications is a time consuming and expensive process and managing that process in the most efficient manner possible has been a focus of untold years of study and experimentation. Interestingly, whereas open source code is subject to greater public review it is not necessarily driven by those same needs.

Many open source programmers are happy to waste countless hours in the pursuit of perfection, to try new things that companies’ would blanche at funding and to spread word through their social networks of every possible attractive idea to dare peek out of a window. Only in the open source world could someone suggest completely rewriting a sizeable chunk of code without having project managers and accountants hustle them off to the broom cupboard for a private chat. Not that those two groups are always aware of the costs of fixing stuff that isn’t broken!

Nevertheless, for all of open source’s charms it also carries around a terrible monster. Programmers will nearly always claim to take security seriously while writing source code which obviously doesn’t agree with this publicly proclaimed sentiment. Take such developments in-house to a proprietary setting and that same result is a recipe for utter disaster and a possible ass kicking out of the nearest door. Companies are risk intolerant when the risk offers no potential gain.

Our open source endeavors need to appeal to enterprises and other conservative programmers – not simply to the masses of PHP programmers attracted by shiny new stuff displacing ancient scarred stuff that still works reliably despite a decade of warfare on the frontlines. We also need to be concious that PHP Security is largely viewed as an oxymoron. Putting both of those words into the same phrase is considered a joke in many quarters. Whether we like it or not, PHP has a higher benchmark to meet and we’re not meeting it.

Consider for a moment your browser. All modern browsers are maintained by groups which understand a fundamental market force. If your browser fucks up security badly enough, users will use another browser that they perceive as being more secure. The obvious corrective action is to improve security, mitigate the risks of browser based vulnerabilities, and push improvements on multiple fronts to create a Defense In Depth approach protecting against one of the ultimate sources of security problems: The Web Programmer.

It’s not just browsers. Both OpenID and OAuth utilise restrictive cryptographic schemes because, at the end of the day, programmers would otherwise find a way to screw it up. Indeed, the idea of OAuth 2.0 doing away entirely with cryptographic signatures was met with relief in some quarters followed by the realisation that it would now depend on programmers correctly implementing HTTPS – so it was added back in!

Unlike browsers and open standards, PHP appears to defy these shared realities. Let’s consider a web application which allows users to send messages to numerous other web applications. It’s a simple message exchange system not unlike email with the benefit that all messages are encrypted and communicated across HTTPS. When the browser acts as a client, we can be reasonably sure that this is a secure client. Browsers are market driven products so they are intoler

Truncated by Planet PHP.ie, read more at the original (another 9095 bytes)