Gilles Detillieux (firstname.lastname@example.org)
Mon, 3 May 1999 11:58:12 -0500 (CDT)
For security concerns, there are two points which you should keep in mind:
1) Even if the user can't access matched documents because they're
password protected, there may be information you don't want the user to
see right in the document excerpts on the search results page. Making
sure that no matches are found for "secure" documents may be crucial,
unless you don't store excerpts for these.
2) Any input parameter to htsearch can be overridden by the user.
I can type in a browser's location window:
to bypass any attempts by the search form to keep me out of certain areas.
It seems to me the only way to avoid having users see things they
shouldn't is to build separate databases for secure and non-secure access.
Even so, you should also make sure that the search forms for secure
areas are themselves secure, because you don't want a user to see (or
even guess at) the config file names for the secure area databases.
According to Torsten Neuer:
> According to Nathaniel Irons:
> >On 5/1/99 at 2:33 PM, email@example.com (Torsten Neuer) wrote:
> >> Instead of parsing the output, generate a dynamic search frontend using
> >> the user's id to create hidden "restrict" and/or "exclude" input fields
> >> for htdearch.
> >But if the data is interesting, and/or the users are relatively adept, I don't
> >see any reason not to expect them to create their own query strings. It'll be
> >trivial if all they have to do is remove an argument or two to htsearch.
> It really doesn't matter if the data is "interesting" when a person has
> no permission to look at it and/or use it. "Exclude"/"restrict" do not
> limit the users by means of query strings. The users are still able to
> create their own queries - but only in the data areas they have access to.
> >Slightly safer would be adding required keywords to each successive level of
> >access, so gaining higher levels of access would require additional knowledge.
> >Safer still would be building separate databases around significant shifts in
> >access privileges, and using the user's id to generate pointers to entirely
> >different configuration files, whose location you could easily randomize every
> >so often. It depends on how secure you need to be.
> If the user access is limited to designated areas by password, keywords
> will be extremely *unsafe* and *insecure*, thus revealing areas to those
> who normally do not have the right to access them. "Exclude"/"restrict"
> limits the queries to those areas where access is granted. If queries
> are to be limited by special keywords, they will be revealed to users
> who look at the HTML source of the query form and thus will be able to
> gain access to hidden and secure areas via search queries.
> Therefore limiting queries for users with different access rights, the
> use of "exclude" and "restrict" is the only choice.
-- Gilles R. Detillieux E-mail: <firstname.lastname@example.org> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 ------------------------------------ To unsubscribe from the htdig mailing list, send a message to email@example.com containing the single word "unsubscribe" in the SUBJECT of the message.
This archive was generated by hypermail 2.0b3 on Mon May 03 1999 - 10:07:32 PDT