Cair em "situações" atribuídas à SQL Injection é muito comum quando, principalmente, os desenvolvedores não entendem ou desconhecem o que é SQL Injection. 

Felizmente, tudo o que é necessário para proteger contra esse "ataque" é um pouco de conhecimento básico em SQL em geral (não apenas T-SQL). Pensando em fazer tudo o que for necessário para proteger sua aplicação contra SQL Injection é estar seguro que os dados e os comandos que os obtém são sempre, consistentemente, separados.

Se o fluxo de comandos tem permissão para manipular dados a qualquer momento, então você está suscetível ao SQL Injection. Isto não importa se sua aplicação utiliza o SQL Server ou qualquer outro RDBMS.

Existem vários artigos que vão orientá-lo em como "acabar" com SQL Injection, mas tenha em mente que em muitos destes "manuais" estão os erros mais comuns em como se proteger. Um bom exemplo disto são orientações como "Utilize procedimentos armazenados (stored procedures) para armazenar suas consultas", uma vez que você cria parâmetros/variáveis para realizar as consultas personalizadas do seu sistema e se não forem tratadas e protegidas adequadamente poderão ser uma brecha para o SQL Injection.

O mais importante é saber que, se o seu servidor SQL possui restrições de acesso para manipulação de dados e objetos, principalmente pelo usuário disponibilizado pelo sistema e, os desenvolvedores validam as informações inseridas/atualizadas de forma adequada, os riscos de sua aplicação sofrer com "ataques" de SQL Injection serão realmente reduzidos.

Outros serviços, como um bom Firewall também dificultam a "investigação" de quem tem interesse em encontrar brechas para obter suas informações.