Codificar/ofuscar parâmetros http

Question

Atualmente estamos trabalhando em um webApp muito simples e gostaríamos de "ofuscar" (Qual seria o termo certo?) Ou codifique de alguma forma o parâmetro de solicitação, para que possamos reduzir a chance de um usuário ocioso enviar dados arbitrariamente.

Por exemplo, o URL se parece /webapp?user=Oscar&count=3

Gostaríamos de ter algo como: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT e tenha esse valor decodificado no servidor com as informações reais da solicitação.

Antes de implementar algo assim (e provavelmente fazendo errado), gostaria de saber se já há algo para fazer isso?

Temos Java no servidor e JavaScript no cliente.

Answer 1

Não, não faça isso. Se você puder criar algo no código do seu cliente para ofuscar os dados que estão sendo transmitidos de volta ao servidor, assim como um hacker intencional. Você simplesmente não pode confiar nos dados sendo enviados ao seu servidor, independentemente do que seu cliente oficial faz. Fique em escapar dos dados do cliente e validá -los contra uma lista de permissões no lado do servidor. Use SSL e, se puder, coloque seus parâmetros de solicitação em uma postagem em vez de obter.

Edição de expansão

Sua confusão decorre da meta de impedir que os usuários adulterem os dados de solicitação, com a necessidade de implementar medidas de segurança padrão. As medidas de segurança padrão para aplicativos da Web envolvem o uso de uma combinação de autenticação, privilégio e gerenciamento de sessões, trilhas de auditoria, validação de dados e canais de comunicação seguros.

O uso do SSL não impede que o cliente adultere os dados, mas impede que os intermediários vejam ou adulterem. Ele também instrui os navegadores bem-comportados a não cache dados confidenciais no histórico da URL.

Parece que você tem algum tipo de aplicativo da web simples que não tem autenticação e passa parâmetros de solicitação que o controlam corretamente e, portanto, algumas pessoas não teconicamente experientes provavelmente poderiam descobrir que user=WorkerBee pode simplesmente ser alterado para user=Boss Em sua barra de navegador e, portanto, eles podem acessar os dados que não devem ver ou fazer coisas que não devem fazer. Seu desejo (ou o desejo do seu cliente) de ofuscar esses parâmetros é ingênuo, pois isso só vai frustrar a pessoa menos teconicamente experiente. É uma medida meio assada e a razão pela qual você não encontrou uma solução existente é que não é uma boa abordagem. É melhor você gastar tempo implementando um sistema de autenticação decente com uma trilha de auditoria para uma boa medida (e se é isso que você faz, Mark Resposta de Gary como correto).

Então, para encerrar:

1. A segurança pela ofuscação não é de segurança.
2. Você não pode confiar nos dados do usuário, mesmo que sejam obscurecidos.Validar seus dados.
3. O uso de canais de comunicação segura (SSL) ajuda a bloquear outras ameaças relacionadas.
4. Você deve abandonar sua abordagem e fazer a coisa certa. A coisa certa, no seu caso, provavelmente significa adicionar um mecanismo de autenticação com um sistema de privilégio para impedir que os usuários acessem coisas que não são privilegiadas o suficiente para ver - incluindo coisas que eles podem tentar acessar pela adulteração com os parâmetros GET. Resposta de Gary R, assim como o comentário de Dave e Will, atingiu este na cabeça.

Answer 2

Se o seu objetivo é "reduzir a chance de um usuário ocioso de enviar dados arbitrariamente", há outra abordagem mais simples que eu tentaria. Faça uma chave de criptografia privada e guarde -a no lado do servidor de aplicativos. Sempre que seu aplicativo gera um URL, crie um hash do URL usando sua chave de criptografia privada e coloque esse hash na sequência de consultas. Sempre que um usuário solicita uma página com parâmetros na URL, recompute o hash e verifique se ele corresponde. Isso lhe dará alguma certeza de que seu aplicativo calculou o URL. Ele deixará seus parâmetros de sequência de consulta legíveis. Em pseudo-código,

SALT = "so9dnfi3i21nwpsodjf";

function computeUrl(url) {
  return url + "&hash=" + md5(url + SALT );
}

function checkUrl(url) {
  hash = /&hash=(.+)/.match(url);
  oldUrl = url.strip(/&hash=.+/);
  return md5(oldUrl + SALT ) == hash;
}

Answer 3

Se você está tentando restringir o acesso aos dados, use algum tipo de mecanismo de login com um cookie que fornece um único sinal na chave de autenticação. Se o cliente enviar o cookie com a chave, poderá manipular os dados de acordo com as autoridades associadas à sua conta (administrador, usuário público etc.). Basta olhar para Spring Security, CAS etc para facilitar o uso de implementações disso em Java. Os tokens fornecidos no cookie geralmente são criptografados com a chave privada do servidor emissor e geralmente são provas de adulteração.

Como alternativa, se você deseja que seu usuário público (não autenticado) seja capaz de postar alguns dados no seu site, todas as apostas estão desativadas. Você deve validar no lado do servidor. Isso significa restringir o acesso a certos URIs e garantir que toda a entrada seja limpa.

A regra de ouro aqui é desaprovar tudo, exceto que coisas que você sabe que são seguras.

Answer 4

Se o objetivo é impedir que os URLs "estáticos" sejam manipulados, você pode simplesmente criptografar os parâmetros ou assiná -los. É provável que seja "seguro o suficiente" em um MD5 dos parâmetros da URL, junto com um pouco de sal. O sal pode ser uma corda aleatória armazenada na sessão, digamos.

Então você pode apenas:

http://example.com/service?x=123&y=Bob&sig=ABCD1324

Essa técnica expõe os dados (ou seja, eles podem "ver" que xyz = 123), mas não podem alterar os dados.

Há uma vantagem de "criptografia" (e eu uso esse termo frouxamente). É aqui que você criptografa toda a seção de parâmetros do URL.

Aqui você pode fazer algo como:

http://example.com/service?data=ABC1235ABC

O bom de usar a criptografia é duas vezes.

Um protege os dados (eles nunca podem ver que xyz = 123, por exemplo).

O outro recurso é que é extensível:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc

Aqui, você pode decodificar a carga útil original e fazer uma mesclagem (segura) com os novos dados.

Portanto, as solicitações podem adicionar dados à solicitação, mas não alteram os dados existentes.

Você pode fazer o mesmo através da técnica de assinatura, você precisaria apenas consolidar a solicitação inteira em um único "blob", e esse blob é implicitamente assinado. Isso é "efetivamente" criptografado, apenas uma criptografia fraca.

Obviamente, você não quer fazer nada disso no cliente. Não há sentido. Se você pode fazer isso, "eles" podem fazê -lo e você não pode dizer a diferença, para que você possa não fazê -lo - a menos que queira "criptografar" dados em uma porta HTTP normal (vs tls, Mas então as pessoas se perguntam sabiamente "por que se preocupar").

Para o Java, todo esse trabalho vai em um filtro, foi assim que eu fiz. O back -end é isolado disso.

Se desejar, você pode fazer o back -end completamente isolado com um filtro de saída que lida com a criptografia/assinatura da URL na saída.

Isso também foi o que eu fiz.

O lado negativo é que está muito envolvido para acertar e performance. Você precisa de um analisador HTML leve para retirar os URLs (escrevi um analisador de streaming para fazê -lo em tempo real, para que ele não copie a página inteira para RAM).

O lado positivo é todo o lado do conteúdo "apenas funciona", pois eles não sabem nada sobre isso.

Há também algum manuseio especial ao lidar com JavaScript (como seu filtro não "sabe facilmente" onde há um URL para criptografar). Eu resolvi isso exigindo que os URLs sejam assinados como específicos "var signedUrl = '....'", para que eu possa encontrá -los facilmente na saída. Não tanto esmagando um fardo para os designers quanto você imagina.

O outro lado positivo do filtro é que você pode desativá -lo. Se você tem algum "comportamento estranho" acontecendo, basta desligá -lo. Se o comportamento continuar, você encontrou um bug relacionado à criptografia. Também permite que os desenvolvedores trabalhem em texto simples e deixem a criptografia para testes de integração.

Dor a fazer, mas é bom no final.

Answer 5

Algo como jcription?

http://www.jcryption.org/examples/

Answer 6

Você pode codificar dados usando base64 ou algo semelhante. Eu codificaria os argumentos inseguros em JSON para serializar -os.