more security in regards to $page->id

[er314]

Hello, 
 
Here is a security related feature request.
 
I am having more and more use of $page->id as a GET or POST parameter, for various workflows in frontend site.
Processwire itself is making use of it at some places related to frontend, eg. for comments submission workflow.
 
My problem is : This is an absolute AND predictable value : from 0 to N. So, when used for submission by the users, it allows a malicious user to forge requests in order to perform a FULL crawling of the website pages. Even pages that are otherwise not accessible by following the website links. Of course, Processwire access permissions apply ; but then, any site-specific permission weakness will result in information disclosure. Overall, this is not very satisfying.
 
What would be best, instead, is the ability to make use of an absolute AND NOT predictable value : a $page->encodedId (build with something like http://hashids.org/php/)
Along with a commodity method getDecodedId(), for retreiving the associated $page->id.
 
Fact is, I am doing something similar to this in the templates which need it. 
And, for easier usage, I plan to generalize this to all templates, with some coding which implies hooks on template creation & on page creation, for automatically adding a $page->encodedId field at each template creation + automatically populating its value at each page creation/cloning.
 
But before I go into this, I would like to submit this feature request : I would rather have this in Processwire core
Processwire itself would directly benefit from this feature (see comments submission workflow, for instance).
 
I hope it makes sense for someone else than me
cheers

Edited August 9, 2015 by er314
Fixed hashids link

[LostKobrakai]

+1 for this request. 

While it's always in the hands of the dev to prevent malicious access to content, even if someone does fiddle with some id's, it's still an added layer of obstruction. This can for example be handy when using id's on the frontend site, like as urlSegments.

[er314]

Or... another solution, for not adding the burden of needing new fields : have PW migrate to using unguessable IDs, instead of the current 1-to-N scheme.

In practice, make all page IDs for newly created pages unguessable, à la youtube hashes.

This would mean, for a fresh install, make all IDs this way. -> As an install option, for compatibility with legacy applications. And probably for some "root" IDs it would be hard and/or too much implications to follow this path.

Yes, I know : even though at first sight things looks clean from the API side for going towards this path ($config->xxxxxPageID , $user->isXxxxx) , I know that things must be much more complex than this :

1. there's the problem of legacy applications, which probably for most of them don't make full use of $config->xxxxxPageID  and $user->isXxxxx

    -> hence being optional at install time and at runtime

2. there must be a huge number of implications in PW core ; and potentially in many modules.

But hey, this is for opening the discussion. Probably another lost cause

cheers

[LostKobrakai]

While I liked the idea of having a new method, which would provide an encrypted id (autogenerated salt like for the user passwords) I don't think there's any necessity to change the underlying id system, especially as this is a default behaviour of mysql. Do you have any usecase examples, where this would be needed? 

[er314]

No, I have absolutely no use case where this alternative proposal would be needed in place of the 1st method.

I was just trying to see if it's simpler/cleaner than the 1st method.

My rough guess was that, it might be cleaner from a public API perspective (no new method needed), but much more complex internally. You are just confirming this, in regards to mysql

[Pierre-Luc]

Hey, this is the exact use case why I made the http://modules.processwire.com/modules/process-field-generator/ module. It will generate crypto safe strings to use as page names (you don't have to expose the page id, especially with the combined use of urlSegments as a view handler).

[horst]

@Pierre-Luc, if possible, you should update the compatibilty list of that module, - it only shows PW 2.4. 

All your other modules are up to date in this regard and shows versions inkl. PW 2.7

[Pierre-Luc]

Forgot to update it. Now done, thanks to notifying me!

[er314]

Hi Pierre-Luc, 

I've just read your module documentation, and I confirm that yes, this is exactly what I'm talking about ! Plus you have made sensible customization settings.

superbe !

Guillaume

[tibs]

TL;DR Everything could already use the paths instead of the ids; it just needs some work to implement. If the ids are so unwelcome, why not go and work on the right kinda complicated stuff instead of adding unnecessary (and probably useless) complexity by inventing an obscure layer of "protection"?

 

There's already an unambiguous 1-to-1 relationship between paths and ids; not using paths at certain places (e.g. assets and edit pages and whatnot) is not an architectural decision but that of convenience and performance. In other words, nothing stands in the way for the whole system to use the paths everywhere, i.e. /my/awesome/page/edit instead of /admin/page/edit/?id=3811 -- one can just set up a few .htaccess rules, rewrite (or hook?) whatever generates the ugly edit links, and done.

Or, almost. It gets more involved for the asset paths, where there are two options I can think of. A) In the current storage, where the asset directories are addressed by the page id, Apache would need to consult the DB to resolve the paths to the ids. And that needs a module, which raises the bar for hosting. B) Then there is the option to use the page paths within the assets directory, but that may be a bit messy when moving / renaming things (the DB and the file system can get out of sync when something happens, so some journaling would be necessary.)

P.S. I did use SHA based page ids before, to make scraping super hard (random access impossible) so I do agree that it has legit use cases. "Security" (i.e. "I don't want the baddies know too much about how I store my data" and the like) isn't one of them. Or am I missing something?