Codificar / Ofuscación de HTTP parámetros

Question

Actualmente estamos trabajando en un muy simple Webapp, y nos gustaría a "obfuscate" (lo que sería el término correcto?) O codificar de alguna manera el parámetro de la petición, por lo que podemos reducir la probabilidad un usuario inactivo desde el envío de datos de forma arbitraria.

Por ejemplo, las miradas URL como /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 aplicación de algo como esto a nosotros mismos (y probablemente haciendo 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 me hagas esto. Si se puede construir algo en su código de cliente para ocultar los datos que se transmiten de vuelta al servidor, entonces también lo puede un hacker intencional. Simplemente no se puede datos de confianza de ser enviado a su servidor, no importa lo que su cliente oficial. Palillo a escapar de los datos del cliente y validarla contra una lista blanca en el lado del servidor . Usar SSL, y si se puede, poner los parámetros de la petición en un POST en lugar de GET.

Expansión editar

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. medidas de seguridad estándar para las aplicaciones web involucran el uso de una combinación de autenticación, el privilegio y la gestión de sesiones, pistas de auditoría, validación de datos, y los canales de comunicación seguros.

El uso de SSL no impide que el cliente desde la manipulación de los datos, pero sí evitar intermediarios de ver o alteración de la misma. También instruye a los navegadores de buen comportamiento que no hagan caché de datos sensibles en el historial de URL.

Parece que tiene algún tipo de aplicación web sencilla que no tiene ninguna autenticación y pasa alrededor de parámetros de la petición que controlan las cosas bien en el GET, de manera que algunas personas no con conocimientos técnicos probablemente podría darse cuenta de que user=WorkerBee simplemente puede ser cambiado a user=Boss en su barra del navegador, y por lo tanto pueden acceder a datos que no deberían ver, o hacer cosas que no deben hacer. Su deseo (o deseo de su cliente) para ocultar esos parámetros es ingenuo, ya que sólo va a frustrar la persona menos afines a la 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 una aproximación buena . Es mejor que pasar el tiempo la implementación de un sistema de autenticación decente con una pista de auditoría para una buena medida (y si esto es realmente lo que haces, marca respuesta de Gary como correcta).

Así que, para envolverlo:

1. Seguridad por la ofuscación no es la seguridad en absoluto.
2. No se puede confiar los datos del usuario, incluso si se oscurece. validar sus datos .
3. Uso de canales de comunicación seguros (SSL) ayuda a bloquear otras amenazas relacionadas.
4. debe abandonar su enfoque y hacer Lo correcto. Lo correcto, en su caso, probablemente significa la adición de una mecanismo de autenticación con una sistema de privilegios para impedir que los usuarios el acceso a las cosas que no son el privilegio de ver - incluyendo cosas que podrían tratar de acceso de la manipulación de parámetros GET. Gary respuesta de R, así como de Dave y comentaremos golpe éste en la cabeza.

Answer 2

Si su objetivo es "reducir la posibilidad de que un usuario inactivo desde el envío de datos de forma arbitraria," hay otro método más sencillo me gustaría probar. Hacer una clave de cifrado privada y almacenarla en su lado del servidor de aplicaciones. Cada vez que su aplicación genera una URL, crear un hash de la URL utilizando su clave privada de cifrado y poner ese resumen en la cadena de consulta. Cada vez que un usuario solicita una página con los parámetros de la URL, volver a calcular el hash y ver si coincide. Esto le dará una cierta certeza de que su aplicación calcula la url. Dejará sus parámetros de cadena de consulta, aunque legible. En 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

Si usted está tratando de restringir el acceso a los datos a continuación, utilizar algún tipo de mecanismo de inicio de sesión con una galleta que proporciona un inicio de sesión único clave de autenticación. Si el cliente envía la cookie con la clave a continuación, que pueden manipular los datos de acuerdo con las autoridades asociados a su cuenta (administrador, usuario público, etc.). Basta con mirar a la primavera de Seguridad, CAS, etc para una fácil de usar implementaciones de este en Java. Las fichas proporcionadas en la cookie están codificadas por lo general con la clave privada del servidor de emisión y son a prueba de manipulación indebida típicamente.

Por otra parte, si desea que su usuario público (no autenticado) para poder escribir algunos datos a su sitio, todas las apuestas están apagadas. Debe validar en el lado del servidor. Estos medios que restringen el acceso a ciertos URIs y asegurarse de que todas las entradas se limpia.

La regla de oro aquí es no permitir todo, menos materia que usted sabe es seguro.

Answer 4

Si el objetivo es prevenir URL "estáticos" de ser manipulado, entonces puede simplemente cifrar los parámetros, o firmen. Lo más probable es "suficientemente seguro" para virar en 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, puede simplemente:

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

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

Hay Es una ventaja de la "codificación" (y uso que término libremente). Aquí es donde puede cifrar 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 que protege los datos (que 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

A continuación, se puede descifrar la carga útil original y hacer una fusión (seguro) con los nuevos datos.

Por lo tanto, las solicitudes pueden agregar datos a la solicitud, simplemente no cambia los datos existentes.

Se puede hacer lo mismo a través de la técnica de la firma, sólo se necesita consolidar la totalidad del pedido en un único "blob", y que nota se realiza de forma implícita firmado. Eso es "efectiva" encriptados, sólo un cifrado débil.

Es evidente que usted no quiere hacer nada de esto en el cliente. No tiene sentido. Si puede hacerlo, "ellos" pueden hacerlo y no se puede decir la diferencia, por lo que puede ser que también no hacerlo en absoluto - a menos que desee cifrar los datos "" más de un puerto HTTP normal (vs TLS, pero entonces la gente va a sabiamente preguntarse "¿por qué preocuparse").

Para Java, todo este trabajo va en un filtro, que es la forma en que lo hice. El extremo posterior está aislado de esta.

Si lo desea, puede hacer que el extremo trasero completamente aislado de esto con un filtro de salida que el cifrado se encarga de la dirección URL / firmar en la salida.

Eso también es lo que hice.

El lado negativo es que está muy involucrado para hacerlo bien y performante. Es necesario un analizador HTML peso ligero para extraer las direcciones URL (escribí un analizador de streaming de hacerlo sobre la marcha por lo que no copió la página entera en la memoria RAM).

El lado positivo es toda la parte de contenido "simplemente funciona", ya que no sabe nada al respecto.

También hay algo de manejo especial cuando se trata de Javascript (como su filtro no será fácil "saber" donde hay una URL para cifrar). Resolví esto requiriendo URLs para ser firmado para ser específicos "var = signedURL '....'", por lo que puedo encontrar los que son fácilmente en la salida. No como una carga para la trituración diseñadores como se podría pensar.

La otra cara brillante del filtro es que se puede desactivar. Si usted tiene un poco de "comportamiento extraño" sucediendo, simplemente apagarlo. Si el comportamiento continúa, usted ha encontrado un error relacionado con el cifrado. También permitirá a los desarrolladores trabajan en texto plano y dejan el cifrado para las pruebas de integración.

El dolor que hacer, pero es agradable en general al final.

Answer 5

Algo así como jCryption?

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

Answer 6

Puede codificar datos utilizando 64 o algo similar. Me codificar los argumentos inself en JSON serializar ellos.