Início / coding / Perguntas / 79128837
Accepted
Pavel Orekhov
Asked: 2024-10-26 23:18:07 +0800 CST

Por que a concatenação no log4j é propensa a ataques?

  • 772

Aqui: https://logging.apache.org/log4j/2.x/manual/getting-started.html#best-practice-concat

Eles dizem isso sobre o uso de concatenação de strings no log4j:

Mais importante, essa abordagem é propensa a ataques! Imagine userId sendo fornecido pelo usuário com o seguinte conteúdo: placeholders para argumentos não existentes para disparar falha: {} {} {dangerousLookup}

Alguém poderia explicar por que isso é perigoso? Não entendi o que a concatenação de strings tem a ver com essa coisa de "dangerousLookup".

java

3 respostas

  1. Best Answer

    Acho que a documentação é muito clara

    Imagine que o userId foi fornecido pelo usuário com o seguinte conteúdo: espaços reservados para argumentos inexistentes para acionar falhas: {} {}

    Caso você tenha o seguinte registrador e passe o acimauserId

    LOGGER.info("failed for user ID: " + userId);

    A execução do código será interrompida, pois o registrador terá como conteúdo "failed for user ID: placeholders for non-existing args to trigger failure: {} {} "e lançará uma exceção de que os 2 argumentos necessários não foram fornecidos.

    Também como o comentarista Violet mencionou, alguém poderia até mesmo passar um argumento com concatenação que é avaliado dinamicamente. Algo que não deve ser impresso nos logs, por exemplo, ${env:SECRET_ENV_VAR}que é o caso mencionado para pesquisa perigosa.

    Você também pode combinar os dois exemplos acima e ver como alguém pode usar uma exceção lançada por um registrador que fornece informações sobre a exceção ao usuário para obter informações que, de outra forma, deveriam estar ocultas.

    É por isso que eles aconselham como requisito que o layout da mensagem seja concreto e não controle o argumento. Por exemplo

    LOGGER.info("failed for user ID `{}`", userId);

    Agora, o registrador apenas imprimirá o argumento fornecido userIdconforme descrito no layout e não o misturará com o layout, para que você fique protegido dos problemas acima e de vários outros.

    • 6

  2. Se você usar concatenação de strings como no exemplo que você vinculou, e o valor da variável que você está concatenando pode vir de uma fonte externa que você pode não controlar, um invasor pode fazer com que esse valor tenha espaços reservados que o método de registro do log4j processará normalmente e que pode conter código malicioso que explora uma vulnerabilidade no log4j. Esse código malicioso seria então executado e o invasor obteria os benefícios de explorar essa vulnerabilidade. É isso que {dangerouslookup}significa, presumivelmente se referindo a vulnerabilidades passadas no log4j que usavam pesquisas JNDI como um vetor de ataque.

    • 1

  3. A documentação é confusa, obrigado por relatar o problema. Tanto a concatenação de strings quanto o registro parametrizado sozinhos não têm implicações de segurança. Um problema aparece, no entanto, quando você mistura os dois:

    logger.warn("Login failed for user '" + user + "' from remote address '{}'.", remoteIp);

    Se o invasor enviar {}como usuário, você receberá uma mensagem como:

    Login failed for user '192.0.2.1' from remote address '{}'.

    Esta é uma vulnerabilidade de injeção de log leve , mas pode causar problemas para analisadores de log automáticos ou confundir administradores. Se você usar log parametrizado, a string de formato deve ser uma constante de tempo de compilação .

    Esse problema não aparecerá se você usar apenas concatenação de strings ou registro parametrizado:

    // String concatenation
logger.warn("Login failed for user '" + user + "' from remote address '" + remoteIp + "'.");
// Parameterized logging
logger.warn("Login failed for user '{}' from remote address '{}'.", user, remoteIp);

    que retornarão:

    Login failed for user '{}' from remote address '192.0.2.1'.

    Observação : se os arquivos de log forem analisados ​​automaticamente e os parâmetros das mensagens de log tiverem um significado, é recomendável usar um layout de log estruturado junto com mensagens de mapa .

    • 1

relate perguntas