asp.net - Prevent SQL Injection when the table name and where clause are variables -

i have situation need help. @ moment, i've build asp.net app using ado.net. i'm using commandtext build dynamic query have sql injection vulnerability. commandtext this

string.format("select count(*) {0} {1}", tablename, whereclause) 

tablename , whereclause passed in developer. see cannot use sqlparameters here because need pass entire tablename , whereclause not parameter values.

my solution prevent sql injection using blacklist check tablename , whereclause find out malicious string don't know best way in situation, isn't it. , if can me find blacklist references or library.

without knowing further details, there several options have in order avoid sql injections attacks or @ least minimize damage can done:

1. whitelisting more secure blacklisting: think whether need access tables except blacklisted ones. if adds tables @ later point in time, or might forget add them backlist.
2. maybe can restrict access specific subset of tables. ideally, these tables follow common naming scheme table name can validated against scheme. if there no naming scheme, add list of tables can accessed in program or application configuration can check whether table name contained in list. if save list in configuration file, able expand list without compiling application again.
3. if cannot whitelist table names, @ least check whether supplied table name present in database querying sys.tables system table (in sql server, other dbms might have similar tables). in query, can use parameters safe.
4. for sql server, should put table name in square brackets (select count(*) [" + tablename + "]"). square brackets used delimit identifiers (also see link). in order work, have check tablename variable not contain closing square bracket. if tablename variable might contain schema identifier (e.g. dbo.mytable you'd have split parts first , add square brackets ([dbo].[mytable]) these separate identifiers (one schema, 1 table name).
5. validate contents of variables using regular expressions or similar checks. easy table name, hard where clause you'd have parse sql clause , assert no dangerous code contained.
6. the hardest part check where clause. in respect best, if limit options user , whitelist possible where clauses. means user can choose range of where clauses program knows or builds based upon user input. these known where clauses contain parameters , therefore safe against sql injection attacks. if cannot whitelist where clauses, you'd have parse where clause in order able decide whether request dangerous or not. require large effort (if don't find library can you), i'd try whitelist many parts of dynamic query possible.
7. in order reduce damage of successful attack, should run query under specific account has limited rights. you'd have add connection string config-file uses account , create connection limited connection string. in sql server, move tables account able access specific schema , limit access schema account.
8. protect service against unauthorized access trusted developers can access it. can using components in infrastructure (firewalls, transport-level security etc.) , adding strong user authentication mechanism.
9. log each request service user , machine can identified. notify users logging mechanism know identified should go wrong.

some final thoughts: if seems easy provide developers such open method querying data, think whether necessary. 1 possible option not have open access, instead configure queries other developers need in configuration file. each query gets identifier , query text stored in file , therefore known beforehand. still, able add new queries or change existing ones after have deployed service. can allow parameters in query callers specify (maybe numbered parameter scheme p1, p2, ...).

as can see list above, hard (and in areas close impossible) lock service down , avoid kinds of sql injection attacks once allow open access. approach described in last paragraph loose flexibility, wouldn't have worry sql injection attacks anymore.