¿Proteger una sola página en un sitio si se hackea el sitio?

3

Se me ha asignado la tarea de intentar encontrar una manera de asegurar una sola página en nuestro sitio si, de algún modo, un pirata informático obtiene acceso a nuestros archivos. Esta "página única" se ejecutará en un servidor diferente.

Requisitos:

  • Mostrar al usuario algo que le permita saber que definitivamente están viendo la página correcta

Eso es todo en realidad.

La idea es que durante un proceso en nuestro sitio, el usuario navegue a esta página, vea algo que le permita saber "usted está realmente en la página que desea". Ese "algo" podría ser incluso una url que apunta a un servidor específico que ejecuta SSL.

Sin embargo, realmente no puedo pensar en ningún sistema completo para manejar esto. Si de alguna manera un pirata informático tiene acceso a lo que sirve nuestro sitio web, siento que podría cambiar cualquier cosa, incluso al ir a https: url en una nueva ventana del navegador para esa página, ¿no podría ser falsificado? ( editar : esta es una pregunta importante. ¿Podrían, de alguna manera, falsificar la URL " enlace " si hackean la principal el sitio web " enlace "? ¿Le informaría el navegador al usuario que en realidad estaba yendo a la URL incorrecta?)

¿Es esta una tarea imposible?

editar
Una idea potencial sería algo como esto:
El cliente abre " enlace ". En un iframe, cargamos: " enlace ". En esa página segura, tenemos una clave enviada desde el servidor. Esa página luego usa Ajax para enviar esa clave ATRÁS al servidor, lo que verifica que la clave era correcta y muestra una imagen brillante. Esto permite al usuario ver visualmente que tienen una conexión segura. Luego, cuando el usuario envía el formulario (en secure.ourwebsite.com), ciframos la información y la enviamos a través de SSL a secure.ourwebsite.com. ¿Es esa una opción viable?

    
pregunta James P. Wright 08.03.2013 - 16:25
fuente

4 respuestas

4

El principio de SSL es que cuando el navegador del cliente muestra https://secure.example.com/whatever.html , la barra de URL en el navegador muestra la URL exacta y el usuario humano puede confiar en el hecho de que lo que ve es realmente lo que realmente posee el servidor. El nombre secure.example.com decidió enviar en ese momento. Esto no tiene ninguna relación con lo que ocurra con cualquier otro sitio, ya sea main.example.com .

Y eso es todo.

Esto significa que si usa un iframe, entonces no hay barra de URL, y por lo tanto no hay garantía. Desde el punto de vista del usuario, cuando se conecta a main.example.com , ve lo que el servidor desea que vea; Si el servidor está bajo el control completo del atacante, entonces el usuario ve lo que el atacante quiere que el usuario vea. En particular, el atacante no querrá que el usuario vea la versión de iframed de https://secure.example.com/ ; en su lugar, el atacante servirá una imagen que parece a la página segura, pero no es lo real. Ya que es un iframe, el usuario no puede ver la diferencia. La barra de URL es la base de la seguridad HTTPS . De lo contrario, solo se trata de imágenes, que se falsifican fácilmente.

Realmente no hay salvación para un sitio pirateado. Ninguna cantidad de SSL, Ajax o iframes solucionará eso.

    
respondido por el Tom Leek 10.03.2013 - 23:45
fuente
1

SSL solo protege la transmisión y la autenticidad del servidor / cliente conectado. No ayuda a proteger el contenido en el servidor en cuestión.

Para resolver su problema, debe crear un hash del contenido y firmarlo con su clave privada corporativa. El usuario ahora puede usar su clave pública para verificar que el contenido no haya sido manipulado.

Mientras mantenga su clave privada, bueno, privada, este enfoque es extremadamente seguro.

Puedes usar algo como GnuPG para implementarlo.

Actualización: Si alguien piratea su sitio "principal", puede colocar el contenido que desee, incluso falsificar el contenido de su iframe "seguro". No hay nada que pueda hacer al respecto, excepto asegurarse de que su sitio no esté comprometido en primer lugar. Lo siento. El enfoque de firma de contenido con gnupg aún funciona, pero requiere que el usuario lo compruebe por sí mismo con su clave pública.

    
respondido por el Martin Wickman 08.03.2013 - 16:29
fuente
0

No creo que tratar de ocultar una brecha sea el mejor enfoque, probablemente debería concentrarse primero en hacer una revisión de seguridad, tal vez contratar a un pentester profesional si su compañía está realmente preocupada por la seguridad en lugar de por su imagen pública.

Habiendo dicho eso, veo 3 problemas diferentes que debes resolver si aún deseas tomar esta ruta:

  1. Averigüe si la página principal ha sido hackeada.
  2. Cómo conmutar por error al servidor secundario.
  3. No está hackeando su servidor secundario.

Lo que haría por 2 es probablemente un enfoque de DNS. Cuando detecte que la página ha cambiado, modificará su nombre de dominio principal para que apunte a la dirección del servidor secundario. Necesitará algún proveedor de DNS que ofrezca una API para haz esto programáticamente.

Para el problema 3, necesita tener el servidor secundario en una red completamente diferente / proveedor de alojamiento, solo para estar seguro, y tener una sola página estática.

El problema 1 puede ser el más difícil, ya que hay muchas formas de modificar un sitio, o el atacante podría no modificarlo en absoluto.

    
respondido por el matugm 11.03.2013 - 03:06
fuente
0

Recuerdo que hace años, hubo un proveedor que proporcionó una solución de hardware al problema que usted describe.

Era un dispositivo de red en línea. Generaría una suma de comprobación para la página que quería proteger y el dispositivo validaría la suma de comprobación antes de permitir que se sirviera el contenido.

También puedes crear stop & van las palabras (la mayoría de los WAF de hoy lo harán)

No sé si la compañía todavía está presente o no ... Haré un poco de investigación. No recuerdo su nombre.

EDITAR: Revolví algunas tarjetas de visita antiguas y la empresa se llamó Vericept. Llegué al sitio web y parecen ser Trustwave y están en el espacio DLP. Es posible que aún tengan un dispositivo que haga lo que mencioné anteriormente.

    
respondido por el k1DBLITZ 11.03.2013 - 16:56
fuente

Lea otras preguntas en las etiquetas