¿Cómo convencer a un compañero de equipo sobre el uso de una lista blanca?

Finalmente, encontré un PoC para un ataque XSS. El componente es vulnerable cuando se llama como a continuación:

http://my-server.com/component?origin=javascript:alert%28%27Hello%20world!%27%29

Prueba que un script malicioso puede ejecutarse una vez que el usuario hace clic en el enlace generado por el componente.

Finalmente, nuestro compañero de equipo ha aceptado fortalecer el componente.

En lugar de una lista blanca, eligió verificar que el valor de origin es una URL válida.

Mientras esté confiando en la información del usuario entrante, nunca estará completamente protegido / seguro. Cualquier cosa puede ser falsificada, alterada, modificada; y, posteriormente, su componente ahora está comprometido.

Si desea seguir la ruta de retener algo , tendría sentido hacer una lista blanca. Sin embargo, ir un paso más allá puede ser más ideal: usted emite tokens en lugar de especificar dominios (piense en cómo Google Analytics utiliza un número UA-XXX en mysite.com). Poner a la administración nuevamente en su administrador web y la posibilidad de dominios defectuosos / vulnerabilidades de seguridad es ahora su responsabilidad.

Para más detalles sobre lo que me refiero, en lugar de tener una lista blanca, configure una base de datos de tokens:

tokens
id       # Primary Key
token    # Unique generated token

Luego, tenga una relación 1: * donde se puedan definir orígenes válidos para esa clave:

origins
id       # Primary key
token_id # Forieign Key, tokens.id
origin   # origin (e.g. google.com)

Luego cree un token para un cliente específico (quien quiera que incluya su componente en su página). Por ejemplo, digamos que tenemos el token abc123def456 :

<iframe src="http://server.com/component?key=abc123def456"></iframe>

Aquí,sucomponenterealizaríaunabúsquedadelladodelservidorensutablatokensyvalidaría.TambiénpuedeagregarchequesadicionalescontraelencabezadoReferer,peroesodependedeusted(ydándosecuentadequeelRefererpodríaserfalsificado).Bahviorpredeterminadoseríadeny*,porloquemostraríaunapáginaquedice"No se han especificado orígenes, configure" (o algo por el estilo).

A continuación, inician sesión en la página de administración y agregan "abc.com". Ahora, el widget se convierte en:

<iframe src="http://server.com/component?key=abc123def456&origin=abc.com"></iframe>

Ahora, en el lado del servidor, está validando la clave junto con el origen (en contra de su lista blanca compilada en la tabla origins (asociada a esa clave). Si un pirata informático intentara usar esta (o modificarla) no es válido El origen (con respecto a la clave) rebotaría y mostraría una página de error.

Si deciden no especificar el origen, también puede configurar un origen predeterminado, de modo que cada vez que incluya solo /component?key=abc123def456 asuma el origen predeterminado.

O algo por el estilo

Cuando escucho sobre las listas blancas, me remonta a la historia de los firewalls.

Cuando se usaron los cortafuegos por primera vez, operaron en "aceptar todo de forma predeterminada, excepto lo que está en la lista negra". Esto creó MUCHOS problemas para los primeros firewalls y administradores de sistemas, ya que tenían que estar al tanto de las amenazas y agregarlas a la lista negra de forma proactiva.

Cuando la industria se dio cuenta del problema y cambió al sistema actual de "bloquear todo por defecto, excepto lo que se incluye en la lista blanca", esto redujo drásticamente el panorama de amenazas y la presión sobre los equipos de administración de sistemas.

Usa esta analogía cuando te enfrentes con esto otra vez. Esto debería convencer a la mayoría de la gente.