Estou testando a resiliência contra ataques de injeção em um banco de dados SQL Server.
Todos os nomes de tabela no banco de dados são minúsculos e o agrupamento diferencia maiúsculas de minúsculas, Latin1_General_CS_AS .
A string que posso enviar é forçada para maiúscula e pode ter no máximo 26 caracteres. Portanto, não posso enviar um DROP TABLE porque o nome da tabela estaria em letras maiúsculas e, portanto, a instrução falharia devido ao agrupamento.
Então - qual é o dano máximo que eu poderia fazer em 26 caracteres?
EDITAR
Eu sei tudo sobre consultas parametrizadas e assim por diante - vamos imaginar que a pessoa que desenvolveu o front-end que cria a consulta para enviar não usou parâmetros neste caso.
Também não estou tentando fazer nada nefasto, este é um sistema construído por outra pessoa da mesma organização.
Fácil:
Ou, eu acho que neste caso seria
Faça a sua escolha de variações sobre isso.
Com toda a probabilidade, você pode testar isso agora em relação ao seu sistema atual, mas qualquer número de pequenas alterações no banco de dados ao longo do tempo pode invalidar seu teste. A cadeia de caracteres pode mudar, alguém pode criar um procedimento armazenado em minúsculas que tenha potencial destrutivo - qualquer coisa. Você nunca pode dizer com 100% de confiança que não há um ataque destrutivo de 26 caracteres que alguém possa construir.
Sugiro que você encontre uma maneira de fazer com que o desenvolvedor siga as práticas recomendadas básicas de segurança padrão do setor, mesmo que apenas para seu próprio bem, como alguém que presumo ser pelo menos parcialmente responsável caso ocorram violações de segurança.
Editar:
E por malícia/diversão, você pode tentar habilitar todos os sinalizadores de rastreamento. Isso seria interessante de observar. Parece que um post de blog que Brent Ozar faria...
O
SHUTDOWN
comando ouKILL
Command (escolha um número aleatório acima de 50) levam significativamente menos de 26 caracteres, embora a conta que executa as consultas do aplicativo não tenha permissões suficientes para executá-las.Você pode criar uma tabela que você preenche até o fim do tempo ou o espaço em disco se esgote, o que ocorrer primeiro.
Dependendo da sua definição de dano, você pode executar isto: WAITFOR DELAY '23:59' Para ser realmente mau, você pode usar uma ferramenta de teste de carga para executar isso em 32.768 clientes.
Variação baseada na resposta de @MikaelEriksson e na resposta de @MartinSmith ao meu comentário inicial:
Inicialmente eu tentei fazer uma declaração WHILE, mas o melhor que consegui fazer foram 27 caracteres:
Mas Martin apontou GOTO:
GOTO... a raiz de todo mal e criador de uma declaração de inserção de loop infinito em 26 caracteres.
Com isso dito... pode ser vantajoso ficar com CHAR(99) em vez de int, pois isso usaria mais espaço. Outras opções usam nomes mais longos e esmagariam o limite de 26 caracteres... ou usariam menos espaço de armazenamento por linha.
Código de teste completo:
Dependendo de quão prejudicial você considera ser um desligamento. :-)
Isso requer que xp_cmdshell esteja habilitado no servidor, algo que não é o caso das últimas versões do SQL Server. Também requer que a conta de serviço tenha o direito de desligamento, que pode ou não ter.
A ativação do xp_cmdshell provavelmente ultrapassa o limite de 26 caracteres. Você permitiria múltiplas injeções?