Comments on: Security issue in CakePHP code documentation http://spacebug.com/security_issue_in_cakephp_code_documentation/ Keeping Software Simple, Open and Pragmatic. Wed, 11 Jan 2012 01:15:39 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: anonymous http://spacebug.com/security_issue_in_cakephp_code_documentation/comment-page-1/#comment-105 anonymous Sat, 06 Mar 2010 20:47:20 +0000 #comment-105 Totally agree, developers will see this example and will probably write less secure code as a result. isAuthorized should be written like Auth->allow(...) Totally agree, developers will see this example and will probably write less secure code as a result. isAuthorized should be written like Auth->allow(…)

]]> By: Amir Shevat http://spacebug.com/security_issue_in_cakephp_code_documentation/comment-page-1/#comment-104 Amir Shevat Sat, 06 Mar 2010 10:13:00 +0000 #comment-104 The whole point of examples is to demonstrate best practices, developers use the example to develop their application and rarely diverge from the example. My point in this post is that an authorization method that returns “authorised” by default is not best practice. Look at how auth->allow() works in cakePHP examples: $this->Auth->allow('foo', 'bar', 'baz'); It works in a white list fashion – you specify the methods you want to provide public access to, and all the rest are blocked by default. The isAuthorized methods should demonstrate the same consistency and use a white list to allow privileges to specific roles and block all the rest. Security examples should drive security best practices and be secure by default. The whole point of examples is to demonstrate best practices, developers use the example to develop their application and rarely diverge from the example.
My point in this post is that an authorization method that returns “authorised” by default is not best practice.

Look at how auth->allow() works in cakePHP examples:

$this->Auth->allow(‘foo’, ‘bar’, ‘baz’);

It works in a white list fashion – you specify the methods you want to provide public access to, and all the rest are blocked by default.

The isAuthorized methods should demonstrate the same consistency and use a white list to allow privileges to specific roles and block all the rest.

Security examples should drive security best practices and be secure by default.

]]> By: anonymous http://spacebug.com/security_issue_in_cakephp_code_documentation/comment-page-1/#comment-103 anonymous Sat, 06 Mar 2010 08:01:39 +0000 #comment-103 So? That's the point of the AuthComponent in the first place. The developer in the example has decided that the only action requiring escalated privileges (<em>aside from already being logged in</em>) is the delete function; they've decided that the others are available to authenticated users. Furthermore, why should it be the case for all functions? You're applying your requirements on an example, you don't know their needs or requirements, <strong>it's just an example</strong>. So? That’s the point of the AuthComponent in the first place. The developer in the example has decided that the only action requiring escalated privileges (aside from already being logged in) is the delete function; they’ve decided that the others are available to authenticated users.

Furthermore, why should it be the case for all functions? You’re applying your requirements on an example, you don’t know their needs or requirements, it’s just an example.

]]> By: Amir Shevat http://spacebug.com/security_issue_in_cakephp_code_documentation/comment-page-1/#comment-101 Amir Shevat Fri, 05 Mar 2010 08:59:00 +0000 #comment-101 But the issue is that the isAuthorized method protects all methods in a controller - not only the delete function. Look at the code of the isAuthorized that handles the delete function. It checks if you are an admin in defaults to unauthorized if you are not admin - this should be the case for all functions Even if you only want to protect a single method right now you should explicitly allow access methods and return unauthorized by default. You simply cannot return authorized by default. But the issue is that the isAuthorized method protects all methods in a controller – not only the delete function.

Look at the code of the isAuthorized that handles the delete function. It checks if you are an admin in defaults to unauthorized if you are not admin – this should be the case for all functions

Even if you only want to protect a single method right now you should explicitly allow access methods and return unauthorized by default. You simply cannot return authorized by default.

]]> By: anonymous http://spacebug.com/security_issue_in_cakephp_code_documentation/comment-page-1/#comment-67 anonymous Fri, 05 Mar 2010 08:51:29 +0000 #comment-67 That's not the case here though. It seems the intention of the example is to only delineate access when performing deletes and that the act of deleting should only be performed by "admin" users. That’s not the case here though. It seems the intention of the example is to only delineate access when performing deletes and that the act of deleting should only be performed by “admin” users.

]]>