do=goto leaks page existence
authorhttp://anastigmatix.net/ <http://anastigmatix.net/@web>
Fri, 24 Oct 2014 23:45:23 +0000 (19:45 -0400)
committeradmin <admin@branchable.com>
Fri, 24 Oct 2014 23:45:23 +0000 (19:45 -0400)
doc/todo/Zoned_ikiwiki.mdwn

index 6b562215aa81221b87928c0fc2ab3cf1193e93a9..c2dfb7a24d745500e9e8d8053778ba041ada4b52 100644 (file)
@@ -123,6 +123,21 @@ but I'll begin it here.
 
 Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
 
 
 Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
 
+### Leakage of page existence by `do=goto`
+
+An unauthorized client can use a `do=goto` request to find out whether a
+page exists (will be forbidden to view it) or not (will be forbidden to create it).
+
+My first idea was to fix this all within [[plugins/contrib/signinview]] by hooking
+`cgi` first and checking for `goto` and an unauthorized page. But checking authorization
+requires session info, not loaded at `cgi` hook time. Next idea was to somehow skip the rest of
+the chain of `cgi` hooks, preventing `goto` from handling the request, and handling
+it again in `sessioncgi`. But 'skip the rest of this chain' doesn't seem to be something
+a hook can return.
+
+Hmm, maybe change the `do` parameter to something other than `goto` before the `goto` hook
+can see it, _then_ handle it later in `sessioncgi`?
+
 ### Backlinks
 
 What is problematic is when you link a public page in a private page : 
 ### Backlinks
 
 What is problematic is when you link a public page in a private page :