New more Secure Auto Routing

Since the current auto routing is a security risk, the default would be changed to disabled in v4.2.0.
See https://forum.codeigniter.com/showthread...#pid395045
We don't recommend to use it.

But auto routing is a convenient feature that eliminates the need to define each route, making it easier to develop.

So I would like to introduce optional New more Secure Auto Routing:

• A controller method needs HTTP verb prefix like `getIndex()`, `postCreate()`.
  • Developers always know HTTP method, so requests by unexpected HTTP method does not happen.
    
• The Default Controller (`home` by default) and the Default Method (`index` by default) must be omitted in the URI.
  • Restrict one-to-one correspondence between controller methods and URIs.
    
  • By default, you can access `/`, but `/home` and `/home/index` are 404.
    
• It checks method parameter count.
  • If there are more parameters in the URI than the method parameters, it results in 404.
    
• It does not support `_remap()` method.
  • Restrict one-to-one correspondence between controller methods and URIs.
    
• Can't access controllers in Defined Routes.
  • Completely separates controllers accessible via Auto Routes from those accessible via Defined Routes.
    

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

Thank you @kenjis .

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

Thank you for all the hard work Kenjis

Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com

This feature was implemented in develop branch.
See https://codeigniter4.github.io/CodeIgnit...to-routing

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

Thank you @kenjis.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

I am trying to upgrade some CI4 websites from 4.1 to 4.3 and was startled to see that _remap was removed and that instead of index we must define getIndex method. This requires extensive changes to my websites and makes for some very ugly method names in my controllers. I'm inclined to continue using the legacy routing. Can someone please refer me to discussion that shows 'current auto routing is a security risk' ? I'd like to see that discussion. I don't use any of the filter functionality, and this new auto routing doesn't really look like an improvement to me.

@sneakyimp Don't worry. You can still use legacy auto routing as before.

The risk here is that the controller filters are bypassed.
See https://forum.codeigniter.com/showthread.php?tid=81379

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

Supplementary information on the risk here.
The controller filters being bypassed is the most obvious risk and the most significant.

The problem is that developers are not strictly aware of HTTP methods of a request, which can lead to defects if an attacker accesses the site with an HTTP method that the developer does not anticipate.

If the HTTP method does not change the processing, it does not seem to cause any particular problem, so I do not consider this to be a big risk. However, this is not to say that there is not a major risk of which I am unaware.
At the very least, the auto routing legacy will accept requests that do not need to be accepted.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

The controller filters being bypassed is the most obvious risk and the most significant.

As I stated in my post, I don't use filters explicitly, it is helpful that you have pointed out that CSRF protection is implemented with a filter. More on that below...

The problem is that developers are not strictly aware of HTTP methods of a request, which can lead to defects if an attacker accesses the site with an HTTP method that the developer does not anticipate

I believe that being unaware of HTTP methods is an individual failure -- this introduces a risk which cannot be effectively remedied with better filters. Fundamentally, developers should adhere to the policy that GET operations just retrieve information, whereas POST operations are for changing server state

@sneakyimp Don't worry. You can still use legacy auto routing as before.

I'm relieved to know that I can continue to use the 'legacy' routing method -- although I must protest that it is referred to as "legacy" -- this implies OLD and OUT OF DATE and, eventually DEPRECATED. One of the things that appealed to me most about CodeIgniter was the simplicity of code organization -- the intuitive mapping of SEO-friendly URLs directly onto controllers without the need to maintain a complicated routing table. Routing tables are nice if you need fancier routing, but I believe they can introduce an additional aspect of complexity that is not just tedious, but error-prone as well. It's also quite a big change from one minor version to another if suddenly all of your autorouted methods are broken.

The risk here is that the controller filters are bypassed.
See https://forum.codeigniter.com/showthread.php?tid=81379

Personally, I feel that relying on filters to implement access control seems like a bad idea for a couple of reasons:

1) the security risks you have pointed out arise from bypassing filters, not autorouting. You expressly state the risk arises when 'there is another route with no filters.'

This vulnerability will be created when a controller method is accessible by a way that a developer does not expect,
and there is a way to bypass a checking, e.g. there is another route with no filters.

While it is true that autorouting might introduce routes a developer does not expect, so might a routing table.

2) separating permissions and access control into separately defined filters makes it less clear what permissions are required where because these permissions would live in some entirely different location from the controller methods. I believe that enforcing permissions directly in a controller is more secure, makes it much clearer how access is controlled, and completely eliminates the confusing three-way tangle of routes/filters/controllers, etc.

As for CSRF filtering being implemented by filters, I am torn. I certainly make use of this filtering, but I'm not sure there is any problem that it only applies to POST operations? I wouldn't profess to be an expert, but I have difficulty seeing how a GET operation is at risk for CSRF? In my case, if I'm expecting an operation to be POST, I always enforce that in the controller method. On the other hand, if we should enforce CSRF for GET operations, shouldn't the CSRF functionality be improved to also include GET operations?

2) separating permissions and access control into separately defined filters makes it less clear what permissions are required where because these permissions would live in some entirely different location from the controller methods. I believe that enforcing permissions directly in a controller is more secure, makes it much clearer how access is controlled, and completely eliminates the confusing three-way tangle of routes/filters/controllers, etc.

Yes, it is true.
So relying on filters to implement access control might be a bad idea.

But CI4 already has controller filters and there is no way to set a filter to a controller.
It seems better to have a way to set a filter to a controller.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper