The updated search module in CVS add a check_query to the search terms, which in turn runs addslashes on all input search term. This completely blocks out all search on non-ascii terms. All multibyte language would rely on binary match for a search.

Of course the revised module is more safe than before, and the previous version does not search multibyte language without modification anyway. So, I will have to customize this one also.

So, my question is, what is the security consideration for adding this check_query, even when it is just querying into the search_index, or to the teaser/body field in my case. Worried that it might just break the query itself? Is it possible that they pass in some malicious query to change the query completely? Say, querying some other table, or even do some modification?

Thanks for any advice.

Comments

jb605’s picture

jb605 commented

The problem was also contributed by the fact that we remove substring search in search.module. Here is the diff result.

< // no results. try a substring search
< $output = search_data("*". $keys. "*");
<
< if ($output) {
< theme("box", t("Search Results"), $output);
< }
< else {
< theme("box", t("Search Results"), t("Your search yielded no results."));
< }
---
> theme("box", t("Search Results"), t("Your search yielded no results."));

Because of the fact that multibyte language can not be broken into words the way English is done, substring search is necessary to obtain results.

Steven’s picture

Steven commented

This is a duplicate of #2142. This issue was earlier, but the other one has clearer explanations.