System info:
Shared hosting

Linux

   2.6.17.11-grsechg

Apache

  v 1.3.37 (Unix)

PHP

  v 4.4.4
MySQL v 4.1.22-standard

I have several sites where I offer a search box for the visitors.
The majority of these sites have an extensive catalog of
products in the db.  The search function(s) work just fine.

Reading around the

net

 , I have come upon some info that makes
me extremely nervous.  The info revolves around script injection.

Now, on all but one of the sites, the search isn't a necessity.  The
products are arranged well and the db schema will bring up the
desired product 99.9% of the time.  The remainder is because my
fuzzy logic is a little fuzzy.  LoL.  A review of my log files shows
that visitors use the search function in less than 1 in 300 views.

One site needs the search function.  Very much.

So, these QQ:

On the sites where the search is not a necissity, is it worth the
trouble to fix it?

On the site where I do need to have a search capacity, what in the
hell can I do to preserve 1..my sanity, 2..database integrity, 3..
protection against injection problems?

**Note that on the site where I need search, the Roosian Spamers
have started to find me.  So far it's limited to link injection, but it
can't be long before ........................

Thanks,
very much your loving companion in web endeavors worldwide.  Click
here for your lovelife horoscope.  <>Here

(LoL.  Couldn't resist.  You guys are seriously serious here.)

First and easiest: if you can exclude any form of punctuation at all in a search, then allow nothing but alpha num chars in a search. This is a one-line fix:

(I'll have to make a few assumptions for this example, hope it makes sense)



This would turn 'http://www.adomain.com' into 'http   www adomain com' which may or may not be what you want, but that'll stop quite a variety of attacks. The XSS stuff is yucky, but if I hear you correctly its MySQL injection that you are most afraid of.

Things like the MySQL fulltext index won't care about punctuation anyhoo, so this is a reasonable fix IMO.




Fair enough.

dnk

I don't recall how to do it anymore, but isn't there a way that you can use numeric codes to spell out punctuation symbols in an input field? Not ascii codes mind you. Maybe I'm just losing my mind, you'd know a lot more about it than I, Perk.

There is... I don't remember either, I'm sure JasonD does... but in any case, it'll require a & or # or something and would get changed... I don't think that something like 0x4A would trigger a ascii translation

Yes, I think it was a %

Used to do some tricky shit with myspace to set up redirects on profiles.

funny coincidence.

I am currently trying to get all the info together to write my own
mysql_real_escape_string function

I don't like trusting some off the shelf function that I can't see the nuts and bolts of for a MAJOR security defense.

I am creating my own SQLsafe and HTMLsafe functions, which sanitize sql for insertion, and HTML for display to the page to prevent XSS. the problem is I already have this all for

ASP

 /MSsql, but not

PHP

 /MySQL which seems to have more vectors to deal with.

Just escaping single quotes is NOT enough. you need to worry about a few other things with MySQL, plus a few unicodes.
also if you are passing and ID's from the client side, such as id=123 in the URL, you should validate/sanitize that as well. I can fish you hard if you just blindly plug an ID into your select query without validating it.

If someone can post a list of the MySQL injection vectors, ie. the characters and entities I gotta check for, I will post my sanitizer function when I am done with it.

This is the read that I started with quite a while ago and it still stands IMO:

http://www.tizag.com/mysql

Tutor

 ial/mysql-

php

 -sql-injection.

php

 

Yea, i have had that bookmarked for a long time. It doesn't cover the deeper injection methods though. I also read that that function is vulnerable though I cant seem to find that article now.

((I posted a thank you note a few hours ago, but it is m i a.  Is theEarl in charge of the database backup here?))

Thanks Perk.  The snippet will solve most of the problems I forsee.  It might even help on the potential xss
problems that will eventually show up.

Had one of those off-the-wall thoughts that I thought to run by you guys.

What about the site search functions available from Gooog and Yahoooie?

Are they proof against link injection?  Are they immune from cross scripting?

From an XSS perspective, if you *never* show back what was actually searched for ie., "Your search for [insert search phrase here" did not return any results, then you're really not an XSS candidate. You could to a parasitic thing, but that's a different story.

From a DB injection thing, there are really only two ways to go from a programmer perspective: If you MUST take user input for something ie a search box, clean the hell out of it. In my case, I simply do not allow any non-alphanum chars in my search string and that'll take care of it. Other than that, I isolate what the user sends from what I throw up against the DB ie., a switch statement that creates the SQL rather than the information coming directly from the surfer. Clearly, in formst where I need a name or address or something I am more exposed, but I clean every string on the way in and make sure it looks exactly the way that I want it to before it goes into the DB.

But even typing this right now I remember an application where I was less than strict ... and it is in production. Best be off to go have a look!