Paquete NPM malicioso: ¿encaja en el Top Ten 2017 de OWASP?

5

En varios foros de seguridad he visto links a una publicación sobre un NPM malicioso ficticio información de la cosecha del paquete. El título de las publicaciones:

  

Estoy recolectando números de tarjetas de crédito y contraseñas de su sitio.   Aquí está cómo.

La mejor cita en la publicación en mi opinión:

  

Por suerte para mí, vivimos en una época en la que la gente instala paquetes npm como   están explotando analgésicos.

Esto llevó a una discusión en nuestra empresa sobre si un paquete NPM malicioso encajaría o no en OWASP Top Ten 2017 o no. Creo que podría encajar en las siguientes categorías:

  • A6: 2017-Mala configuración de seguridad
    La descripción dice: "No solo todos los sistemas operativos, marcos, bibliotecas y las aplicaciones deben configurarse de forma segura ...". Si tiene una biblioteca malintencionada que puede hacer algo porque su CSP no está configurado correctamente, por ejemplo, la incluiría en esta categoría.

  • A7: 2017-Cross-Site Scripting (XSS)
    Si la biblioteca habilita una vulnerabilidad XSS, caería dentro de esta categoría.

  • A9: 2017: uso de componentes con vulnerabilidades conocidas
    Si se sabe que la biblioteca es maliciosa, se incluiría en esta categoría.

  • A10: 2017-Insufficient Logging & Monitoring
    Si no se detecta el ataque, significa que no estamos registrando lo suficiente. Hay varias bibliotecas para el registro de JavaScript del lado del cliente y las solicitudes salientes se pueden consultar aquí. Por supuesto, la biblioteca maliciosa podría intentar deshabilitar esto, pero aún podría caer en esta categoría.

¿Esto es correcto o es un paquete NPM malicioso fuera del alcance de OWASP Top Ten 2017?

    
pregunta Ogglas 10.01.2018 - 09:37
fuente

1 respuesta

1

Me parece claro que una biblioteca con código malicioso está perfectamente cubierta por A9: 2017: uso de componentes con vulnerabilidades conocidas . Pensé que A9 fue creado para este caso de uso.

Aunque la redacción de OWASP habla de bibliotecas antiguas que tienen vulnerabilidades descubiertas a lo largo del tiempo (Heartbleed) y reemplazadas, no hay nada en la redacción que sugiera que esta debe ser la razón de la vulnerabilidad. La codificación malintencionada intencional funciona tan bien como una razón.

Puede surgir un debate sobre si la "codificación maliciosa" puede equipararse o no a una "vulnerabilidad", ya que el código malicioso podría funcionar como es debido sin efectos no deseados. Creo que este debate es un poco pedante y el espíritu del Top 10 de OWASP se apoya al equiparar las dos ideas.

Las bibliotecas codificadas malintencionadamente no son una "mala configuración". Una biblioteca mal configurada es una que no es vulnerable, per se, pero introduce vulnerabilidades debido al mal uso.

Las bibliotecas codificadas maliciosamente podrían introducir vulnerabilidades XSS, pero A7 es demasiado específico en este caso.

El registro y monitoreo insuficientes es un problema meta que afecta a todas las situaciones potenciales y es demasiado amplio para ser aplicable a este escenario de amenaza.

    
respondido por el schroeder 10.01.2018 - 10:41
fuente

Lea otras preguntas en las etiquetas