¿Cómo reparar las vulnerabilidades de npm manualmente?

96

Cuando corro npm installdice found 33 vulnerabilities (2 low, 31 moderate) run `npm audit fix` to fix them, or `npm audit` for details.

Sin embargo, npm audit fixsalidasup to date in 11s fixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updated

¿ reviewSignifica eso que no se supone que lo arregle el usuario?

Cuando lo ejecuto npm audit, me da una lista de tablas, similar a esta:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.17.5                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ browser-sync [dev]                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ browser-sync > easy-extender > lodash                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/577                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

En este ejemplo, la sección de corrección de la página vinculada dice Update to version 4.17.5 or later.. Sin embargo, /node_modules/browser-sync/package.jsonhay líneas:

"devDependencies": {
    "lodash-cli": "4.17.5",
}

y no más dependencias lodash. Entonces ya debería ser v4.17.5. También verifiqué /node_modules/lodash/lodash.jsoncuál tiene var VERSION = '4.17.10';línea. En /node_modules/lodash/package.jsonexisten estas líneas:

  "_from": "lodash@^4.17.4",
  "_id": "[email protected]",

Creo que la versión se muestra en "_id", no en "_from", por lo que las versiones son correctas, pero la vulnerabilidad sigue apareciendo en la lista de auditoría.

Todavía soy nuevo en node.js y esos mensajes me confunden mucho. ¿Hay alguna forma de solucionarlo manualmente o deshacerme de esos mensajes con los que no puedo hacer nada?

node.js npm npm-audit Jakupov
fuente
¿Responde esto a tu pregunta? ¿Cómo soluciono un paquete npm vulnerable en mi package-lock.json que no aparece en package.json?
JBallin

Respuestas:

33

lodash-cliin devDependenciesno afecta el browser-syncfuncionamiento de su proyecto, devDependenciesse ignoran cuando se instala un paquete como dependencia.

Lo auditque dice el informe es que es lo easy-extenderque tiene lodashdependencia:

browser-sync > easy-extender > lodash

Que depende de Lodash 3 , mientras que el problema se resolvió en Lodash 4. El problema podría ser fijada por bifurcan easy-extender, actualizándolo e instalarlo en lugar del paquete de registro público NGP. Pero no hay ningún problema real con esta dependencia.

auditLa importancia del informe debe evaluarse manualmente. Incluso si la dependencia anidada tiene un riesgo de seguridad, esto no significa que se haya utilizado una función que introduce este riesgo. Esto tampoco significa que incluso si se usa, presenta un riesgo real debido a cómo se usa.

browser-synces una herramienta de desarrollo que no se utiliza en producción, no existen tantos escenarios donde se puedan explotar sus vulnerabilidades. Y Prototype Pollution no es una vulnerabilidad en absoluto, solo un aviso de que un paquete no sigue las buenas prácticas, se puede ignorar.

Generalmente, esta es la forma de corregir las vulnerabilidades reportadas:

  • Haz una prueba de cordura
  • En caso de que se trate de un problema real, consulte el repositorio del paquete vulnerable en busca de problemas y relaciones públicas existentes
  • En caso de que no haya ninguno, envíe un problema
  • Bifurque un repositorio o use PR existente como dependencia de git hasta que se solucione en la versión de NPM
  • En caso de dependencias anidadas, haga esto en varios niveles de anidación

La mayoría de las veces se espera que no avance más allá de un control de cordura.

patch-packagepuede ayudar a parchear dependencias anidadas en el lugar, pero esto no afectará el auditinforme.

Matraz Estus
fuente
No presté atención a la sección Path, y realmente usa lodash v3.10.1, gracias. Pero la sincronización del navegador es solo un ejemplo, el último de la lista. Entonces, puedo ignorar 2 vulnerabilidades bajas, pero ¿puedo ignorar 31 moderadas? Supongo que no debería modificar nada node_modules, entonces, ¿bifurcar y arreglar es la única forma de deshacerse de ellos? ¿Y como nuevo usuario no tengo capacidad para hacer eso? ¿Debería informar a los desarrolladores de paquetes sobre ellos?
Jakupov
4
pero ¿puedo ignorar 31 moderados? - de esto se trata el "control de cordura", use su criterio. Cuanta más atención preste a lo que realmente dicen estos informes, mejor desarrollador podrá convertirse en seguridad. ¿Debería informar a los desarrolladores de paquetes sobre ellos? - probablemente deberías (al menos para callarte audit), la respuesta responde eso. La gente vivía sin él de npm auditalguna manera. Las posibilidades de que causen problemas de seguridad reales a la aplicación son muy bajas, pero sin saber qué son y cómo se utilizan en su aplicación, no puedo garantizarlo.
Estus Flask
¡Gracias! Tomó tiempo para escribir un comentario, por lo que no vi la parte editada antes de comentar.
Jakupov
5

Si está absolutamente seguro de que desea omitir la auditoría, puede hacerlo agregando --no-audit

 npm install --no-audit
Tjad Clark
fuente
2

'npm audit fix' incrementará la versión de dependencia en package.json, lo que podría provocar la ruptura del código. Entonces, una mejor manera es abrir package-lock.json y actualizar las versiones de dependencia / subdependencia a la versión requerida. Mantenga el package-lock.json en el repositorio.

A veces, las vulnerabilidades provienen de paquetes de desarrollo. En ese caso, ignore esas vulnerabilidades, ya que no se detectan en la producción.

nik
fuente
-3

La mayor parte del problema que ocurrió en mi sistema se debió al paquete npm. Lo intenté,

npm un npm

No es necesario que vuelva a instalarlo.

Simplemente ejecute el programa nuevamente. Funcionó para mí.

Gaurav Rana
fuente