Lista de verificación de seguridad básica para usar una biblioteca de código abierto

El código abierto no es en sí mismo una garantía de calidad, ni la garantía de un código inofensivo. No tengo ningún ejemplo de una aplicación, marco o biblioteca de código abierto que haya contenido una puerta trasera voluntaria, pero debemos tener en cuenta que:

• las vulnerabilidades pueden ser difíciles de encontrar e impactar a toda la aplicación. Un buen ejemplo de esto es un error de implementación en OpenSSL que podría permitir que un atacante robe cualquier secreto, incluidas las claves privadas: ref. en wikipedia
• El código confidencial , o el código que rara vez es revisado por expertos en seguridad (las utilidades php, por ejemplo) podrían tener una puerta trasera por un tiempo bastante largo antes de que fuera descubierto y hecho público.

Las prácticas comunes son confiar solo en el software abierto bien conocido , ya que cuanto más se usan, más posibilidades hay de que se descubra un código dañino.

Para ser justos, también debe notar que el software comercial casi siempre viene con una limitación de responsabilidad . Eso significa que no está más protegido con software comercial que con software gratuito (de código abierto), y al menos este último le brinda la disponibilidad de auditar su código, o de pagarle a un experto para que lo haga por usted.

Pero no debe confiar en un software mal revisado, incluso si es de código abierto para una aplicación altamente sensible. Como de costumbre, debe considerarse la buena relación riesgo / costo.

Aquí hay una diferencia entre el lado del servidor y el lado del cliente. Desde que habla de barras de desplazamiento y editores de reducción, supongo que este es el lado del cliente. Me preocuparía menos los problemas del lado del cliente, ya que la mayoría de los navegadores modernos se ocupan rápidamente de los problemas de seguridad. Además, los navegadores intentan limitar los riesgos de seguridad y, en ocasiones, actúan en nombre del usuario (malware detectado, solicitudes xhr no válidas).

Lado del cliente

Las puertas traseras son poco comunes para estas bibliotecas o cualquier parte del software del lado del cliente. Aunque existen, HTML5 y la web moderna han impulsado a los navegadores a implementar algunos trucos para evitar actividades maliciosas, por ejemplo; mismo origen, contenido mixto, bloques emergentes y avisos iframe, la eliminación de flash, activex y applets, y así sucesivamente ...

Lado del servidor

Serverside es otra historia. Si utiliza bibliotecas de terceros (ya sean de código abierto o no), expone el entorno en el que se ejecuta la aplicación. Con frecuencia, las técnicas empleadas, como el bloqueo, las autorizaciones automáticas, los permisos por directorio de aplicación y por base de datos (operación) minimizan la posibilidad de corromper con éxito / acceder a datos y / u otros datos ambientales.

Para responder a la pregunta, es un problema legítimo que puede causar un error catastrófico. No es fácil / imposible verificar cada pieza de código que acaba de hacer. Hoy en día los marcos dependen en gran medida de complementos, extensiones y bibliotecas. Opensource no equivale a correcciones de seguridad rápidas, pero podemos suponer que cuanto más gente use algo, más rápido se informan y corrigen los errores. Coloque sistemas para limitar las posibilidades cuando sí salga mal. Tenga un plan de desastre, diseñe para fallar, use los registros (de auditoría), haga que los demonios rastreen los registros de acceso, etc. Cuando se trata de puerta trasera, la gente a menudo parece olvidar el firewall saliente.

Cuando uno empaqueta componentes del lado del cliente y los implementa en un navegador como parte de la aplicación en el contexto del dominio desde el cual se sirve la aplicación, el código se ejecuta dentro del límite de confianza que el navegador supone que existe con el dominio .

Esto significa que el código de terceros puede hacer cualquier cosa que el código de terceros pueda hacer. Tiene una visibilidad completa de DOM, puede llegar a servidores de terceros, puede mostrar anuncios y etiquetas de seguimiento al navegador, etc. Esta es una exposición significativa.

En términos de lo que se puede hacer para defender esta exposición:

1. La administración de versiones y dependencias y la comprobación de un servicio de vulnerabilidad como retire.js puede presentar cierta protección contra las vulnerabilidades conocidas. En este sentido, desaconseje copiar y pegar códigos de terceros en favor de dependencias explícitas. Quizás esta práctica ya esté en uso.

2. El uso de encabezados de Política de Seguridad de Contenido permite una lista blanca de la utilización y comunicación con terceros:

   enlace

3. Conducir la aplicación con Selenium, etc., en un entorno de prueba / arenero con un proxy presenta una oportunidad para descubrir a veces nuevas comunicaciones y utilización de terceros cuando se presenta.

   Dicho esto, los atacantes más sofisticados con código en la ruta de ejecución intentan detectar cuando se ejecutan en entornos de espacio aislado o en un modo de descubrimiento y no activarán la entrega de la carga útil.