Validar si la URL (mensaje) proviene de una fuente confiable

Question

Validar si la URL (mensaje) proviene de una fuente confiable

#1 de Tobi Nary (1 votos)
#2 de TommyWhite (0 votos)

1

Estamos trabajando en una página de redireccionamiento para nuestras aplicaciones móviles.

Los usuarios irían a una página como:

https://mobileredirect.our-app.com?target=https://clientdomain.com/some_resource

Las aplicaciones móviles en iOS y Adroid pueden interceptar el dominio "mobileredirect.our-app.com", cuando se instalan. Si no está instalado, el navegador se abrirá y redirigirá el navegador al dominio del cliente.

Esto contiene un problema obvio. Cualquiera puede poner cualquier dominio en el esquema y esto se convierte en un vector de ataque. Me gustaría poder verificar si la URL proviene realmente de una fuente confiable. Debemos hacerlo de esta manera, ya que no controlamos qué dominios podrían usar nuestra aplicación móvil.

Idealmente, me gustaría hacer esto en el navegador, sin la necesidad de un servidor.

Estaba pensando en usar una biblioteca como simple-crypt , usando la operación Asymmetric. Los servidores de confianza tendrían la clave privada, cifrarían la URL y terminaría así:

https://mobileredirect.our-app.com?target=ENCRYPTED_URL.

Los clientes (aplicaciones móviles y el sitio web) contendrían la clave pública para descifrar la URL. Esto significa que la clave pública será visible para todos.

Ahora mi pregunta: ¿Es esta una buena idea? ¿Cómo se puede romper esto? ¿Es una exageración? ¿Hay formas más fáciles (por ejemplo, usar algún tipo de algoritmo de suma de comprobación)?

Este es un reenvío desde desbordamiento de pila .

encryption url-redirection javascript

pregunta Bert Goethals 04.07.2017 - 10:04

fuente

2 respuestas

0

Parece que te has enfrentado con un simple Redireccionamiento abierto, no puedo señalarte la implementación en sí, pero parece que estás buscando Seguridad de contenido Política (CSP) , la implementación depende de la plataforma que esté utilizando. En pocas palabras, esta tecnología permite (o no) los recursos que utiliza su aplicación.

Desde la perspectiva del probador de penetración, es un dolor de cabeza cuando se enfrenta con CSP. Además, debe ver la recomendación básica para su caso aquí OWASP Redirecciones y vallas de tramitación no validadas

respondido por el TommyWhite 06.07.2017 - 11:59

fuente

Lea otras preguntas en las etiquetas encryption url-redirection javascript

¿Es posible realizar un ataque XSS en el título / subtítulo de una página web? Comprender las diferencias entre TCB basado en kernel y TCB de micro-kernel

score 1 · Accepted Answer

Es bueno que desee mantener privada la clave privada y solo entregarla a servidores de confianza, no a los clientes en sí.

Aunque usted propone un esquema que (probablemente) será seguro, tengo un enfoque ligeramente diferente para que usted considere que es menos un abuso de la criptografía asimétrica y permite una mejor transparencia en cuanto a lo que le está sucediendo al usuario recibiendo uno de esos enlaces:

Si agrega un elemento de ruta a la URL que contiene el hash firmado de la url para enviar al usuario, de esta forma:

http://a.tgt/?target=sign(privKey, h(https://b.tgt/bla))|https://b.tgt/bla

donde sign() firma un mensaje con una clave privada y h() hashs una cadena, tienes

una mejor oportunidad de detectar alteraciones,
autenticación sólida y
no oculte el objetivo directo real del usuario.

Al concatenar la firma y la URL de destino, como se señala en los comentarios, se reduce la posibilidad de que la carga útil se procese sin procesar la firma también.

Tenga en cuenta que el cifrado con la clave privada se suele denominar firma :)