>> i.e. 'UPDATE ' + fTableName + ' SET .........
>>

...

> EXECUTE STATEMENT command ...

...

> * You open up a large security vulnerability. If I know you have a
> stored procedure that executes an update of an arbitrary field in an
> arbitrary table, you need to consider a malicious person passing in
> tablenames and fieldnames that they are not meant to (including
> system tables).

I do not see any vulnerability here. EXECUTE STATEMENT does not
bypass checking of sql privileges, in fact it is more restricted than
executing UPDATE directly inside SP. See this example

CREATE TABLE TAB ( I INTEGER );

CREATE PROCEDURE TEST1 AS
BEGIN
UPDATE TAB SET I=I+1;
END;

CREATE PROCEDURE TEST2 AS
BEGIN
EXECUTE STATEMENT 'UPDATE TAB SET I=I+1';
END;

GRANT EXECUTE ON PROCEDURE TEST1 TO IVAN;
GRANT EXECUTE ON PROCEDURE TEST2 TO IVAN;
GRANT ALL ON TAB TO PROCEDURE TEST1, PROCEDURE TEST2;

Although user IVAN does not have any privileges to table TAB,
he can execute procedure TEST1, because that SP has all permissions
to table TAB.
But IVAN can't execute TEST2 because access to TAB has to be granted
directly to him, the fact that TEST2 has granted access to TAB is not important
in case of EXECUTE STATEMENT.

In other words, you can't abuse EXECUTE STATEMENT to perform
statements that you could not execute directly otherwise.

Ivan