Bug: Certain (hacked) searches can bypass ALLOWWEBVIEW etc

Main.SitaramChamarty, Apr 22: I am sorry I forgot to mention it in the original bug report, but I did indeed have NOSEARCHALL = on in the WebPreferences. No one can actually "/twiki/bin/view" anything in the private web; but they can search, and - using the bookview option - they can get the whole topic for whatever topics match their search. The trick is in having one webname in the PATH_INFO part of the URL and a different one in the "web=webname" form variable in the QUERY_STRING. This, coupled with some tricky caching of Preferences and/or merging of preferences in Prefs.pm, seems to be causing some problems, even when a required correction is made to Access.pm

Once again - my apologies for submitting an incomplete (and therefore misleading) bug report. I have corrected the info now and re-classified this topic.

I have two webs. "Webone" is public - has many users as well as TWikiGuest is allowed. "Webtwo" is private. Only I and 3 other users are allowed even to view this. I implement this using ALLOWWEBVIEW.

Main.SitaramChamarty, Apr 22: also, NOSEARCHALL is set to "on"

But there's a bug. A search such as this:

http://172.19.40.149/twiki/bin/search/Webone/?scope=text&web=on&search=searchtext

works great and correctly refuses to show the user anything from the private web. But if you change "web=on" to "web=Webtwo" (and any perl-savvy user can figure this out!), and so try this:

http://172.19.40.149/twiki/bin/search/Webone/?scope=text&web=Webtwo&search=searchtext

then he sees matching topics from the private web.

I thought I'd solved it when I saw a missing argument to a couple of calls (lines 120 and 127) to getPreferencesValue in Access.pm. But that did not work - these changes were necessary, but not sufficient.

I spent an hour or two digging deeper, but failed. There is some deep bug in Prefs.pm and all the "altPrefs" that it is doing (for efficiency, I think) which somehow fails to return the ALLOWWEBVIEW correctly. It may also have something to do with preference-merging, for all I know.

I basically gave up at that point

Test case

• create two webs - Webone and Webtwo.
• Protect Webtwo from the general public using ALLOWWEBVIEW. Main.SitaramChamarty, Apr 22: also set NOSEARCHALL = on in the WebPreferences
• create a page in the protected web which comtains some word that you know doesn't appear in a whole lot of places
• log in as an unprivileged user
• try http://server/twiki/bin/search/Webone/?scope=text&web=Webtwo&search=searchtext substituting server, searchtext, etc.

Environment

-- SitaramChamarty - 19 Apr 2002

Follow up

This is actually a documented feature, read TWiki.TWikiAccessControl: "If keeping a hidden web out of general use is a consideration, you can prevent the all webs search option from accessing hidden webs, by enabling the NOSEARCHALL variable in WebPreferences."

-- PeterThoeny - 20 Apr 2002

I apologise for not mentioning that NOSEARCHALL is indeed set in my test system, and for not mentioning that in the point-by-point "test case" section above.

Fact is, NOSEARCHALL is set to on, and no one can actually view any pages. But they can effectively search for whatever they want, and they can then use the "bookview" option to see the whole page, and in fact the whole web.

-- SitaramChamarty - 22 Apr 2002

I wrestled with this one for several hours. Here's the problem: whatever web you're in when you run the search script effectively controls the access permissions and clobbers those set in the web designated by the web parameter. If you look at the Prefs.pm script, you'll see what's going on. Let's go back to the example...

http://172.19.40.149/twiki/bin/search/Webone?scope=text&web=Webtwo&search=searchtext

When the search script runs, it first loads all the preferences from Webone in initializePrefs. Ok. Later on, when getPreferencesValue gets called the function dilligently tries to get the prefs for Webtwo . Cool. Except, it will ignore any parameters declared FINALPREFERENCES from Webone . Hence, all the topics appear.

Well, I tried all kinds of special case logic, but honestly I kept breaking other things. I was going to validate the web parameter right in the search script, but I'd have to hack up a new function in Prefs.pm to get the prefs from a web without doing the defaults.

Hack Solution: If you go into Search.pm you can simply comment out the third case in searchWeb where TWiki looks at theWebName (First it sees if it's null, then if it's All or On, else it assumes your specifying specific webs). I lose this functionality but honestly I don't know when I ever use the web parameter in this way anyway. I'd love if someone had a better solution!

-- MattWalsh - 05 Sep 2002