Riesgos potenciales de una base de código única para múltiples CMS

4

Actualmente estamos en el proceso de convertir nuestras múltiples bases de código (que son exactamente iguales, excepto por un archivo de configuración y 2 hojas de estilo).

Hemos estado pensando en esto por un tiempo, y la idea por ahora es determinar el dominio al que el usuario está accediendo y cargando las hojas de estilo y el archivo de configuración en función del dominio.

Por ejemplo:
El usuario 'A' va al sitio web 'www.my.example.com' y la configuración (que incluye la base de datos, SMTP y otras opciones) y las hojas de estilo se utilizan. Determinamos todo en función de su dominio.

Entonces, si el usuario 'B' va al otro CMS 'my.exampler.com' cargará la configuración y las hojas de estilo para 'my.exampler.com' en lugar de 'my.example.com'.

¿Hay algún riesgo de seguridad al hacerlo de esta manera? Actualmente no sabemos de los posibles riesgos de seguridad que podrían ocurrir. El archivo de configuración no es accesible para los usuarios sin tener acceso directo o por FTP al servidor.

¿Es una mala idea? ¿Existe posiblemente una forma más segura de hacer esto? ¿O es esta una forma aceptable de crear una base de código única para cada CMS?

    
pregunta pandaJuan 02.01.2018 - 15:07
fuente

1 respuesta

1

En resumen, servir múltiples dominios desde una base de código única es mucho mejor que servir múltiples dominios desde múltiples bases de códigos. Menos código mucho mejor que más código.

Dicho esto, hay razones para NO hacer esto, especialmente si los diferentes dominios tienen diferentes perfiles de riesgo (como uno es un CMS y otro es el comercio electrónico).

Y al hacer esto, tiene que hacerse con cuidado. Un error común es confiar de forma implícita en el encabezado del Host entrante y reutilizarlo en plantillas, etc., lo que abre todos los sitios alojados de esta manera para poner en peligro.

    
respondido por el Jonah Benton 17.02.2018 - 17:16
fuente

Lea otras preguntas en las etiquetas