Escape or parameter for RowFilter to prevent expression injection security attack?

  • Thread starter Thread starter Koji Ishii
  • Start date Start date
K

Koji Ishii

One thing I've been frustrated with ADO.NET was the lack of Escape()
function or parameterized query for RowFilter. "Escape() function" I mean a
function like Regex.Escape(), which makes a string as a literal string in
the expression.

I can write:

ds.RowFilter = "col1 = '" + value.Replace("'", "''") + "'";

or

ds.RowFilter = "col1 LIKE '" + value.Replace("'", "''").Replace("%",
"%%").Replace("_", "__") + "%'"

but this tends to be forgoten. Now that I saw some samples from WinFS and
they use similar embeded expression as string without Escape function nor
parameterized query.

I'm wondering if this was already discussed, since I believe this is a
pretty common issue. MS strongly discourage building expression like this
for SQL server to prevent SQL code injection attack. Well, DataSet maybe
safe since it's not as capable as SQL server, but we have similar model not
only in DataSet but also in XPath, XQuery, WinFS, etc., and we developers
must keep remember what are the escape characters for which. Developers have
to pay attention that what security risk it involves if injection happen.
Injection against WinFS sounds like pretty risky.

Wouldn't it be nice if every class that implements internal
compiler/interpreter has at least Escape() and Unescape()? Parameterized
query is also fine with me, but that might not be as easy as Escape() and
Unescape() I guess.

Does anyone have any thoughts on this?


Thanks,
Koji Ishii
http://www.gluesoft.co.jp/en/
 
Injection attacks aren't launced on ADO.NET dataviews... While I couldn't
agree more that sending Dynamic SQL to the server is a bad approach, you can
do it on the client side to filter a dataview and not worry about it (there
are tons of other security issues to concern yourself with, but injection
into a Dataview sin't one of them )

Why? Because the dataview is totally disconnected from the Database, and
only the dataapadter, commandbuilder or your update logic can send data back
to the database. That's the layer you need to ensure is safe. If you use
Stored Procedures or Parameterzied SQL, then the command object will handle
the escapes for you.

Now, bad SQL in the rowfilter can cause exceptions in your code, bu tnot an
injection problem per se.

HTH,

Bill
 
Back
Top