Właściwy sposób na naprawienie potencjalnej luki w zabezpieczeniach w zależności zdefiniowanej w pliku package-lock.json

88

Github podał mi ten błąd w jednym z moich repozytoriów.

We found a potential security vulnerability in one of your dependencies.
A dependency defined in ./package-lock.json has known security vulnerabilities 
and should be updated.

Zależność nie jest zdefiniowana w naszym package.jsonpliku. W moim rozumieniu usuwanie package-lock.jsonpliku i jego ponowne generowanie nie jest dobrą praktyką . Nie widzę jednak innego sposobu rozwiązania tego problemu. Jeśli odrzucę tę lukę w zabezpieczeniach, pojawi się ona ponownie kilka dni później. Jakieś pomysły? Dzięki!

Kaito
źródło

Odpowiedzi:

67

Nowość: teraz z npm @ 6 możesz bezpośrednio biec

npm audit fix

Stara odpowiedź:

Powinieneś spróbować zidentyfikować nazwę pakietu powodującego problem, a następnie uruchomić

npm install package-name

oczywiście zastępując nazwę pakietu.

Spowoduje to zainstalowanie najnowszej wersji pakietu i bardzo często najnowsza wersja rozwiązuje problem bezpieczeństwa. Jeśli masz ograniczenie dotyczące wersji (np .: 1.2), zawsze możesz spróbować:

npm install package-name@^1.2

i zostanie zainstalowana najnowsza poprawiona wersja

DevTheJo
źródło
1
... i aby 'zidentyfikować nazwę pakietu powodującego problem', którą możesz uruchomić npm ls vulnerability-name. Zawiera listę elementów zależnych od luki, które można następnie zaktualizować / zainstalować. (jak wspomniano dość niejasno w odpowiedzi @ RileyManda)
Sjeiti
1
npm Audyt fix czysto rozwiązuje ten problem teraz.
Kaito
9
Doda package-namew dependenciesz package.json. Nie chcę tego.
pokaz
7

Aby rozwiązać ten problem:

Rozwiązanie 1: Najpierw znajdź lukę: użyj terminalu: cd do swojego projektu , a następnie uruchom "npm ls hoek"

I na koniec: npm install bcrypt @ latest

Następnie wypchnij zaktualizowany projekt do git (tj. Wykonaj nowe zatwierdzenie).

Rozwiązanie 2:

jeśli pierwsza opcja / rozwiązanie nie rozwiązuje problemu, zmień wersję ręcznie w pliku package-lock.json. Zmień ręcznie wersję z 2.16.3 na 4.2.1

"hoek": {
      "version":  "4.2.1",
      "resolved": "https://registry.npmjs.org/hoek/-/hoek-4.2.1.tgz",
      "integrity": "sha1-ILt0A9POo5jpHcRxCo/xuCdKJe0=",
      "dev": true

Następnie zaktualizuj swój projekt na GitHub (zatwierdzenie / wypychanie) Po prostu upewnij się, że każde wystąpienie wersji hoek w Twojej wersji package-lock.json zostało zmienione na 4.2.1

Alternatywnie, jeśli możesz znaleźć sposób na zmianę wersji hoek / aktualizację hoek za pomocą npm, znacznie uprości to. ( Npm update @ hoek..version ) .. lub odinstaluj określoną zależność, a następnie zainstaluj ją ponownie za pomocą bower lub npm.

RileyManda
źródło
4

Miałem ten sam problem z luką w zabezpieczeniach typu lodash w projekcie, który budowałem z przędzy. Github oznaczył je jako zagrożenie bezpieczeństwa.

Spróbowałem odpowiedzi z @rileymanda powyżej, używając terminala: cd do projektu, a następnie uruchom npm ls lodash.

To ujawniło, że w moim przypadku błąd był w skryptach reagowania . Szybka wyszukiwarka Google w przypadku problemów ze skryptami reagowania i zgłaszania problemów ujawniła, że ​​jest to znany problem.

Próbowałem różnych rzeczy naprawić za pomocą przędzy - wszystko bez powodzenia. npm ls lodashnadal pokazywał podatną wersję lodash w użyciu.

Po przeczytaniu bloga Matta Turnbulla o ulepszeniach npm przełączyłem się z powrotem z przędzy na npm. (Usuń yarn.lock, usuń ./node_modules. Uruchom npm install). npm ls lodashteraz pokazał najnowsze używane wersje zależności - hurra! Zaangażował się w github i był teraz szczęśliwy, że luka zniknęła.

Wygląda na to, że przędza ma problemy z rozwiązywaniem takich problemów (lub nie jest to zamierzone).

Jeśli napotykasz ten problem podczas budowania z włóczki, spróbuj przełączyć [z powrotem] na npm!

JohnSk
źródło
3

W moim rozumieniu usuwanie pliku package-lock.json i jego ponowne generowanie nie jest dobrą praktyką.

Jednak tak się zwykle dzieje w tym przypadku.
Patrz na przykład kwestia kątowa / kątowa-CLI 8534 , którą rozwiązuje PR 8535 .
Że prowadzi zależny projekt podobny frees-io/freestyle-opscenter-webclientdo aktualizacji swojego package-lock.json: PR 31 .

VonC
źródło
Regeneracja-pakietu lock.json wydaje nie rozwiązuje probelm
xianshenglu
@xianshenglu OK, zostawię odpowiedź na wypadek, gdyby to pomogło innym.
VonC
Otrzymuję ostrzeżenie o blokadzie pakietu w starym zatwierdzeniu. Jak mam coś naprawić w historii bez przepisywania tego?
pishpish
@destoryer That I don't know: spróbuj zadać nowe pytanie z większą ilością szczegółów (system operacyjny, wersja npm, ...)
VonC
1
To rozwiązało mój problem. Dzięki za wskazówkę.
Rich
1

znane luki w zabezpieczeniach i należy je zaktualizować.

Od 23 maja 2019 roku masz teraz „ Dependabot: automatyczne poprawki zabezpieczeń

Dzięki integracji Dependabot udostępniliśmy automatyczne poprawki bezpieczeństwa jako publiczną wersję beta.

Zautomatyzowane poprawki zabezpieczeń to żądania ściągnięcia generowane przez GitHub w celu naprawienia luk w zabezpieczeniach.
Automatyzują żmudną część przepływu pracy i ułatwiają programistom aktualizowanie ich zależności.

Więcej informacji można znaleźć w sekcji „ Konfigurowanie automatycznych poprawek zabezpieczeń

Uwaga: automatyczne poprawki zabezpieczeń są dostępne w wersji beta i mogą ulec zmianie.

Można włączyć automatyczne poprawki zabezpieczeń dla dowolnego repozytorium, które korzysta z alertów zabezpieczeń i wykresu zależności.
Automatycznie włączymy automatyczne poprawki zabezpieczeń w każdym repozytorium korzystającym z alertów zabezpieczeń i wykresu zależności w ciągu najbliższych kilku miesięcy, począwszy od maja 2019 r.

VonC
źródło
Miałem mieszane wyniki z tym botem. Wolę robić ręcznie npm auditi / lub npm audit fix.
Fuhrmanator
@Fuhrmanator OK. Wspomniałeś medium.com/coinmonks/ ... w poprzednim komentarzu?
VonC
0

To działa dla mnie. odinstaluj wszystkie zależności i zainstaluj je ponownie

Na przykład

z package.json zobacz listę swoich zależności

{
"name": "ebook-saler",
  "version": "1.0.0",
  "description": "App for selling ebooks",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "author": "Md Shayon",
  "license": "ISC",
  "dependencies": {
    "body-parser": "^1.19.0",
    "express": "^4.17.1",
    "express-handlebars": "^3.1.0",
    "hoek": "^6.1.3",
    "stripe": "^7.5.0"
  }
}

Postępuj zgodnie z poleceniem

npm uninstall body-parser express express-handlebars hoek stripe
npm install body-parser express express-handlebars hoek stripe
git commit -m "updated"
git push
MD SHAYON
źródło
0
  1. W GitHub przejdź do strony głównej repozytorium.
  2. Pod nazwą repozytorium kliknij opcję Bezpieczeństwo.
  3. Kliknij alert, który chcesz wyświetlić.
  4. Przejrzyj szczegóły luki i, jeśli jest dostępne, żądanie ściągnięcia zawierające automatyczną poprawkę zabezpieczeń.
  5. Opcjonalnie, jeśli nie ma jeszcze automatycznej poprawki zabezpieczeń dla alertu, aby utworzyć żądanie ściągnięcia w celu usunięcia luki, kliknij opcję Utwórz automatyczną poprawkę zabezpieczeń.
  6. Gdy będziesz gotowy, aby zaktualizować swoją zależność i rozwiązać lukę, scal żądanie ściągnięcia.

Patrz szczegóły

MD SHAYON
źródło
0

spróbuj npm audit fix, to rozwiąże wiele ostrzeżeń

następnie npm i [package.name]@xxx

na przykład:

"dependencies": {
  "lodash": ">=4.17.13"
}

npm i [email protected]

Jun Du
źródło