Citat:
Ursprungligen postat av
0xgh64
Tjoo, någon här som någonsin exploitat dependency confusion? Detta fall NodeJS. Eller har mer erfarenhet en mig i NodeJS som vill fylla i lite? Testar en website i ett bbp program och när jag bläddrade igenom lite saker med JS miner på i Burpsuite i bakgrunden, hittade JS miner en oregistrerad npm module i en av .js filerna, pathen ser ut som /assets/index.3d32f.js. I all JavaScript är ett object som innehåller en massa paths som /node_modules/@module/web-components/icons/img.svg (alla är likadanna med olika svg filer, sammt en del keys & values). Är inte familjär med exakt hur frontend läser in modulerna, men som jag skulle tänka mig står @ för en import av modulen från backend/server-side? Kan dom ha en module i deras interna nätverk och därför finns den inte på npmjs.com? Scenariot jag tänkte mig var att ladda upp mitt egna npm package och börja med att testa med en out of band DNS interaction > DNS exfiltration > RCE. Osäker dock är det värt att försöka sig på att skriva sitt egna npm package? Får ursäkta svengelskan men blir alltid lika jävligt att börja vrida om vissa ord när det kommer till IT/kodning etc. Och till moderatorn får jag be om ursäkt om det blev dubbla inlägg, men har på känn att jag får bättre svar i den här tråden.
Edit: Kommer man att hamna skriva om kod efter kontext från JavaScript filen?
@ på en modulnamn betyder
inte att det är en modul som skall hämtas från backend. Det handlar snarare om att man vill förtydliga scopet som man skriver @. Men ja, det är vanligt att man kan ha egna privata moduler som installeras i node-projektet från en lokal path istället för att hämtas från npm-registry. Det är också vanligt att man har sina privata moduler i en privat Github repo, och då modulen att hämtas in via npm package managern när man kör npm install. Man lägger således in access token i själva package.json så att den har access till det privata repot.