Dependency Confusion
Basiese Inligting
Kortliks, 'n afhanklikheidsverwarringskwesbaarheid kom voor wanneer 'n projek 'n biblioteek met 'n verkeerd gespelde naam, nie-bestaande of met 'n ongespesifiseerde weergawe gebruik en die gebruikte afhanklikheidsbewaarplek toelaat om bygewerkte weergawes van openbare bewaarplekke te vergaar.
Verkeerd gespelde: Importeer
reqestsin plaas vanrequestsNie-bestaande: Importeer
company-logging, 'n interne biblioteek wat nie meer bestaan nieOngespesifiseerde weergawe: Importeer 'n interne bestaande
company-requests-biblioteek, maar die bewaarplek kyk na openbare bewaarplekke om te sien of daar groter weergawes is.
Uitbuiting
In alle gevalle hoef die aanvaller net 'n skadelike pakkie met die naam van biblioteke wat deur die slagoffermaatskappy gebruik word, te publiseer.
Verkeerd gespelde & Nie-bestaande
As jou maatskappy probeer om 'n biblioteek in te voer wat nie intern is nie, is dit baie waarskynlik dat die bewaarplek van biblioteke dit in openbare bewaarplekke gaan soek. As 'n aanvaller dit geskep het, is dit baie waarskynlik dat jou kode en masjiene wat dit hardloop, gekompromitteer gaan word.
Ongespesifiseerde Weergawe
Dit is baie algemeen vir ontwikkelaars om geen weergawe te spesifiseer van die gebruikte biblioteek, of net 'n hoofweergawe te spesifiseer. Dan sal die tolk probeer om die nuutste weergawe wat aan daardie vereistes voldoen, af te laai.
As die biblioteek 'n bekende eksterne biblioteek is (soos python requests), kan 'n aanvaller nie veel doen nie, aangesien hy nie 'n biblioteek met die naam requests kan skep (tensy hy die oorspronklike skrywer is).
Maar, as die biblioteek intern is, soos requests-company in hierdie voorbeeld, as die biblioteekbewaarplek toelaat om ook eksterne nuwe weergawes te soek, sal dit soek na 'n nuwer weergawe wat openlik beskikbaar is.
Dus, as 'n aanvaller weet dat die maatskappy die requests-company-biblioteek weergawe 1.0.1 gebruik (laat klein opdaterings toe), kan hy die biblioteek requests-company weergawe 1.0.2 publiseer en die maatskappy sal daardie biblioteek gebruik in plaas van die interne een.
AWS-oplossing
Hierdie kwesbaarheid is gevind in AWS CodeArtifact (lees die besonderhede in hierdie blogpos). AWS het dit reggestel deur toe te laat om te spesifiseer of 'n biblioteek intern of ekstern is, om te verhoed dat interne afhanklikhede van eksterne bewaarplekke afgelaai word.
Vind Kwesbare Biblioteke
In die oorspronklike pos oor afhanklikheidsverwarring het die skrywer gesoek na duisende blootgestelde package.json-lêers wat die afhanklikhede van JavaScript-projekte bevat.
Verwysings
Last updated
