First, it's not clear what you mean by sanitizing sql parameters.

If you're talking about making sure that they are correct type and/or length, then you will get an exception thrown if the parameters don't match with the correct Sql types of the stored procedure at the database side.

If you're talking about making sure the parameters can't fall victim to sql injection attacks, then you don't need to worry.  I don't know of any sql injection attacks where you can run arbitary Sql inside a Sql procedure by using parameterised queries, unless the developer has done something a bit silly inside the procedure itself (like accepting a sql statement as a parameter).

The best defense against Sql injection is using stored procedures and parameterized queries - you don't need to do anything at the application block level to improve this IMO.

There is a core InputFilter (NoSQL) that can be used to filter for common sql injection, but it's a blacklist filter so may not be perfect (it's essentially legacy code from dnn 1.x). I highly recommend you recode your dynamic sql from using concatenation to instead using a parameterised approach that utilises NULL values and Or checks - see http://weblogs.asp.net/sukumarraju/archive/2009/12/05/dynamic-search-using-stored-procedure.aspx for an example.

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US