[ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4
Stefan Hornburg
racke at linuxia.de
Fri Sep 25 12:29:48 UTC 2009
Rick Bragg wrote:
> On Fri, 2009-09-25 at 01:33 -0700, Peter wrote:
>> On 09/24/2009 11:54 PM, Gert van der Spoel wrote:
>>>> -----Original Message-----
>>>> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
>>>> users-bounces at icdevgroup.org] On Behalf Of Rick Bragg
>>>> Sent: Friday, September 25, 2009 9:47 AM
>>>> To: interchange-users at icdevgroup.org
>>>> Subject: Re: [ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4
>>>>
>>>> On Fri, 2009-09-25 at 06:38 +0000, Rick Bragg wrote:
>>>>> Thanks for this update, I have updated all my e-commerce catalogs with
>>>>> no problems at all except for one that is scheduled to go live on next
>>>>> Wednesday. The countdown to bringing Montpelier live has started, and
>>>>> the city is like a mob scene, they will be banging on my door because it
>>>>> is already really late :)
>>>>>
>>>>> Anyway, my issue is that I am using lots of new tables that I have build
>>>>> for "content management" and "social networking" purposes. I am using a
>>>>> search similar to the "search_box_smnall" and "advancedsearch" for much
>>>>> of the content, also I am usinig a "swish" search for pdf files. The
>>>>> tables are somewhat private so I don't want to open them up in the
>>>>> "AllowRemoteSearch" config directive in catalog.cfg
>>>>>
>>>>> Are there new ways to use these kinds of searches? Or is there a
>>>>> temporary work-around that I can do for now?
>> The best thing you can do is to pass the user entered search parameters
>> in CGI variables, for example you can do something like this:
>>
>> <form method="post" action="[area my_results_page]">
>> Foo Search Field: <input type="text" name="foo" size="40"><br>
>> Bar Search Field: <input type="text" name="bar" size="40"><br>
>> <input type="submit" value="Search">
>> </form>
>>
>>
>> ...then on the page, my_results_page you would do something like this:
>>
>> [loop search=|
>> fi=my_table
>> st=db
>> co=1
>> sf=foo
>> se=[cgi foo]
>> sf=bar
>> se=[cgi bar]
>> rf=baz,biz
>> |]
>>
>> <p>
>> baz is: [loop-param baz]<br>
>> biz is: [loop-param biz]
>> </p>
>> [/loop]
>>
>>
>> The above type of search is safe from being exploited by this
>> vulnerability and will continue to work without having to add the tables
>> to AlloRemoteSearch.
>>
>>>> Actually, I set it up so that all the people using the system are
>>>> logging into the affiliates database and nobody will be able to put ITL
>>>> anywhere in the site (except the planning department who I am letting
>>>> do anything anyway). However, I will be letting the Clerk login to the
>>>> admin area ONLY for "orders". So is it safe to open up these tables in
>>>> this case?
>> No, a user does not have to be logged in as an admin or anything
>> important to take advantage of this vulnerability.
>>
>>> You can allow tables temporarily via something like:
>>> push(@{$Config->{AllowRemoteSearch}},'TABLE');
>> This only works in very limited cases and has to be done on the search
>> results page, but run before the search results are processed. It may
>> or may not work before the [search-region] tag, I'm not sure. Keep in
>> mind that if you do this you could still be open to an attack.
>>
>>
>> Peter
>>
>> _______________________________________________
>
>
> Ah! I love the new search form idea. can I also use just a [query] tag
> instead of [loop] on the results? I like to use additional SQL right
> there! That will also solve other problems I am having such as trying
> type in "fixed wheel gear" and returning rows that match "fixed gear"
>
Yes, you can do this. Just make sure to sanitize the user's input before
feeding it directly into a SQL query.
Regards
Racke
--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
More information about the interchange-users
mailing list