[AppDb] [2/3] safe functions

[Chris Morgan]

On Monday 26 June 2006 1:50 am, Jonathan Ernst wrote:
> Le dimanche 25 juin 2006 à 20:00 -0400, Chris Morgan a écrit :
> > Hi Jonathan.
> >
> > You'll want to talk to EA about the filtering changes.  The plan is to
> > filter using the same syntax and flags that the php filter extension
> > is going to use so we can easily switch over to this extension in the
> > future.
>
> I know we could use PEAR and we could also use a database abstraction
> layer, I just thought my solution was better because it has proven to
> work well on several projects I worked recently and is recommanded by
> the php manual (and it makes queries more readable than using other
> syntaxes).
>

The most effective solution involves both filtering and sql protection.  The 
first layer of protection is to filter each input variable down to the most 
restrictive data we can accept.

The next step is to ensure that each query, independent of the data passed in, 
is safe because of the appropriate quoting.

With both of these layers in place we can be pretty sure that injection and 
other attacks on the code will be much less effective.  We could probably be 
secure with only the sql protection in place but the filtering raises the bar 
greatly for any potential exploits of sql or any other logic in the appdb.


> > Also, I've submitted a patch for review to appdb at winehq.com and
> > wine-patches at winehq.com that removes all of our get_magic_quotes_gpc()
> > use and adds a check in include/incl.php that warns and prevents appdb
> > from running if magic quotes is enabled.  So you shouldn't need to
> > have any get_magic_quotes_gpc() checks anymore.
>
> Isn't it better to support both configurations ? My solution works with
> or without magic quotes.
>

I don't believe so.  If you read the patch that I submitted or look in 
include/incl.php you'll see the reasoning behind not bothering with magic 
quotes.


> > I also noticed your quote_smart_sql() call.  This call isn't used
> > anywhere, we shouldn't add calls to functions that aren't called.  We
>
> It is used in 3/3.
>
> > also already have a function that will make sql calls safe called
> > query_paramters() in include/db.php.  Also, do we want to strip tags
> > from sql?  Won't that remove all tags from things like app/version
> > descriptions, comments and notes?
>
> No, there is a parameter in this function (quote_smart_sql). By default
> we don't remove html, but for some fields we might want to filter out
> html (comment titles, etc.)
>
>

Ahh I see.

Chris