ERRO DE CÓDIGO E SUGESTÃO DE CORREÇÃO

Por Ricardo Costa Val do Rosario e CoPilot 365

PERGUNTA

QUAL O ERRO QUE EXISTE NESSE CÓDIGO E COMO PODE SER O MESMO CORRIGIDO?

Python Copy

def login(username, password):
    connection = sqlite3.connect('users.db')
    cursor = connection.cursor()

    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"

    cursor.execute(query)
    user = cursor.fetchone()

    connection.close()

    return user is not None

RESPOSTA

• O código apresenta uma vulnerabilidade de SQL Injection.

• Isso ocorre porque os valores de *username e password *são inseridos diretamente na string da consulta SQL por meio de f-string, o que permite que um usuário mal-intencionado insira comandos SQL arbitrários e potencialmente acesse ou modifique informações sensíveis no banco de dados.

• Para corrigir esse problema e tornar a consulta segura, é recomendado o uso de consultas parametrizadas.

Por exemplo:

Python Copy

def login(username, password):
    connection = sqlite3.connect('users.db')
    cursor = connection.cursor()

    query = "SELECT * FROM users WHERE username = ? AND password = ?"
    cursor.execute(query, (username, password))
    user = cursor.fetchone()

    connection.close()
    return user is not None

• Essa abordagem garante que os valores dos parâmetros sejam escapados corretamente, evitando a execução indesejada de comandos SQL injetados.

• Além do SQL injection, há outras vulnerabilidades comuns relacionadas tanto à forma como as consultas SQL são formuladas quanto à configuração e ao gerenciamento do banco de dados. Aqui estão alguns exemplos:

1. Exposição de Informações Sensíveis:

• Mensagens de erro detalhadas ou excessivamente informativas podem revelar a estrutura do banco de dados, nomes de tabelas, colunas ou versões do software.

• Essa exposição facilita para que um atacante entenda o ambiente e monte ataques direcionados.

• Para evitar esse problema, é recomendado tratar os erros de forma genérica e registrar detalhes internamente, sem repassá-los à interface do usuário[^3^][^4^].

2. Uso Excessivo de Privilégios:

• Quando a aplicação utiliza uma conexão com o banco de dados com privilégios administrativos ou amplos demais, mesmo uma exploração potencialmente limitada pode levar a consequências graves, como modificação ou exfiltração completa dos dados.

• A adoção do princípio do menor privilégio — conceder apenas os acessos estritamente necessários para cada operação é essencial para mitigar esse risco.

3. Injeção de Dados Maliciosos de Segunda Ordem:

• Em situações em que dados de entrada são salvos no banco sem o tratamento adequado e, posteriormente, utilizados para compor novas consultas, pode ocorrer uma “injeção de segunda ordem”.

• Inicialmente, esses dados podem parecer inofensivos, mas quando reutilizados sem sanitização adicional, podem permitir a execução de comandos maliciosos.

4. Vulnerabilidades em Procedimentos Armazenados:

• Embora os procedimentos armazenados sejam uma forma de encapsular a lógica de acesso aos dados, eles podem ser vulneráveis se não validarem corretamente os parâmetros de entrada.

• Se esses procedimentos armazenados utilizarem concatenção de strings ou não implementarem verificações rigorosas, podem ser explorados de maneira semelhante às consultas dinâmicas vulneráveis a injeção.

5. Armazenamento Inseguro de Dados Sensíveis:

• Mesmo que a consulta em si não seja vulnerável a injeção, o armazenamento inadequado dos dados como senha sem texto claro ou usando algoritmos de hashing fracos pode comprometer toda a segurança do sistema caso um atacante consiga acesso ao banco de dados.

• É importante aplicar técnicas robustas de criptografia e hashing, por exemplo:

(bcrypt ou Argon2)

para proteger informações confidenciais

Considerações Finais

• Essas vulnerabilidades demonstram que a segurança em SQL vai além do risco direto de injeção.

• É fundamental implementar boas práticas na escrita de consultas, na gestão de privilégios e na configuração segura do ambiente de banco de dados.

• Devem serem tomadas ações capazes de não só prevenir ataques diretos, mas que também dificultem a exploração de informações internas por potenciais invasores.