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

Rick Bragg lists at gmnet.net
Fri Sep 25 13:27:06 UTC 2009


On Fri, 2009-09-25 at 14:29 +0200, Stefan Hornburg wrote:
> 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
> 


Ah perfect, works like a charm -except- I have a retuning problem.  My
more pages give me Internal server errors!  The more list works perfect
on my other catalogs where I am using the [search-region] but with the
[query] they do not!  Nothing in the error logs, just end of script
stuff. AHH!  I think I will start a new thread for this...



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