¿Es un riesgo de seguridad permitir que cualquiera vea la apariencia / html / javascript de las páginas de su administrador?

3

Bien, considere el escenario en el que tiene dos proyectos, uno es una API RESTful y el otro es un sitio web público.

La API utiliza autenticación basada en cookies / tokens y contiene toda la lógica de su aplicación.

El sitio web está creado con una tecnología MV * del lado del cliente, lo que puede y no puede hacer se basa en el rol del usuario autenticado por la API.

Alojar el HTML / JS / CSS del sitio web sin introducir un tercer marco MVC es más rápido (y más barato).

Por ejemplo, puede tener su API RESTful (tal vez construida con Django) y un servidor que sirve HTML / JS / CSS tal como está (digamos que es Apache), o una API RESTful y tener el sitio web en sí mismo utilizando una tecnología MVC del lado del servidor (como .net MVC) que restringe el acceso a HTML / CSS / JS según la función de usuario proporcionada por la API.

Esto ralentizará las cosas, pero ¿es más seguro? ¿Vale la pena la sobrecarga de no permitir que alguien que atraviesa el código del lado del cliente disponible públicamente no pueda ver cómo se ven sus páginas de administrador y qué puntos finales de API llaman y cómo los llaman, o es esta seguridad a través de la oscuridad? >

¿Seguramente un atacante determinado podría resolver esto de todos modos usando una herramienta como fiddler mientras navega por sus páginas públicas y luego analiza su API con otra herramienta?

Gracias

    
pregunta JMK 03.07.2014 - 01:32
fuente

2 respuestas

2

No me preocuparía por eso. Imagínelo de esta manera: si usa, por ejemplo, django.contrib.admin , todos saben cómo se ven las páginas de administración. ¿Es eso un riesgo de seguridad? No si las solicitudes se autentican y autorizan correctamente.

Es posible que desee tener cuidado de que las propias páginas no expongan la información que preferiría mantener en secreto o sería útil en ingeniería social, como "para restablecer la contraseña de un usuario, llame al servicio de asistencia interno al 212-555- 4240. "

    
respondido por el David 03.07.2014 - 02:01
fuente
1

lo que dijo David, más

  • asegúrese de que nadie pueda atravesar / navegar su carpeta con contenido estático, ya sea a través de un index.html vacío dentro de cada carpeta o

    # apache
    
    <Directory /path/to/stuff>
      Options -Indexes
    
    </Directory>
    
    # nginx
    server {
      ... 
      autoindex off;
      ...
    
    }
    

nota al margen / rant:

al servir contenido estático en un entorno distribuido, siempre preferiría nginx sobre apache por razones de rendimiento puro; Es camino (orden de magnitudes) más rápido mientras manteniendo una memoria / cpu muy baja cuando se está cargando. Si no lo crees, haz algunas pruebas con archivos simples y quedate impresionado :)

si opera un servidor / niveles múltiples - la configuración que realmente recomiendo es ingresar a estos nuevos servidores proxy inversos, podría ser nginx, barniz o proxy ha (todos difieren según el alcance de su operación)

    
respondido por el that guy from over there 03.07.2014 - 07:40
fuente

Lea otras preguntas en las etiquetas