Share
Moderna JavaScript-utvecklare älskar NPM. GitHub och registret för npm är utvecklarens förstahandsval för att hitta ett visst paket. Open-source-moduler bidrar till produktivitet och effektivitet genom att ge utvecklare en mängd funktioner som du kan återanvända i ditt projekt. Det är rättvist att säga att om det inte fanns för dessa öppen källkodspaket skulle de flesta av ramarna idag inte existera i sin nuvarande form.
En fullständig applikation på företagsnivå kan till exempel vara beroende av hundratals om inte tusentals paket. Vanliga beroenden inkluderar direkta beroenden, utvecklingsberoende, bundna beroenden, produktionsberoende och valfria beroenden. Det är bra för att alla ska få det bästa ut ur det öppna källkososystemet.
En av de faktorer som förbises är dock den mängd risk som är inblandad. Även om dessa tredjepartsmoduler är särskilt användbara på domänen, introducerar de också vissa säkerhetsrisker i din ansökan.
OSS-beroenden är faktiskt utsatta för utnyttjande och kompromisser. Låt oss ta en titt på några exempel:
En sårbarhet upptäcktes nyligen i ett paket som kallas eslint-scope vilket är beroende av flera populära JavaScript-paket som babel-eslint och webpack. Paketunderhållarens konto skadades, och hackarna lade till en del skadlig kod i den. Lyckligtvis såg någon att exploatera tillräckligt snart att skadan var uppenbarligen begränsad till några användare.
Moment.js, som är en av de mest använda biblioteken för att analysera och visa datum i JavaScript, har nyligen visat sig ha en sårbarhet med ett svårighetsgrad på 7,5. Utnyttjandet gjorde det sårbart för ReDoS-attacker. Plåster släpptes snabbt, och de kunde snabbt lösa problemet.
Men det är inte allt. En hel del nya utmaningar blir kända varje vecka. Några av dem blir avslöjade för allmänheten, men andra gör rubriker först efter ett allvarligt brott.
Så hur mildrar vi dessa risker? I den här artikeln ska jag förklara några av branschstandardens bästa praxis som du kan använda för att säkra dina oavbrutna beroenden.
Logiskt sett, när antalet beroenden ökar, kan risken att sluta med ett sårbart paket också öka. Detta gäller även för direkta och indirekta beroenden. Även om det inte finns någon anledning att du ska sluta använda open source-paket, är det alltid en bra idé att hålla reda på dem.
Dessa beroenden är lätt att upptäcka och kan vara lika enkla som att springa npm ls i rotkatalogen i din ansökan. Du kan använda -prod argument som visar alla produktionsberoende och -lång argument för en sammanfattning av varje paketbeskrivning.
Dessutom kan du använda en tjänst för att automatisera beredskapsprocessen som erbjuder realtidsövervakning och automatisk uppdateringstestning för dina beroenden. Några av de välkända verktygen är GreenKeeper, Libraries.io, etc. Dessa verktyg sammanställer en lista över de beroenden du använder för närvarande och spårar relevant information om dem.
Med tiden och förändringar i din kod är det troligt att du slutar använda vissa paket helt och i stället lägga till nya. Emellertid tenderar utvecklare att inte ta bort gamla paket när de går med.
Med tiden kan ditt projekt samla upp många oanvända beroenden. Även om detta inte är en direkt säkerhetsrisk, lägger dessa beroenden nästan säkert till ditt projekt angreppsytan och leder till onödig rodnad i koden. En angripare kan hitta ett kryphål genom att ladda ett gammalt men installerat paket som har en högre sårbarhetskvotent och därigenom öka den potentiella skada den kan orsaka.
Hur söker du efter sådana oanvända beroende? Du kan göra detta med hjälp av depcheckverktyget. Depcheck söker igenom hela koden för kräver och importera kommandon. Det korrelerar sedan dessa kommandon med antingen installerade paket eller de som nämns i din package.json och ger dig en rapport. Kommandot kan också ändras med olika kommandoflaggor, vilket gör det enklare att automatisera kontrollen av oanvända beroenden.
Installera depcheck med:
npm installera -g depcheck
Nästan alla punkter som diskuteras ovan är främst inriktade på de potentiella problem som du kan stöta på. Men vad gäller de beroenden du använder just nu?
Baserat på en nyligen genomförd studie innehåller nästan 15% av nuvarande paket en känd sårbarhet, antingen i komponenter eller beroenden. Den goda nyheten är dock att det finns många verktyg som du kan använda för att analysera din kod och hitta säkerhetsrisker för öppen källkod inom ditt projekt.
Det mest praktiska verktyget är NPM npm revision. Revision är ett skript som släpptes med npm version 6. Node Security Platform inledningsvis utvecklad npm revision, och npm registret senare förvärvat det. Om du är nyfiken på vad npm-revisionen handlar om, här är ett citat från den officiella bloggen:
En säkerhetsrevision är en bedömning av paketberoende för säkerhetsproblem. Säkerhetsrevisioner hjälper dig att skydda dina paketets användare genom att du kan hitta och åtgärda kända sårbarheter i beroenden. Npm-revisionskommandot lämnar en beskrivning av de beroenden som konfigurerats i ditt paket till ditt standardregister och ber om en rapport med kända sårbarheter.
Den genererade rapporten innehåller vanligtvis följande detaljer: det drabbade paketnamnet, svårighetsgraden av sårbarhet och beskrivning, sökväg och annan information och, om det är tillgängligt, kommandon för att tillämpa korrigeringsfiler för att lösa sårbarheter. Du kan även få revisionsrapporten i JSON genom att springa npm revision --json.
Utöver det erbjuder npm också hjälp om hur man agerar utifrån rapporten. Du kan använda npm revision fix för att åtgärda problem som redan har hittats. Dessa korrigeringar uppnås vanligen med hjälp av guidade uppgraderingar eller via open source-korrigeringar.
Mer information finns i npm: s dokumentation.
Begreppet öppen källkodssäkerhet är starkt beroende av antalet ögon som tittar över det specifika biblioteket. Paket som används aktivt används närmare. Därför finns det en större chans att utvecklaren kanske har tagit upp alla kända säkerhetsproblem i det specifika paketet.
Låt oss ta ett exempel. På GitHub finns det många JSON webb token implementeringar som du kan använda med ditt Node.js bibliotek. Men de som inte befinner sig i aktiv utveckling kan ha kritiska sårbarheter. En sådan sårbarhet, som rapporterades av Auth0, låter vem som helst skapa sina egna "signerade" tokens med vilken nyttolast de vill ha.
Om ett rimligt populärt eller välutnyttjat paket hade denna fel skulle oddsen för ett utvecklingsfinnande och patching felet vara högre. Men hur är det med ett inaktivt / övergiven projekt? Vi kommer att prata om det i nästa punkt.
Kanske är det snabbaste och mest effektiva sättet att bestämma aktiviteten för ett visst paket att kontrollera dess nedladdningshastighet på npm. Du hittar det här i stats avsnittet av npms paketsida. Det är också möjligt att extrahera dessa siffror automatiskt med hjälp av API för npm-statistiken eller genom att bläddra i historisk statistik på npm-stat.com. För paket med GitHub-repositories, bör du kolla in förlovningshistoriken, frågespåraren och eventuella relevanta begäran om begäran om biblioteket.
Det finns många buggar, inklusive ett stort antal säkerhetsbuggar som kontinuerligt upptras och i de flesta fall omedelbart patchas. Det är inte ovanligt att se nyligen rapporterade sårbarheter som endast är fastställda på den senaste filialen / versionen av ett visst projekt.
Till exempel, låt oss ta itu med ReDoS-sårbarheten som rapporterats på HMAC-paketet "hawk" i början av 2016. Denna bugg i hök löstes snabbt, men endast i den senaste stora versionen, 4.x. Äldre versioner som 3.x lappades mycket senare även om de hade lika stora risker.
Därför är dina beroende beror på att de inte har några säkerhetsbuller om de använder den senaste tillgängliga versionen.
Det enklaste sättet att bekräfta om du använder den senaste versionen är att använda npm föråldrad kommando. Detta kommando stöder -prod flagga för att ignorera några dev beroenden och --json för att göra automatisering enklare.
Kontrollera regelbundet de paket du använder för att verifiera deras ändringsdatum. Du kan göra det på två sätt: via npm-gränssnittet, eller genom att springa npm-visning .
Nyckeln till att säkra din ansökan är att ha en säkerhets-första kultur från början. I det här inlägget har vi täckt några av de vanliga metoderna för att förbättra säkerheten för dina JavaScript-komponenter.
Accentsconagua
npm revision att analysera dina beroenden.Om du har några tankar om JavaScript-säkerhet, kan du dela dem i kommentarerna.
