Come può essere eliminata questa funzione di disinfettante degli input?

C'è una classica applicazione ASP nel mio lavoro che è (credo) altamente vulnerabile all'iniezione SQL. Voglio dimostrare alla gestione che questo codice non sia sicuro, ma tutto ciò che sono in grado di fare è inserire i record di log "SQLINJ" nel database:

Public function preventSQLInjection(lstr)

    BlackList = Array("--", ";", "'", "/*", "*/", "@@", "@",_
                      "alter ", "begin ", "create ", "cursor ",_
                      "declare ", "delete ", "drop ", " end", "exec ",_
                      "execute ", "fetch ", "insert ", "kill ", "open ",_
                      "select ", "sysobjects", "syscolumns",_
                      "table ", "update ", "=")

    preventSQLInjection = lstr

        For Each s in BlackList      
        If ( InStr (lstr, s) <> 0 ) Then
            execSqlQuery "INSERT INTO AccesLogs (datetime,ip,action,comments) VALUES ('" & formatDate(date) & " " & formatTime(time) & "','" & request.ServerVariables("REMOTE_ADDR") & "','SQLINJ','" & replace(lstr,"'","''") & "')",connectionstring
            preventSQLInjection = "DONOTUSEIT"
            exit for
        End If  
    Next

end function

Da quanto ho capito, l'attacco più semplice sarebbe stato sulla tabella AccessLogs , a causa di replace(lstr,"'","''") che "sanifica" il tentativo di SQL-Injection e lo registra.

SO che questo codice dovrebbe essere abbandonato e tutti gli SQL eseguibili dovrebbero essere eseguiti con comandi e parametri effettivi - Odio le stringhe concatenate con passione.

Voglio dimostrare alla direzione che la pagina è molto vulnerabile, come sysobjects è nella lista nera, ma non sys.objects quindi se posso iniettare SQL eseguibile deve essere possibile ottenere l'intero schema del database senza sudare.

Come può questa funzione essere sconfitta, diciamo, dai campi username e password sulla pagina login.asp ? O sto facendo tutto questo e questo codice è perfettamente sicuro?