Sådan nærmer du sikkerhed med Node.js

Vi har tilføjet en ny kategori til Node.js Foundation Enterprise Conversation-serien kaldet Node.js Foundation Enterprise Tech Conversations. Denne nye filial indeholder samtaler med eksperter, der arbejder på Node.js-funktioner, der betyder noget for virksomhedsbrugere, såsom sikkerhed.

Til vores første tech-samtale satte vi os sammen med Mike Samuel, der arbejder i Googles IFC-hærdeteam, som er en del af Googles sikkerhedsteknologi-team. Dette team fokuserer på rammer, biblioteker og programmeringssprog for at forsøge at forbedre dem og gøre det lettere at producere sikker og robust software.

Samtalen dækkede:

  • Hvilke slags spørgsmål skal projektledere stille deres arkitekter og udviklere til sikkerhed? (01:53)
  • Hvordan bedst styres afhængigheder fra en sikkerhedslinse med Node.js? (03:12)
  • Hvilken slags sikkerhedsproblemer skal udviklere forvente, at rammer skal løse? (00:06)
  • Hvilke nye trusler har udviklingshold måske brug for at begynde at planlægge? (29:01)
  • Hvilke nye funktioner kan hjælpe udviklingshold med at administrere sikkerhed? (33:20)
Et par hurtige takeaways:
- Dit team skal opdatere deres afhængigheder, når sikkerhedsproblemer findes opstrøms.
- Brug altid andenfaktorautentisering med npm.

Sikkerhed er altid et rettidigt emne med enhver teknologi, da den altid udvikler sig. Hvis du vil gå dybere ind i emnet Node.js økosystemsikkerhed, kan du se denne introduktion til Node.js Security Working Group og Node.js Security Roadmap.

Hele transkriptionen af ​​samtalen er nedenfor, og du kan også lytte til den på YouTube her.

Yderligere referencer, Mike nævnte under denne samtale, inkluderer:

  • Hans snak om Node.js Security hos JSConf EU 2018
  • Script Gadgets
  • Følg Mike på Medium her.

Ønsker du at foreslå et emne til vores enterprise tech-samtaler? Send en e-mail til [email protected]

Udskrift

Tierney Cyren: 00:00 Hej alle sammen, og tak for at du kom til en anden Node.js Enterprise Tech samtale med Mike Samuel på Google. Mike, vil du introducere dig selv?

Mike Samuel: 00:15 Ja. Jeg arbejder på Googles IFC-hærdeteam. Hærdning er en del af sikkerhedsteknik. Vi tager rammer, biblioteker og programmeringssprog og prøver at forbedre dem for at gøre det lettere at producere sikker og robust software. Det er et forholdsvis lille team af sikkerhedsspecialister, alle os softwareingeniører. Vi støtter en meget større gruppe applikationsudviklere.

Tierney Cyren: 00:44 Fantastisk. Jeg er Tierney Cyren. Jeg er udvikler hos NodeSource og formand for Node.js samfundskomité. Lad os komme ind på dit team, og hvad det hold gør lidt mere. Hvad er omfanget af sikkerhed, og hvordan spiller den slags spil ind i det, du laver dag til dag?

Mike Samuel: 01:08 Vi er ansvarlige for at adressere slags på rammeniveau fælles klasser af sårbarheder. Vi vil fjerne byrden fra applikationsudviklingen. For eksempel, hvis enhver applikationsudvikler skal undersøge al deres kode for at sikre sig, at de ikke har et XSS, er det ikke en effektiv brug af deres tid. Mens vi kan forbedre en ramme, så de bliver nødt til at lave usædvanlige slags fejl for at være sårbare over for XSS, så har vi forbedret udviklernes produktivitet meget, og det forbedrer sikkerheden for slutbrugerne

Tierney Cyren: 01:44 Fantastisk. Jeg tror, ​​at den slags spiller lidt pænt ind i det næste emne, som som en udvikler, der er nødt til at gøre det, skal gå og gøre det arbejde, hvad er de slags spørgsmål, som nogen, der ikke er udvikler som en projektleder skulle spørge deres arkitekter og devs om sikkerhed?

Mike Samuel: 02:12 Et team, der har en historie om, hvordan man adresserer hver slags fælles sikkerhedssårbarhed, der vil være et meget bedre sted end et hold, der ikke gør det. For eksempel et team, der kan sige, du ved, "Vi er sikre fra XSS, fordi vi bruger kontekstuelt auto-undslippe skabelonsprog. Hvad det betyder, er, at når vi producerer html, forstår vores skabelonsprog html og sørger for, at ting undgås. Vi Brug disse værktøjer konsekvent, så vi vil være sikre mod denne XSS, "og måske har vi en anden historie om, hvorfor vi er sikre mod SQL-injektion og andet, ja. At have disse historier, slags og tænke igennem, hvordan vi undgår hver af disse problemer på en systematisk og konsistent måde, sætter dig i et meget bedre sted.

Tierney Cyren: 03:11 Awesome.

Mike Samuel: 03:12 Andre former for problemer, et team, der lægger mærke til deres afhængighed og opdaterer deres afhængighed, når sikkerhedsproblemer findes opstrøms, vil være et meget bedre sted.

Tierney Cyren: 03:26 Ja.

Mike Samuel: 03:27 Der er skrevet meget om det store antal afhængigheder, som mange Node-projekter har. Det er ikke et problem i sig selv. Det er bare det, at når en fejl i en af ​​disse bliver kendte, kan angribere hurtigt komme til at udnytte den. Det er godt at have en historie om, hvordan du holder dig ajour.

Tierney Cyren: 03:52 Du nævnte, at du havde en sti eller et svar for de almindelige sikkerhedssårbarheder, eller som om de almindelige angrebsveje. Hvad med usædvanlige? Jeg er nysgerrig efter, om det er sådan noget, som premierministeren skal stilles, hvis der er et spørgsmål, som premierministerne skal spørge deres teammedlemmer om det?

Mike Samuel: 04:12 Nå, så ja. Selvfølgelig. Afhængigt af arten af ​​den service, du leverer, kan der være sikkerhedssårbarheder, der er specifikke for det. At starte sikkerhedsanmeldelser ofte tidligt og konsultere med sikkerhedspecialister for at forstå, kan relatere dine projektspecifikationer til angreb, der er sket i fortiden, er bestemt nyttigt.

Tierney Cyren: 04:47 Fantastisk.

Mike Samuel: 04:50 Derefter er det vigtigt også at engagere sig med sikkerhedspecialister, der holder øje med nye trusler.

Tierney Cyren: 04:59 Mm-hmm (bekræftende). Du nævnte også at håndtere afhængigheder. Dette er noget, jeg har lært meget om for nylig med hensyn til, som ... En sårbarhed er normalt ikke bare på øverste niveau, især i et afhængighedstræ, der er specifikt for node. Det bliver tre eller fire moduler dybt; Du ved, en afhængighed af en afhængighed af afhængighed. Hvordan foreslår du, at folk styrer det eller handler med det? Ved du, hvilken slags værktøjslink foreslår du måske?

Mike Samuel: 05:27 Ja, dette er faktisk en af ​​de ting, som jeg har arbejdet med TC39, JavaScript-udvalget. Jeg har lagt en kode, som - og mit mål er at gøre det muligt at give forskellige moduler forskellige tillidsniveauer. For eksempel er shell-adgang, ved du, hvis du har adgang til børneprocessen, kan du ... Hvis en angriber kan få en streng til børneproces, kan de gøre alle slags dårlige ting.

Tierney Cyren: 06:01 Ja, ja.

Mike Samuel: 06:03 Meget få af dine afhængigheder vil faktisk udtrykkeligt bruge børneprocessen. Meget få af dem har brug for at bruge børneprocesser til at udføre deres job. Du kan fokusere din opmærksomhed på at forstå de afhængigheder, der har brug for det, hvis du kan sikre dig, at kun et lille antal moduler kan få adgang til det på én gang. Dette er et eksempel på, slags, inden for Google bruger vi meget statisk analyse. Statisk analyse lader os måske vide, at en C ++ binær, for eksempel, hvor den ringer til, du ved, på en skal. Knude, fordi det er JavaScript, får statisk analyse dig kun så langt. Du skal udføre dynamisk håndhævelse. Jeg har arbejdet meget med at finde frem til mekanismer, der lader os sige, ”Hej, jeg ved, baseret på, slags, at køre mine test, som disse moduler har brug for at påkalde børneprocessen. på at sikre, at de gør det godt. Så vil jeg sørge for, at du i produktionen, andre, moduler forsøger at påkalde børneprocessen. " Den slags begrænser nedsiden.

Tierney Cyren: 07:25 Okay.

Mike Samuel: 07:26 At kunne sige, at der er disse forskellige myndighedskilder, der kan misbruges. At være i stand til at differentiere de mange, de få af dine mange afhængigheder, der har brug for en af ​​dem, så lad os begrænse ulempen og fokusere din opmærksomhed ... Og se fokuserede anmeldelser.

Tierney Cyren: 07:50 Det bringer faktisk en ... Det er superinteressant for mig eller en superinteressant ting. En af angrebsvektorerne med et nodemodul er package.json. Jeg er nysgerrig, for det er ikke rigtig det første parti JavaScript. Det er mere tredjepart. Jeg er nysgerrig efter, hvordan det kunne eller kan, eller teoretisk set ville integreres i denne slags historie, hvis der overhovedet er integration på dette niveau.

Mike Samuel: 08:21 Ja. Jeg tror, ​​nogen, jeg glemmer forskernes navn, viste, at det i princippet var muligt at komme med en orm, der løb på postinstallationstidspunktet og brugte det faktum, at nogen muligvis var logget på npm for at foretage redigeringer af pakken.json og propagere sig selv. Du ved, du hører noget efter installation og postinstallation påberåber sig dybest set bindestreg, at bindestreg kunne have lappet pakken.json i din projektrute og derefter forpligtet npm. Brug bestemt altid andenfaktorautentisering med npm.

Tierney Cyren: 09:08 Ja.

Mike Samuel: 09:11 Ja, det taler jeg lidt om i ... Åh, jeg skal nævne, at jeg har udgivet dette, jeg og nogle kolleger fra Google har udgivet dette dokument kaldet "Node.js Security Roadmpa. Fyi. " En sikkerhedsvejskort forklarer, hvor vi er sikkerhedsmæssige og hvordan vi kommer til et bedre sted. Dette misbrug af scripts efter installation er dokumenteret der. Ideelt set ender du op i en sandkasse. Der er npm-flag, der giver dig mulighed for at springe efter installation af manuskripter. Du ønsker at adskille privilegiet til at ændre ting under nodemoduler, som er slags slutmålet for de fleste postinstallations-scripts, fra privilegiet til at ændre udviklerkode, ændre den lokale get-klient. Adskill det også fra privilegiet at forpligte sig til det globale npm-arkiv.

Mike Samuel: 10:21 Jeg dokumenterede det der, man skulle gøre det, der involverer at holde et lokalt øjebliksbillede af npm og off-load kørsel af postinstallations-scripts. Det er ikke trivielt påvirkeligt i nogle få bash-linjer, så jeg tror, ​​det er noget, der kunne leveres som en service og funnling alt det til et pænt, let implementeret sæt værktøjer. Du ved, det korte svar er tofaktorautentisering på kort sigt og forsøger at bruge disse værktøjer, når de bliver tilgængelige på lang sigt. En af de dejlige ting ved vedligeholdelse af det lokale øjebliksbillede er, at det faktisk giver dig mulighed for at reagere på en mere smidig måde på sikkerhedshændelser. Hvis du finder ud af, at nogen har fundet ud af, hvordan man udnytter en tredjepartsafhængighed, vil du måske ikke vente på opstrøms for at løse det. Du kan måske sige, "Hej, nogle mennesker har fundet en løsning. Vi lapper vores lokale kopi, fordi vi måske kun bruger noget af den funktionalitet, den giver." Vi kunne skære ud af hvad der kan udnyttes, hvis vi ikke rent faktisk bruger det. Skub til vores lokale arkiv og ikke skal vente på opstrøms for at sikre vores servere mod nul dagen.

Tierney Cyren: 11:50 Det er super fantastisk. Det er en meget interessant del. Jeg er lidt spent på at se, hvordan du udvikler dig til det rum. Mange af de ting, du sagde, taler slags til det næste emne, som vi diskuterede, eller hvor vi skal diskutere, hvilket er, at der er en masse forskellige ting, som udviklere og rammer kan gøre. Det er altid slags virvlet, i det mindste for mig. Jeg er nysgerrig efter, hvad er problemerne omkring sikkerhed, som devs forventer, at rammerne skal løse?

Mike Samuel: 12:30 Det er et fremragende spørgsmål. Den foregående ting mindede mig om en ting mere om, slags, hvad dine projektledere skulle spørge, og det er for mig et team, der har en historie om, hvad de skal gøre, når ting går galt, vil være på et bedre sted .

Tierney Cyren: 12:30 Absolut.

Mike Samuel: 12:49 Et hold der, slags "Hvor er vores databasebackup?" Du ved, "Kan hvem, der holder personsøgeren, hvis personsøgeren går af ved midnat, ved de hvordan man gendanner en ny og god version af applikationen fra sikkerhedskopi? Og ved de, om det tilfældet er et relativt nyt medlem af hold, ved de hvordan man kontakter nogen, der kan give et andet par øjne. "

Tierney Cyren: 13:18 Ja, helt. Helt ærligt går det faktisk ind i min tankeproces omkring spørgsmålet om, hvilke sikkerhedsproblemer der kan forventes, at rammer skal løse i, at en delmængde af rammer er lokal cache. Det er en af ​​de ting, som jeg personligt ikke har set nok personer og virksomheder, der gør. Den slags svar på spørgsmålet om, "Okay, vi har en lokal cache. Her er den ting, jeg har brug for,". Det går også til dette er en ramme for at løse dette problem. Selvom jeg ikke nødvendigvis ved, om det er sådan vi taler om rammer i den forstand, at hvilke sikkerhedsproblemer der skal løses.

Mike Samuel: 14:05 Jeg tror, ​​ja. For eksempel leverer nogle applikationsbeholdere, når du skubber til en ny version af din applikation, de giver cacher til de gamle versioner. Du kan vende tilbage til en gammel version, hvis du har problemer med den nye version. Er det slags, hvad vi taler om?

Tierney Cyren: 14:27 Ja, ja. Jeg tænker på noget som enten JFrog Artifactory eller Verdaccio, som er en nodeapp, der bare er i lokal npm cache.

Mike Samuel: 14:40 Ja.

Tierney Cyren: 14:40 Bare så du ved, JFrog Artifactory er et betalt produkt, men det er en cache i enterprise grade, dybest set. Det er sådan, hvad jeg tænker på i den periode af en ramme, der giver et niveau af sikkerhed. Det er ikke rigtig en sikkerhedsfunktion, men det er mere af et: "Hvordan løser vi noget, når der er et problem, som vi ikke selv kan løse." Ja, det er en underlig form for gråt område, men jeg tror, ​​det vil løse det punkt, som du talte om.

Mike Samuel: 15:10 Ja, og jeg synes, det er fint at betragte den slags rammekode. Jeg tror, ​​du har ret i, at der er visse slags problemer, som vi kan forvente at løse i en ramme som Express, og at der er visse problemer, der muligvis kan løses i noget som Artifactory.

Tierney Cyren: 15:31 Ja og-

Mike Samuel: 15:32 Det ville helt sikkert være relevant for, slags, hvordan ... Hvor kan det være et sted at offload køre et postinstallations script, så vi kan adskille dem fra udviklerrettigheder.

Tierney Cyren: 15:46 Jeh. Du nævnte Express, hvad er de ting, Express skal løse? Hvad er sikkerhedsproblemerne på det niveau, der skal løses?

Mike Samuel: 15:58 Jeg er frygtelig uvidende om, hvordan Express bruges. Min forståelse af Express er, at det er en grab taske med mange forskellige funktioner, og mange forskellige produktteam bruger forskellige undergrupper af disse funktioner. Når det er sagt, tror jeg, du kan adressere mange, du ved, at rammer kan give dig et sted at kontrollere en sikkerhedsantagelse. Det kan også gøre det meget let at konsekvent bruge gode værktøjer. Jeg tror, ​​Express-bundter med et sæt af biopipehåndterere. Det er et sted, du kan kontrollere sikkerhedsantagelsen. De giver dig også mulighed for at samle 10 fodssprog. For eksempel, hvis den enkleste, letteste ting er at bruge en kontekstuelt auto, der slipper fra 10 fods sprog, kan du virkelig få et greb på XSS.

Mike Samuel: 17:06 En anden måde at tackle mange sikkerhedsproblemer på er at repræsentere sikkerheden mod sikkerheden af ​​en eller anden værdi, som du vil sende over ledningen som at have en bestemt køretidstype. Frameworks kan lide Express kan give et sted at kontrollere denne antagelse konsekvent. For eksempel udtrykker jeg måske i typesystemet en sondring mellem en almindelig gammel streng og en streng med html, som jeg ved, at det er sikkert at indlæse i vores oprindelse. Du ved, måske er sikker html bare navnet på en type, der pakker en streng. Vi gør dette gennem et halvt dusin programmeringssprog og rammer inden for Google. Jeg definerer en type, der indkapsler nogle sikkerhedsegenskaber. Du ved, sikker html er sikkert at indlæse i en DOM i min virksomheds oprindelse. Express kan derefter ændre skrivningen, så hvis du tilmelder dig denne ekstra sikkerhedsantagelse, vil den indvende vilkårlige strenge, der er skrevet til dit svarskrop, når indholdstypen er html. Det tillader og pakker disse værdier ud. Det kunne integrere skabelonsystemer som low-end producenter af sikre html-værdier for at gøre dette gennemsigtigt for brugeren, hvor der ... Du ved, hvornår de bruger de værktøjer, den giver. De kan også indeholde en html-sanitizer, der er en anden lav ende, slags pålidelig producent af disse sikre html-værdier.

Mike Samuel: 19:10 Hvis du repræsenterer som et objekt, hvis du repræsenterer dine sikkerhedsforudsætninger i dit typesystem, kan rammen kontrollere typen, kontrollere de antagelser, hvor de skal kontrolleres. Rammen kan ved hjælp af sammenlægningsværktøjer gøre det meget let for udviklere at producere værdier til at skelne strenge, der kan komme fra et kapitel, fra værdier, der har været igennem en proces, der har været kendt for at producere sikre afsætningsmuligheder. Jeg tror, ​​jeg gentog mig selv og mumlede lidt der.

Tierney Cyren: 19:44 Du er god, du er god. Ja, så meget ... En af de ting, jeg slags plukket op i, det er som om det har et udvideligt system, er vigtigt for dette. Det er meget af hvad Node.js har gjort. En masse af knudepunkterne er udvidelige. Du bygger på andres arbejde, ikke? Du koble dig ind i tingene. Udtrykk meget gør det. Jeg vil faktisk gerne kalde det en bestemt ting bare for folk, der lytter, er Hjelm. Hjelm er et super godt værktøj til Express, og jeg synes, at HAPI også gør en masse af disse ting som standard. Det går lidt videre. Express som et værktøj skal gøre dette, men så går det faktisk ind, "Hej, vi gør alle disse ting, som Express ikke gør." Uden for Express og det specifikke økosystem synes jeg, det er en meget værdifuld ting for mennesker, der er interesseret i sikkerhed og er interesseret i det, at faktisk gå efter værktøjer, der eksplicit går og gør disse ting, som et kernebibliotek eller en kerneramme ikke gøre.

Mike Samuel: 20:49 Ja, og jeg tror nogle-

Tierney Cyren: 20:51 Har du tanker eller følelser omkring det?

Mike Samuel: 20:52 Jeg synes, at hjelm gør et godt stykke arbejde blandt andet med sikkerhedsrelevante overskrifter. Du ved det, og sørg for, at dit html-svar har de overskrifter, du har brug for. Jeg tror, ​​at siden nettet begyndte, har folk lagt mærke til, at "Hej, der er denne slags almindelige problemer, som vi kan løse, men vi kan ikke bare ændre den måde, browsere fungerer, og så tilføj en overskrift og lad folk vælge at vælge den slags set adfærd, "X indholdstypemuligheder er en af ​​disse. Hjelm giver dig mulighed for, slags, gør det let at sikre dig, at du ikke går glip af mange af dem, der vælger at se adfærd ting og generere ting som indholdssikkerhedspolitikker til lockdown eval og klientsiden JavaScript, og den slags ting.

Tierney Cyren: 21:52 Ja. De gør et godt stykke arbejde med mange ting. De gør også et par interessante kantsager. Jeg kan ikke tænke på dem fra toppen af ​​mit hoved, jeg har skrevet et par artikler om det. Ja, jeg kan ikke tænke på det fra toppen af ​​mit hoved. Når det er sagt, er jeg nysgerrig, er den slags abstraktion af ansvaret for en anden? Disse ting skal teoretisk være inkluderet i Express. Er det godt, at nogen tog sig tid til at bygge det, hvor de anerkendte svaghederne, eller skulle det være noget, der er inkluderet i Express? Eller ligesom uanset ende. Express og hjelm er et eksempel her, der er flere eksempler på ting som dette, men den slags tilgang til at gå og rette ting. Er du nysgerrig efter, hvad dine tanker er omkring det?

Mike Samuel: 22:43 Jeg har ikke talt med Express-vedligeholdere om dette, men min forståelse er, at Express, de har en stor implementeret base af klienter.

Tierney Cyren: 22:52 Ja.

Mike Samuel: 22:55 Det er meget svært at ændre de bid, der sendes over ledningerne. Jeg tror, ​​rammer, Express er meget en plugin-model. Slags at give et korset af plugins, der gør ting som hvad noget af det, Hjelm gør med, jeg ved ikke pusten fra, hvad Hjelm gør, men noget af det, Hjelm gør omkring ting som responsoverskrifter. At kunne sige, "Hej, dette er min sikkerhedsstilling på en liste over velkendte plugins." Derefter skal du sørge for, at enhver afgang fra, du ved, ligesom jeg har disse plugins, der leverer nye spædbørnsværktøjer, gør det let for mit udviklingshold. Jeg vil have, at mit udviklingshold skal bruge dem konsekvent, og jeg vil have en lille hvid liste over undtagelser fra disse regler. At støtte den model, tror jeg, er noget, Express kan gøre.

Tierney Cyren: 24:22 Awesome.

Mike Samuel: 24:23 Igen, min forfærdelige uvidenhed er en slags åndedrag fra det, Express-teamet laver. De har muligvis allerede gjort store fremskridt i dette område, ved jeg ikke.

Tierney Cyren: 24:32 Ja, jeg er heller ikke så bekendt med dem, som jeg burde være.

Mike Samuel: 24:35 Ja, jeg har virkelig brug for at lære noget om det.

Tierney Cyren: 24:37 Det er okay. Ja, der sker bestemt meget der konstant. Vi har snakket lidt om, hvilke problemer rammerne skal løse. Hvad med problemer, der ikke er på rammernes skuldre? Er det noget, du har stærke følelser omkring eller nogen tanker omkring?

Mike Samuel: 25:01 For Node.js-rammer er næsten hele klientsiden JavaScript ikke på deres skuldre. Jeg tror, ​​at nogle rammer prøver at udføre kodebevægelse fra en server til klienten, og så kan de muligvis stå et sted at også dyrlæge og måske omskrive klientsidekoden for at udføre dynamisk håndhævelse. Ja, mange af angrebene på netværksniveau er ting, der bedst adresseres på containerniveau. Hvis din Google Cloud eller Amazon-ækvivalent ... Ja, så der er mange angreb på netværksniveauet, der bedst adresseres på containerniveau.

Tierney Cyren: 25:46 Når du siger-

Mike Samuel: 25:46 En masse -

Tierney Cyren: 25:48 Jeg ville sige, når du siger container, mener du ligesom Docker eller hvad, slags containere og citerer udskiftning? Eller mener du ligesom enhver form for server? Som VPS eller hvad som helst metal du bruger til, sondringen der.

Mike Samuel: 26:07 Ja, så der ... Et system er en gruppe af, slags samarbejdende maskiner. Containere giver en måde at introducere disse maskiner til hinanden. Jeg har muligvis et antal servere op til et antal databasestøtter, og måske er der også nogle mikrotjenester her. Containeren er hvor du muligvis kan håndtere al udveksling af hemmelige strenge, der tillader og siger, "Hej, du er en server. Det er her, du kan finde din databaseadgang. Her er tjenesterne." Det giver meget af det. Du kan angribe et system ved at prøve at komme i tale med en anden database backend eller forsøge at aflytte den trafik. Containeren kan gøre meget for at sikre, at alle dem er krypteret. Nogle gange vil du have alle dine ... Ideelt set, du tjekker, du autoriserer adgang på hvert enkelt niveau. Dine mikrooverflader har ikke bare tillid til en meddelelse, fordi den tilfældigvis kom fra din webfront. Din web-frontend, når den sender en meddelelse til en mikrooverflade eller til din ramme, indeholder den nogle legitimationsoplysninger.

Mike Samuel: 27:42 Lad os sige, at jeg gør det på vegne af en bestemt bruger, og hvert trin i kæden godkender igen. Slags at trænge disse slutbrugeroplysninger gennem dette distribuerede system, der kan involvere både rammerne og containeren, fordi containeren ofte er den, der slags genererer hemmeligheder for hver node i det distribuerede system, eller måske for hver proces, der kører på en knude i det distribuerede system. Dette bliver banket ind i FDO og den slags ting, som ikke er min specialitet.

Tierney Cyren: 28:30 Ja, ja. Samme. På det er en af ​​de ting, som jeg undrer mig over, temmelig ofte, hvad er nogle af de mere nye ting, der sker med hensyn til devs og behov for at planlægge for sikkerhed. Sikkerhed er slags ofte ... Det udvikler sig nogensinde. Hvordan genkender folk, hvad der sker nu? Så hvordan kan de også, du kan genkende, hvad der sker nu, hvordan planlægger de at genkende, hvad der sker i fremtiden?

Mike Samuel: 29:11 Der er en række nye trusler lige nu, så disse ruter eller funktioner kan give disse kilder til trusler. For eksempel er der nu brugerdefinerede elementer i browsere. Der var et papir kaldet Script Gadgets-papiret, som skulle, hvordan funktioner som html-import og nogle måder, som nye rammer som Polymer og React bruger til at registrere elementdefinitioner. Jeg tror, ​​det faktisk ikke registrerer elementdefinitioner, men jeg tror, ​​at html-importen, nogle af html-import-tingene blev det gennem React. Hvordan disse nye funktioner kan lade dig omgå, omgå indholdssikkerhedspolitikker og andre mekanismer, du bruger til at kontrollere, hvordan kode indlæses på en klient. Der er det. Hvis du tilfældigvis laver blockchains, den nye ting, er der et voksende antal sikkerhedslitteraturer om måder ikke at udføre blockchain på, og hvordan almindelige applikationsfejl kan føre til problemer i ... Så at du attesterer til ting, du burde ikke attesterer.

Mike Samuel: 30:46 Jeg tror, ​​en anden af ​​de store ændringer i sikkerhed, det plejede at være tilfældet, at sikkerhed fuzzers, du kunne køre en sikkerhed fuzzer, og det ville pege dig på nogle mulige lækage steder i dine applikationskoder. Angribere begyndte at køre sikkerhedsfuzzere, så de automatisk genererede en masse forespørgsler for at se, "Hej, dette websted bruger muligvis en gammel version af et eller andet indholdsstyringssystem, som er kendt sårbart." Der bygges nu fuzzere omkring systemer til begrænsning af problemer. Der har sandsynligvis været en smule mere af et våbenløb mellem sikkerhedstestere og angribere, fordi systemer med begrænsningsløsning er deleistiske, så bare fordi jeg tilfældigvis er ... Mit begrænsningsløsningssystem finder muligvis ni ud af 10 sårbarheder. Hvis angribernes system til begrænsning af løsningen finder ni ud af 10 sårbarheder, men de er ikke de samme ni, har du et problem. Jeg tror, ​​du også spurgte, hvordan du håndterer nye trusler.

Tierney Cyren: 32:06 Jepp.

Mike Samuel: 32:06 Ideelt set har du en sikkerhedspecialist, der læser gennem litteraturen og holder dig informeret, og filtrerer ind for at se, hvad der er relevant og hvad der ikke er. Jeg synes, der er noget godt værktøj på dette område. Npm Audit, for eksempel, gør ... Du ved, det er en fantastisk funktion, som slags fortæller dig, når dine afhængigheder har kendte problemer. Ikke alle sikkerhedssårbarheder gør det til kilden til sandhed for npm Audit, men det er godt i tilfælde, hvor disse faktisk offentliggøres. Ja, hvis du ikke er en sikkerhedspecialist, skal du bare kende en som mig, der læser html-specifikationen, så du ikke behøver det.

Tierney Cyren: 33:14 Awesome. Ja, jeg har ikke en masse ting at spørge om det, men jeg vil afholde dem i øjeblikket. For at gå videre til vores sidste ting eller vores sidste emne, vil jeg gerne spørge, hvilke nye funktioner i JavaScript på et platformniveau, på et rammeniveau og applikationsniveau, der kan eller ville hjælpe teams med at styre sikkerhed for dev eller produktionsinstallationer ?

Mike Samuel: 33:45 I betragtning af at mange nodeprogrammer, ved du, koden, som jeg skriver som applikationsudvikler, er bare toppen af ​​isbjerget. Der er denne enorme mængde tredjepartsafhængighedskoder, som jeg er afhængig af. Jeg tror, ​​en af ​​de kritiske ting er måder, som jeg sagde før, at stole på kode for at gøre hvad, du ved, stole på kun de moduler, der har brug for en bestemt kilde til synlig autoritet med adgang til det. Kun de ting, der virkelig har brug for børneprocessen, får adgang til det. At kunne sige, "Disse moduler har brug for det, og jeg antager, at resten ikke gør det," kræver, at vi har et eller andet begreb om modulidentitet. Jeg har foreslået TC39, det udvalg, der opretholder sproget, et bestemt begreb om modulidentitet. Jeg tror, ​​at JavaScript har et meget dynamisk sprog i JavaScript. Statiske analysatorer som typeskripter, typesystem som ESLint, som Googles Closure Compiler er gode, men de skal tage optimistiske antagelser. Det er vigtigt at repræsentere sikkerhedsantagelser om værdier i systemet for driftstid.

Mike Samuel: 35:26 Jeg er en stor fan af kontrakttyper, og jeg har udgivet pakken for noden sek mønstre til at tjene som grundlag for det. Derefter tror jeg, vi har brug for en måde at låse kræfter på, som du ved, funktioner, der sjældent bruges, og som vides at være problemer. Eval er ondt, men så længe en af ​​dine afhængigheder virkelig har brug for den, så er du nødt til at tænde den for hele runtime. Det er uheldigt. Eval har legitime anvendelser i, slags, indlæsning af den tomme genererede kode. Igen, ja, differentiel autoritet for moduler bør ikke bare udvides til andre moduler. Det bør også udvides til indbyggede inser som Eval.

Tierney Cyren: 36:35 Fantastisk. Med det synes jeg, vi skal pakkes sammen, men inden vi gør det, er der nogen links, du gerne vil henvise folk til? Nogen steder, noget folk skal se på? Specielt ligesom hvis det forslag til identifikatorerne i JS på TC39, hvis det er op, ville det være fantastisk. Ellers andet?

Mike Samuel: 36:57 Ja, meget af det holdt jeg foredrag på JSCon i Berlin. Det synes jeg snart skulle være på YouTube. JS Con, det er en fantastisk konference, og de sætter alle deres taler op. Jeg har også nogle ambitioner om at være en YouTube-start, så jeg sammensætter en YouTube-serie om at vise en række webpuslespil. Hvis du kan lide sikkerhedsopgaver, kan du tjekke det ud. Hvis du går til medium.com/@mikesamuel, skal du finde det. Det kaldes bare "Puslespil mod sikkerhed." Det er her, jeg offentliggør ikke ofte, men det er her, jeg offentliggør mine tanker om, hvordan man koordinerer, gør interaktioner mellem sikkerhedsteam og applikationsudviklere mere effektive og produktive.

Tierney Cyren: 38:10 Awesome. Nå, tak, fordi du deltog i forretningsteknologisamtaler. Jeg sætter virkelig pris på det.

Mike Samuel: 38:17 Ja, meget tak. Det var dejlige spørgsmål.

Tierney Cyren: 38:17 Fantastisk, tak.