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

Rick Bragg lists at gmnet.net
Fri Sep 25 12:20:01 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
> 
> _______________________________________________


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" 

As for the mob, they are a very nice, socially responsible, and peaceful
mob :)




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