[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.


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