¿Es importante que el nivel intermedio de una aplicación web use un protocolo de comunicación diferente?

2

Al crear una aplicación web de n niveles / capas en la que cada nivel está físicamente separado de los demás, ¿es importante que una pila de comunicación diferente sea utilizada por los niveles de fondo (que no están expuestos a Internet)? que el nivel web que es?

Al ser consciente de la seguridad en la creación de una aplicación web, estoy creando un servidor de aplicaciones de nivel medio (backend-tier) que maneja todo el acceso a los datos de la aplicación web para que el servidor web nunca tenga acceso directo a la base de datos.

He pensado que necesito hacer que el servidor de aplicaciones use un protocolo de comunicación diferente al expuesto en el servidor web. Si mi nivel intermedio expone los servicios web HTTP / REST utilizando la misma pila de tecnología que el servidor web, ¿no se pondría en peligro tan fácilmente el nivel intermedio?

Como tal, he estado haciendo que el nivel intermedio se comunique mediante un protocolo TCP binario mientras el servidor web expone los servicios web HTTP / REST. El lado negativo de esto es toda la sobrecarga adicional. Necesito definir las interfaces dos veces (una para el servidor de aplicaciones y otra para el servidor web) y debo tratar con dos bibliotecas / protocolos de comunicación y sus peculiaridades.

¿Es esta la complejidad que exige el desarrollo de aplicaciones web seguras? ¿Tengo razón al necesitar usar diferentes protocolos / bibliotecas el servidor de aplicaciones y el servidor web?

Editado para agregar: Esto se refiere a la mitigación en caso de que el servidor web se vea comprometido. El servidor web puede hacer mucho menos que el nivel medio (más notablemente, no acceder a la base de datos). Un atacante que comprometa el servidor web sería malo; pero, lograr un acceso sin restricciones a la base de datos sería mucho peor.

    
pregunta vossad01 29.01.2015 - 16:57
fuente

3 respuestas

2

El uso de un protocolo diferente de pila / transporte no reduce significativamente el riesgo.

cliente - ([1] http) - > frontend - ([2] binario) - > backend - ([3] mssql / odbc /?) - > base de datos

Tres protocolos etiquetados [1], [2] y [3]. Si un atacante compromete el servidor frontend, no importa para qué protocolo se usa [2]. El atacante tendrá los mismos permisos que cualquier proceso que se ejecute en el front-end, independientemente del protocolo utilizado para [2].

Pondría menos energía en los protocolos de intercambio y más energía en el monitoreo del tráfico desde el frontend al backend. Es más probable que el tráfico muestre anomalías debido a que el frontend al tráfico de back-end suele estar claramente definido. El tráfico de cliente a frontend no es tan fácil de detectar anomalías porque cada navegador, cada escáner, cada pirata informático está tratando de interrumpir todo el tiempo. Pero si puede detectar que ya se ha producido un compromiso, podrá mitigar el daño.

Vuelve a tu pregunta de protocolo. Debido a que HTTP es un texto claro, es más fácil de monitorear. Puede detectar solicitudes inusuales y alertar su respuesta al incidente.

Sólo mis 2 centavos.

    
respondido por el Jonathan 29.01.2015 - 20:04
fuente
1

No, no es importante. Está sugiriendo la seguridad a través de la oscuridad, o elevando el nivel para el descubrimiento de defectos.

Lo importante es que modela correctamente todos los activos en el ámbito para las exposiciones y vulnerabilidades de seguridad.

Debería dar un paso atrás y reiniciar implementando un ciclo de vida de desarrollo de seguridad bien diseñado. Ese proceso incluirá capacitación, requisitos, diseño, implementación, verificación, lanzamiento y respuesta.

Hay una cantidad de buenos materiales de referencia para ayudarlo en el proceso. Pero algunos buenos lugares para comenzar:

  • "El ciclo de vida del desarrollo de la seguridad" (Michael Howard)
  • "Modelado de amenazas: diseño para la seguridad" (Adam Shostack)
  • "Creación de software seguro" (John Viega)
respondido por el W1T3H4T 29.01.2015 - 18:16
fuente
0

Si su evaluación / requisitos de diseño han determinado que es necesario un nivel intermedio, entonces su lógica es sólida.

Suponiendo que se debe usar el mismo conjunto de productos para los niveles medio y externo, luego que el protocolo de nivel medio use diferentes componentes de software / pila de tecnología para el protocolo de nivel externo, entonces, en teoría, una vulnerabilidad explotable en el servicio de nivel externo no conlleva un compromiso directo hacia adelante del nivel medio basado en la misma vulnerabilidad / vulnerabilidad.

Dependiendo de lo que esté intentando lograr, puede valer la pena echar un vistazo para ver si hay una opción de proxy de aplicación más robusta disponible para su uso en el nivel intermedio.

Obviamente, habrá otros riesgos en la solución, que necesitarán controles para evitar el acceso no autorizado, lo que resultará en el envío de un tráfico aparentemente autorizado desde el nivel externo al nivel medio.

    
respondido por el R15 29.01.2015 - 19:31
fuente

Lea otras preguntas en las etiquetas