Codificar/ofuscar los parámetros HTTP

Question

Actualmente estamos trabajando en una aplicación Webapp muy simple, y nos gustaría "ofuscar" (¿cuál sería el término correcto?) O codificar de alguna manera el parámetro de solicitud, para poder reducir la posibilidad un usuario inactivo de enviar datos arbitrariamente.

Por ejemplo, la URL se parece a /webapp?user=Oscar&count=3

Nos gustaría tener algo como: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT y tienen ese valor decodificado en el servidor con la petición de información real.

Antes de entrar en la implementación de algo como esto nosotros mismos (y probablemente hacerlo mal), me gustaría saber si hay algo que hacer esto ya?

Tenemos Java en el servidor y JavaScript en el cliente.

Answer 1

No, no hagas esto. Si puede construir algo en su código de cliente para ocultar los datos que se transmiten de vuelta al servidor, también lo puede hacer un hacker voluntario. Simplemente no puede confiar en los datos que se envían a su servidor, sin importar lo que haga su cliente oficial. Se adhieren a los datos del cliente que se escapan y lo validan contra una lista blanca en el lado del servidor. Use SSL, y si puede, coloque los parámetros de su solicitud en un POST en lugar de GET.

Expansión edición

Su confusión proviene del objetivo de bloquear a los usuarios de la manipulación de datos de la solicitud, con la necesidad de implementar medidas de seguridad estándar. Las medidas de seguridad estándar para aplicaciones web implican el uso de una combinación de autenticación, administración de privilegios y sesiones, pistas de auditoría, validación de datos y canales de comunicación seguros.

El uso de SSL no evita que el cliente altere los datos, pero evita que los intermediarios puedan verlos o alterarlos. También instruye a los navegadores de buen comportamiento para que no almacenen datos confidenciales en el historial de URL.

Parece que tiene algún tipo de aplicación web simple que no tiene autenticación, y pasa parámetros de solicitud que lo controlan directamente en el GET, y así algunas personas no conocedoras de la tecnología podrían darse cuenta de que user=WorkerBee simplemente puede cambiarse a user=Boss en su barra de navegación, y así pueden acceder a los datos que no deberían ver, o hacer cosas que no deberían hacer. Su deseo (o el de su cliente) de ofuscar esos parámetros es ingenuo, ya que solo frustrará a la persona menos experta en tecnología. Es una medida a medias y la razón por la que no ha encontrado una solución existente es que no es un buen enfoque. Es mejor que dedique tiempo a implementar un sistema de autenticación decente con una pista de auditoría por si acaso (y si esto es lo que hace, marque Gary's answer como correcto).

lo tanto, para envolverlo:

1. de Seguridad por la ofuscación no es seguridad en absoluto.
2. No puede confiar en datos de usuario, incluso si está oscurecido. Validate your data.
3. Usando canales de comunicación seguros (SSL) ayuda a bloquear otras amenazas relacionadas.
4. Usted debe abandonar su enfoque y hacer lo correcto.Lo correcto, en su caso, probablemente significa la adición de un mecanismo de autenticación con un sistema privilegio de evitar que los usuarios accedan a cosas que no son lo suficientemente el privilegio de ver - incluyendo cosas que podría tratar de obtener mediante la manipulación de GET parámetros. Gary R's answer, así como el comentario de Dave y Will al éste en la cabeza.

Answer 2

Puede codificar datos utilizando base64 o algo similar. Codificaría los argumentos en sí en JSON para serializarlos.

Answer 3

Si su objetivo es "reducir la posibilidad de que un usuario inactivo envíe datos arbitrariamente", hay otro enfoque más simple que probaría. Cree una clave de cifrado privada y guárdela en su servidor de aplicaciones. Siempre que su aplicación genere una url, cree un hash de la url usando su clave de encriptación privada y ponga ese hash en la cadena de consulta. Siempre que un usuario solicite una página con parámetros en la url, vuelva a calcular el hash y vea si coincide. Esto le dará cierta certeza de que su aplicación calculó la url. Sin embargo, dejará legibles los parámetros de la cadena de consulta. En el 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 4

¿Algo como jCryption?

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

Answer 5

Si el objetivo es prevenir URL "estáticos" de ser manipulado, a continuación, simplemente puede cifrar los parámetros, o firmen. Es probable que sea "lo suficientemente seguro" para agregar un MD5 de los parámetros de URL, junto con un poco de sal. La sal puede ser una cadena aleatoria almacenada en la sesión, por ejemplo.

a continuación, puedes:

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

Esta técnica expone los datos (es decir, pueden "ver" que xyz = 123), pero no pueden cambiar los datos.

Hay una ventaja de "encriptación" (y yo uso ese término sin apretar). Aquí es donde encriptas toda la sección de parámetros de la URL.

Aquí puede hacer algo como:

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

Lo bueno de usar el cifrado es doble.

Uno protege los datos (el usuario nunca puede ver que xyz = 123, por ejemplo).

La otra característica es que aunque es extensible:

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

Aquí, se puede decodificar la carga útil original, y hacer un (seguro) fusionarse con los nuevos datos.

Entonces, las solicitudes pueden AGREGAR datos a la solicitud, simplemente no cambian los datos EXISTENTES.

Puede hacer lo mismo a través de la técnica de firma, solo necesita consolidar toda la solicitud en un solo "blob", y ese blob está firmado implícitamente. Eso está "efectivamente" encriptado, solo una encriptación débil.

Obviamente no desea hacer NINGUNO de esto en el cliente. No tiene sentido.Si puede hacerlo, "ellos" pueden hacerlo y usted no puede notar la diferencia, por lo que es mejor que no lo haga en absoluto, a menos que desee "encriptar" datos en un puerto HTTP normal (frente a TLS, pero entonces la gente sabiamente se preguntaría "por qué molestarse").

Para Java, todo este trabajo va en un filtro, así es como lo hice. El back-end está aislado de esto.

Si lo desea, puede hacer que la parte de atrás esté completamente aislada de esto con un filtro de salida que maneja el cifrado/firma de URL a la salida.

Eso es lo que hice.

El inconveniente es que es muy complicado para hacerlo bien y realizarlo. Necesita un analizador de HTML ligero para extraer las URL (escribí un analizador de transmisión para hacerlo sobre la marcha, por lo que no copió toda la página en la memoria RAM).

El lado positivo es que todo el contenido "solo funciona", ya que no saben nada al respecto.

También hay un manejo especial cuando se trata de Javascript (ya que su filtro no "sabrá" fácilmente dónde hay una URL para encriptar). Lo resolví solicitando que las URL se firmaran para ser específicas "var signedURL = '....'", por lo que puedo encontrarlas fácilmente en la salida. No es una carga tan pesada para los diseñadores como se podría pensar.

El otro lado brillante del filtro es que puede deshabilitarlo. Si tiene algún "comportamiento extraño" que ocurre, simplemente apáguelo. Si el comportamiento continúa, has encontrado un error relacionado con el cifrado. También permite a los desarrolladores trabajar en texto plano y dejar el cifrado para las pruebas de integración.

Dolor por hacer, pero en general es agradable al final.

Answer 6

Si está intentando restringir el acceso a los datos, utilice algún tipo de mecanismo de inicio de sesión con una cookie que proporcione una clave de autenticación Single Sign On. Si el cliente envía la cookie con la clave, puede manipular los datos de acuerdo con las autoridades asociadas a su cuenta (administrador, usuario público, etc.). Solo mire Spring Security, CAS, etc. para realizar implementaciones fáciles de usar en Java. Los tokens provistos en la cookie normalmente se cifran con la clave privada del servidor emisor y, por lo general, son inviolables.

Alternativamente, si desea que su usuario público (no autenticado) pueda publicar algunos datos en su sitio, entonces todas las apuestas estarán desactivadas. Debe validar por el lado del servidor. Esto significa restringir el acceso a ciertos URI y asegurarse de que se limpian todas las entradas.

La regla de oro es no permitir todo, excepto las cosas que usted sabe que son seguras.