manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: Release?
Date Tue, 07 Dec 2010 00:45:22 GMT
quoteSQLString is used mainly for data content that is not directly
sourced from input, such as state values, etc.  So your concern is
unlikely to be actually true.  But even so, if you are saying that all
of these should be converted to prepared values, fine - but this would
be a large job and is likely to be error prone.  Would it not be
better to address any concerns you might have about quoteSQLString

Since quoteSQLString uses ' as it's quotation mark, and properly
escapes ' characters within the string, I claim that the method is
properly written and cannot be used for a sql attack.  If you
disagree, provide me a string that "breaks" the escaping that it does.
 The definition of such breakage is a string that, when escaped with
quoteSQLString, causes the query to interpret ANY of the string's
contents as something other than the string.

The link you provided lists many kinds of exploit, most of them
fundamentally issues with (a) non-escaping of strings, and (b) taking
advantage of flaws in (say) PHP or ASP.  ALL of them are thwarted by
proper escaping of character content.


On Mon, Dec 6, 2010 at 7:30 PM, Robert Muir <> wrote:
> On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright <> wrote:
>> As for the sql injection question, please elaborate.  There is no UI
>> ability to do sql injection that I am aware of, because all the
>> strings you might enter are properly escaped before being incorporated
>> into queries.  This includes queries that come via the API and
>> Authority Service.  So I guess I need an example of how you might
>> cause a sql injection given the current code.
> Escaping tends to only thwart casual attackers, not motivated ones or
> even automated tools.
> For example the escaping i see used here: e.g. quoteSQLString seems to
> only quote single-quote characters.
> There are a number of techniques to workaround this type of escaping,
> some are listed here:
> In my opinion all variables should be explicitly bound via PreparedStatements.

View raw message