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

Rick Bragg lists at gmnet.net
Fri Sep 25 15:19:28 UTC 2009

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

Hi, Is there a way to do something like this with a "swish" search?
the mv_searchtype "swish"  is throughing be off here.

This is what I have now...

<form name="search_docs" action="[area search]" method=post>
    <input type=hidden name=mv_session_id value="[data session id]">
    <input type=hidden name=mv_searchtype VALUE="swish">
    <INPUT TYPE=hidden NAME=mv_matchlimit VALUE="25">
    <input type=hidden name=mv_search_file VALUE="products/docs.index.swish">
    <input type=hidden name=mv_search_page VALUE="swish_results">
    <input type=hidden name=mv_coordinate VALUE="1">
    <input type=hidden name=mv_substring_match VALUE="1">
    <INPUT TYPE=hidden NAME=mv_search_map VALUE="
  <INPUT NAME=search1 VALUE="">
  <input type=hidden name=search2 VALUE="">
  <input type=submit form="search_docs" value="[L]Go[/L]">

What is the best way to make this work?

Thanks again!

This message has been scanned for viruses and
dangerous content by Green Mountain Network, and is
believed to be clean.

More information about the interchange-users mailing list