Alex Vanderbist has a recent post to his site showing how to fix an issue with Imagick and the "not authorized" exception that can happen when processing PDF files.

Over the last few days we've had a couple of issues with Imagick and processing PDFs on our servers. As it turns out, these issues are caused by automatic security updates. Let's look into the issue and its solution.

The post starts with an example of the errors they've been seeing with the "not authorized" message in their Bugsnag logs. As they traced the problem they saw it was happening on older codebases too, not just new ones. Finally they tracked down the culprit: a recent security update to Imagick that added extra policies for PDFs that need to be configured for it to work as before. They provide an example of what should be added to your policy.xml file and how to bulk-patch your systems via Ansible.

On the TutsPlus.com site there's a new tutorial posted for the Laravel users out there covering a few pieces of the authorization features of the framework. The tutorial covers "gates" and "policies", introducing some of their basic concepts and providing example code to implement your own.

Today, we're going to discuss the authorization system of the Laravel web framework. The Laravel framework implements authorization in the form of gates and policies. After an introduction to gates and policies, I'll demonstrate the concepts by implementing a custom example.

I assume that you're already aware of the built-in Laravel authentication system as that's something essential in order to understand the concept of authorization. Obviously, the authorization system works in conjunction with the authentication system in order to identify the legitimate user session.

The article starts by introducing some of the basic approaches the framework takes to authorization handling and where gates and polices fit in. It then gets into the details of each including example code showing how to define them based on the interfaces provided. The tutorial then shows how to put them to use in a simple application, applying them at both the controller and view level.

In the latest release of the Laravel framework (v5.1.1) they've introduced authorization handling to the native framework. This allows you to integrate permissions checks and perform policy validation both on the backend and in the templates.

In addition to providing authentication services out of the box, Laravel also provides a simple way to organize authorization logic and control access to resources. There are a variety of methods and helpers to assist you in organizing your authorization logic.

The functionality includes the concepts of "abilities" (permissions, essentially) and validate the allow/deny status based on object properties, such as Users. The documentation shows how to perform the evaluations in the controllers, user model, form requests and even in the Blade templates. There's also a section on creating policies for more complex evaluations than just one-off permission checks.

To get a feel for what the community things of this new functionality, be sure to check out this Reddit thread with feedback, both positive and negative, on how it was implemented.

Pádraic Brady has a new post to his blog about the state of output escaping in PHP and the steps that need to be taken to help prevent and protect applications from the real threat of cross-site scripting.

Automatic escaping has a certain appeal given its goal of removing the need to type escape() all over your templates. Funny thing, though, is that this is basically its one and only advantage. The second claimed goal is to remove a factor of human error (i.e. forgetting to type escape() somewhere), however, this hasn’t posed an issue for me in the past where simple analysis of templates can quickly locate such omissions. And no, using automatic escaping does not remove the need to analyse templates for security issues – that’s still needed regardless.

He goes on to define what "automatic escaping" is and isn't and how it relates to the context of the information (the same data may not always be filtered the same way in every place). He talks about scope-limited escaping, context-aware escaping and an idea that could help make life easier - a content security policy defining how the client should behave when interpreting HTML.

Related to this other post about content security policies in PHP sites, DashExamples.com has a quick new post about what you'll need to add to your application to implement a policy of your own.

Content Security Policy(CSP) is a mechanism in the browser that restricts what content will be requested and run by the browser. CSP does this by passing in a specific response header that tells the browser what resources (images, javascript, css, frames, etc) can be requested and accepted to execute. There are multiple ways to setup CSP for your web site, you can use your web server configuration like I showed in a previous example or use a dynamic scripting language like PHP.

What it really boils down to is setting a header, either X-Content-Security-Policy or X-Content-Security-Policy-Report-Only, to tell the browser what security policy to use and how to honor it. You can find out more about content security policies from this page on the Mozilla wiki. CSPs allow you to define how your site's content interacts and help to prevent issues like XSS and data injection.

Jani Hartikainen has written up a new post for his blog looking at how to combine multiple password validation methods inside of a single application.

If your application is well thought out, you would not want to save any data that isn’t valid. So what do you do, when you need different validation schemes, say for passwords, depending on some special case? [...] There is a better approach: Using a “policy” - Policies can be used for other things than this too, but let’s look at how to use a policy for managing password validation.

He sets up an example scenario where the user sets an invalid and valid password and shows how policies for password validation (regular expression matches and other validation techniques) can provide a simple way to ensure the user has entered the right information.

In an effort to keep things a bit more secure (after finding out about this) the symfony team has officially released their own security policy to help prevent issues like that in the future.

You may be wondering why it has been taking us such a long time to react. Here's the main reason: we had not a very strong security alert reporting and qualifying process. This has been fixed recently. So as of now, if you find a security bug in symfony, please send an email to security at symfony-project.com, with as much details as you can and ideally a patch if you can provide one.

The wiki has a whole section on how to report security issues to get them to the right place.