Quiero poner node.js en la nube para una aplicación que tenga información corporativa confidencial. Me temo que node.js no es tan seguro como algunos de los servidores más antiguos, ya que no ha estado en la naturaleza mucho. Vi a gente recomendando usar un proxy inverso para hacerlo más seguro. Entiendo que es más seguro ya que no está directamente expuesto al mundo. Pero aún así, xss y otros ataques son posibles. Desde una perspectiva de seguridad solamente, ¿alguien piensa que node.js está a la par de los servidores anteriores? ¿Algún consejo sobre "cómo convencer a tu jefe + al equipo de seguridad corporativo"?¿El proxy inverso hace que node.js sea seguro?
Respuesta
En teoría, un proxy inverso no pasaría ninguna solicitud que no pueda procesar por sí mismo (incluidos los que está diseñado para bloquear intencionalmente).
Sin embargo, si hubo errores en Node.js que, por ejemplo, hacer que divulga el contenido de ciertas variables cuando se recibe una petición como
GET /x0c/xa0
, entonces el proxy acaba de transmitir esa petición y transmitir la respuesta al cliente (atacante).
Así que todavía hay riesgos ...
¿Por qué no hacer de proxy de bloqueo duro en Python, C++, etc, que controlará el acceso? Todos los que pasan este proxy son usuarios de confianza y node.js trabaja con ellos.
No creo que esto sea realmente una respuesta al PO. – SuitedSloth
La manera de convencer al jefe y a los equipos de seguridad es demostrar que ha pensado en los problemas y tiene un plan razonable y realista para probarlos.
En cualquier entorno corporativo, su proxy solo será una pequeña parte de la seguridad general y así es como se gestionan los riesgos.
Para probar algo como esto, deberá enviar un número de * un * solicitudes razonables en el proxy. Me gusta la sugerencia de juand, por ejemplo, también debes enviar solicitudes muy grandes al proxy.
Un proxy Node.js debe ser al menos tan seguro como un Apache o incluso un proxy python/C++ personalizado, ya que solo debe permitir que proxy elementos muy específicos.
- 1. Proxy inverso
- 2. Ventajas de un proxy inverso frente a Node.JS
- 3. IIS como proxy inverso
- 4. lighttpd como proxy inverso
- 5. Usando el Fiddler como un proxy inverso
- 6. El proxy inverso Apache 2.2 no funciona
- 7. sesiones express.js con proxy inverso
- 8. ¿Qué hace que el encuadernado sea lento?
- 9. IIS proxy inverso con reescrituras no puede manejar una redirección desde el servidor proxy que a
- 10. ¿Qué problema hay en esta configuración para nginx como proxy inverso para node.js?
- 11. Cómo implementar Node.js en la nube para alta disponibilidad usando multi-core, proxy inverso y SSL
- 12. ¿Qué hace que el dominio cruzado ajax sea inseguro?
- 13. Nginx como proxy inverso durante el sondeo largo
- 14. WebDAV detrás de un proxy inverso
- 15. ¿Mejor proxy inverso para IIS 6?
- 16. Apache proxy inverso con autenticación básica
- 17. ¿Cómo configurar un Proxy inverso de Squid?
- 18. Proxy inverso con aplicaciones de google?
- 19. Problema con GWT detrás de un proxy inverso, ya sea nginx o apache
- 20. Añadir un servidor proxy inverso para heroku
- 21. ¿Qué hace que Ometa sea especial?
- 22. ¿Qué hace que STL sea rápido?
- 23. ¿Qué hace que Oracle sea más escalable?
- 24. Error seguro HTTPS de Node.js
- 25. Cómo hacer que mi código sea más seguro
- 26. Estrategias de invalidación de caché de proxy inverso de Nginx
- 27. ¿Qué hace que VxWorks sea tan determinista y rápido?
- 28. ¿Cómo hacer que este Twisted Python Proxy sea más rápido?
- 29. sp_executesql que hace que mi consulta sea muy lenta
- 30. ¿Qué hace que PostgreSQL sea más avanzado que MySQL?
Si es corporativo, solo debe ponerlo detrás del NAT (firewall). También node.js puede ser bastante seguro contra la mayoría de los ataques. – Alfred
@alfred: gracias, pero "bastante seguro contra la mayoría de los ataques" no convencerá al equipo de seguridad corporativo. Además, esta es una aplicación en la nube, no está detrás de la NAT corporativa. –
Su pregunta está muy lejos de la realidad. Los eventos "srevers más antiguos" son vulnerables a xss y otros ataques, mientras que estos son errores en SU CÓDIGO no, el servidor. Desde este punto de vista, los servidores más antiguos son tan inseguros como nodejs. Los proxys inversos solo pueden protegerlo de, por ejemplo, "http.createserver" cuando el servidor proxy detecta una solicitud http mal formada (error de protocolo) y descarta la solicitud, pero un error hipotético en nodejs habría expuesto información confidencial. –