Authentication using Zend_Amf

Kevin Schroeder writes; I forget why, but a few days ago I started doing some digging around with authentication in Zend_Amf_Server. I had figured that I would add an adapter to the Zend_Amf_Server::setAuth() method and that would be it.

But I was wrong.

AMF allows for multiple request bodies to be sent at the same time. Of those there are several “special” types of commands. One of those commands is logging in. What this means is that you don’t need a method that logs someone in for you. Zend_Amf_Server handles authentication separately from your service classes.

Authentication for Zend_Amf_Server will generally use a combination of Zend_Auth and Zend_Acl components. Zend_Auth is used to provide the credential verification while Zend_Acl is used to validate that the current user user can access the requested service method. It is actually a relatively trivial task to restrict access to non-logged in users using the method that I will describe here.

The first step in the process is to create an authentication adapter. It really doesn’t matter what you’re using. What matters is that the adapter returns an identity object with a property called “role”. The built in ACL handle expects this to be part of the identity object.


class Auth extends Zend_Amf_Auth_Abstract
{
const LOGGEDIN_ROLE = 'loggedin';

public function authenticate()
{
$identity = new stdClass();
$result = Zend_Auth_Result::FAILURE;

// Do a proper login, y'all
if ($this->_username == 'test' && $this->_password == 'test') {
$identity->role = self::LOGGEDIN_ROLE;
$result = Zend_Auth_Result::SUCCESS;
} else {
$identity->role = Zend_Amf_Constants::GUEST_ROLE;
}

return new Zend_Auth_Result($result, $identity);
}
}

The Auth class extends Zend_Amf_Auth_Abstract because Flex seems to require username and passwords as being the only mechanism for passing credentials. The abstract class defines a method that hooks in with the special commands and passes the special credentials to the special adapter. Clearly your authentication mechanism should be better than the one that I put in here, but you’ll get the idea. The most important part is adding the role property to the identity object and passing it to the Zend_Auth_Result object.

Then in your gateway you need to add this adapter as well as create an simple ACL.


$server = new Zend_Amf_Server();
$server->addDirectory(realpath(__DIR__.'/../services'));

$acl = new Zend_Acl();
$acl->addRole(Auth::LOGGEDIN_ROLE);
$acl->allow(Auth::LOGGEDIN_ROLE);
$server->setAcl($acl);

$auth = new Auth();
$server->setAuth($auth);

echo $server->handle();

This adds the new Auth role to the ACL and says that it has access to everything. Since there is no place where I allow guest access (denoted by Zend_Amf_Constants::GUEST_ROLE in the adapter) guest requests will be denied.

With just this little bit of code you now have a mechanism that will provide restricted access to all of your service objects.

via Kevin Schroeder’s blog – Zend Technologies.

Zend Framework – Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend Framework, please report it to us at [email protected]. We will work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

  • Component(s) affected
  • A description indicating how to reproduce the issue
  • A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the project contributors a chance to resolve the vulnerability and issue a new release prior to any public exposure; this helps protect Zend Framework users and provides them with a chance to upgrade and/or update in order to protect their applications.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

  • We will patch the current release branch, as well as the prior two minor release branches.
  • After patching the release branches, we will immediately issue new security fix releases for each patched release branch.
  • A security advisory will be released on the Zend Framework site detailing the vulnerability, as well as recommendations for end-users to protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as via a feed (which is also present in the website head for easy feed discovery)

via Zend Framework.

Zend Framework Security Related Releases Now Available

And finally there has been some actual movement on securing up the Zend Framework in an proactive fashion (at least from now on:) )

As announced earlier by Matthew, Zend Framework 1.9.7, 1.8.5 and 1.7.9 have been released incorporating routine maintenance and a number of security fixes detailed in the announcement. It's recommended that framework users upgrade as soon as possible to the latest release of whichever of these minor branches they are using.

As the announcement also indicates, following December's excitement I spent much of the Christmas and New Year period conducting a security review of the framework. While an ongoing process, the initial review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. The results of that initial review were reported over the holidays to the Zend team, who patiently put up with my long winded emails and managed not to strangle me…so far. I'm keeping myself holed up in the mountains for now ;-).

The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers. These will not be disclosed at this time, and will not form any new advisories for the simple fact that ZF 1.10 currently exists only as an alpha release where issues are to be expected anyway. Regardless, you all owe me extra cookies for those ;-).

On to the vulnerabilities, the majority are linked to encoding inconsistencies. One of the more far-reaching results of the fixes is that all developers should note the Zend Framework now enforces a default character encoding of UTF-8, including Zend_View which until now has defaulted to ISO-8859-1. This will require users needing that encoding to now set it manually. In addition, numerous classes have been given methods allowing developers pass in their preferred encoding. It's essential you do so to benefit from the full protection of all escaping mechanisms using htmlspecialchars() and htmlentities(). The remaining vulnerabilities are self-explanatory and, besides upgrading, require little additional work on your part.

It's also important to note that these fixes often go beyond fixing the immediate symptoms. So reporter's credit aside, thanks to Matthew, Ralph and Thomas Weidner who worked on the patches for these fixes as well as spending the time discussing and debating them all in turn. I'm sure Matthew and Ralph had lots of fun (in between apoplectic fits) preparing for three releases but it's truly appreciated.

I remember from December (when not ranting ;-)), that one of the identifiable problems with the Zend Framework was its overall security strategy which has been reactive in nature. The reason for performing this security review, in addition to finding it exciting to spend hour after hour staring at source code (I'm being sarcastic), is that my original rant was misdirected in one aspect. If the framework is reactive, it is because everyone who contributes source code also contributes to that particular attitude. Performing the review was one way of breaking the reactive trend, and so instead of having these security issues persist into the framework's future versions to be discovered by accident (or not), they have been deliberately searched for, found, poked, prodded, debated and then dutifully exterminated. Welcome to proactivity.

If there is a point, it is that as Zend Framework contributors it's still ultimately our job to enforce and promote a security awareness. We can't pass that responsibility to Zend (all of three employees) and wave our hands innocently. We now have two new jobs we better get used to. The first is applying the new Security Policy and notifying the security channel of any reported or self-discovered security issues. Don't sit around wondering if it's a problem, send it in and let the guys look at it. That goes for all security issues without exception (or should). Secondly, we need to build some semblance of a security conciousness because at present that is sorely lacking. I believe the Zend guys are on a similar track here so they may have more to say in the near future. I'll doubtlessly blog about these two topics more specifically over the next few days.

In the meantime, you have some new releases to work with ;-). I sunk a lot of time into this, but being an open source project it's only right you exploit that for all it's worth :-P.

via Maugrim The Reaper’s Blog.