[ic] Interchange security releases: 5.7.2, 5.6.2, 5.4.4

Peter peter at pajamian.dhs.org
Fri Sep 25 08:33:25 UTC 2009


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



More information about the interchange-users mailing list