>Thanks for the feedback, Myles. We may be better off staying with what

we have as it adds a layer of isolation between our databases and our
web pages. We don't carry any passwords, credit card info, etc. in our
databases, so that is not an issue.

OK, and I think its probably a good idea. But consider this scenario
(as hypothetical as it might be) to help illustrate a point...

You allow any data to be stored in Firebird from the web. So "Bob" goes
to your site, and enters something like:

'javascript:top.location.href = "/attacktargetsite.com/badpage.html"'

as data in a field your database and saves it. And you let it through.

Then someone does something via the web that retrieves that data and
displays it on a web page somewhere.

What happens? Their browser immediately executes the Javascript and
does their bidding just by opening a page on your web site (in this
example).

Now this is incredibly simplistic, but consider that you change the
Javascript to do something a bit more malicious (like having a Phishing
site that created on some bad server that looks like your website and
asks the customer who thinks they are 'trusted' to re-enter their login
ID & Password, or enter their credit card no, etc.). You can imagine
the possibilities. That site captures their credentials and then
someone from that site now pwns them on your website.

This is an elementary XSS (Cross site scripting attack) that would only
be able to be thwarted if you sanitized the data BEFORE it was saved in
the database. Sanitizing means checking for specific content that would
represent executable JS, etc. That's a bit more than just worrying
about parameter passing, etc. It needs specific content sanitization.

Myles
--
-------------
Myles Wakeham
Director of Engineering
Tech Solutions USA LLC
www.techsolusa.com