പതിപ്പ് പിന്നിംഗിന്റെ അഭാവം, ആശ്രയത്വ ആശയക്കുഴപ്പം

സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ നമ്മൾ സ്വന്തം ഘടകങ്ങളെയും മൂന്നാം കക്ഷി ഘടകങ്ങളെയും അല്ലെങ്കിൽ ആർട്ടിഫാക്റ്റുകളെയുമാണ് ആശ്രയിക്കുന്നത്. ആധുനിക സോഫ്റ്റ്‌വെയറിന് ഒരു വഴക്കമുള്ള ഡിപൻഡൻസി മാനേജ്മെന്റ് അത്യാവശ്യമാണ്. NPM പോലുള്ള പാക്കേജ് മാനേജർമാർ, മാവൻ, PIP or ന്യൂജെറ്റ് സോഫ്റ്റ്‌വെയർ ആശ്രിതത്വം വ്യക്തമാക്കാൻ പലപ്പോഴും ഉപയോഗിക്കുന്നു. സുരക്ഷയെക്കാൾ സൗകര്യവും ഉപയോഗ എളുപ്പവും മനസ്സിൽ വെച്ചുകൊണ്ടാണ് ഈ ഉപകരണങ്ങൾ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

പ്രശ്നം

പ്രശ്നം എന്തെന്നാൽ, ഡെവലപ്പർമാർക്ക് ഉപയോഗിക്കാനുള്ള വഴക്കവും എളുപ്പവും മോശം ആളുകളെയാണ് വിളിക്കുന്നത്, കാരണം അവർ സോഫ്റ്റ്‌വെയർ ആശ്രിതത്വം തങ്ങളുടെ ബിസിനസിന് അപ്രതിരോധ്യമായി ആകർഷകമാണെന്ന് കാണുന്നു. ഫലം: മോശം അഭിനേതാക്കൾ ഇവിടെ കാണിച്ചിരിക്കുന്ന എല്ലാ ആക്രമണ പാതകളും പിന്തുടർന്നു. ഉറവിടം: “ബാക്ക്‌സ്റ്റാബേഴ്‌സ് നൈഫ് കളക്ഷൻ: ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ സപ്ലൈ ചെയിൻ ആക്രമണങ്ങളുടെ ഒരു അവലോകനം”

ഈ പോസ്റ്റിൽ നമ്മൾ ഓപ്പൺ പതിപ്പ് ഡിക്ലറേഷനുകളുടെ ഉപയോഗത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും, അതായത് ഡൗൺലോഡ് ചെയ്ത പതിപ്പ് സ്ഥിരമല്ല, പക്ഷേ ഒരു നിശ്ചിത ശ്രേണിയിൽ ഉൾപ്പെട്ടിരിക്കണം. നിർമ്മാണ സമയത്ത്, വ്യക്തമാക്കിയ പതിപ്പ് ശ്രേണിയുമായി പൊരുത്തപ്പെടുന്ന നിലവിലുള്ള ഏറ്റവും ഉയർന്ന പതിപ്പ് പാക്കേജ് മാനേജർ തിരഞ്ഞെടുത്ത് ഡൗൺലോഡ് / ഇൻസ്റ്റാൾ ചെയ്യുന്നു.

വ്യത്യസ്ത പാക്കേജ് മാനേജർമാർക്കുള്ള ഡിപൻഡൻസി ഡിക്ലറേഷനുകളിലെ ഓപ്പൺ ഡിക്ലറേഷനുകൾ നമുക്ക് ചിത്രീകരിക്കാം:

• • എൻ‌പി‌എം: package.json

{

 

   പങ്ക് € |

   "ആശ്രിതത്വം": {
      പങ്ക് € |
      “സ്വീകരിക്കുന്നു”: “>=1.3.8”,
      “ലോഡാഷ്”: “~4.16.0”,
      പങ്ക് € |
   },
   പങ്ക് € |
}

സ്വീകരിക്കുന്ന പാക്കേജിനായി 1.3.8 ൽ കുറയാത്ത ഏറ്റവും വലിയ നിലവിലുള്ള പതിപ്പും 4.16.x ശ്രേണിയിലെ ലോഡാഷിനായുള്ള ഏറ്റവും വലിയ 'പാച്ച്' അപ്‌ഡേറ്റും ഇൻസ്റ്റാൾ ചെയ്യപ്പെടും.

• • മാവെൻ: pom.xml

...

...

     കോമൺസ്-ഐഒ
     കോമൺസ്-ഐഒ
     റിലീസ് ചെയ്യുക

...

...

commons-io (jar ഫയൽ) ന് ലഭ്യമായ അവസാന പതിപ്പ് ആശ്രിതത്വമായി ചേർക്കും.

• • നുറുങ്ങ്: setup.py

...
സജ്ജമാക്കുക(
    ...
    install_requires=['പെപ്പർകോൺ', 'launchpadlib'],
    ...
)
...

ഇത്തരം ഓപ്പൺ പതിപ്പ് സ്കീമുകൾക്ക് ഗുണവും ദോഷവും ഉണ്ട്. പുതിയ പതിപ്പുകൾ സാധാരണയായി പ്രവർത്തനപരവും ഗുണനിലവാരപരവുമായ മെച്ചപ്പെടുത്തലുകൾ, ബഗ് പരിഹാരങ്ങൾ, സുരക്ഷാ പാച്ചുകൾ എന്നിവ ഇതിൽ അടങ്ങിയിരിക്കുന്നു, അവ യാന്ത്രികമായി അപ്‌ഗ്രേഡ് ചെയ്യപ്പെടുന്നു. മിക്ക യഥാർത്ഥ ലോക പ്രോജക്റ്റുകൾക്കും, ദുരന്തകരമായ സുരക്ഷാ കേടുപാടുകൾ ഒഴികെ, പരിഹാരങ്ങൾ മുൻ ചെറിയ പതിപ്പുകളിലേക്ക് ബാക്ക്‌പോർട്ട് ചെയ്യുന്നില്ല എന്നത് ദയവായി ശ്രദ്ധിക്കുക. എല്ലാ ഡിപൻഡൻസികളും പരിഹരിക്കപ്പെടുമ്പോൾ ഇൻസ്റ്റാൾ ചെയ്യേണ്ട പതിപ്പുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന്, ലൈബ്രറികളിൽ ഉപയോഗിക്കുന്നതിന് ഓപ്പൺ പതിപ്പുകളും നല്ലതാണ്.

എന്നാൽ ഓപ്പൺ പതിപ്പ് ശ്രേണികൾക്ക് ഒരു മോശം വശമുണ്ട്. ബിൽഡ് സമയത്ത് ഏതൊക്കെ പതിപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുമെന്ന് നിങ്ങൾക്ക് കൃത്യമായി അറിയില്ല, കൂടാതെ ബിൽഡുകൾ ആവർത്തിക്കാനും കഴിയില്ല. കൂടാതെ ഒരു ഇരുണ്ട തുറന്ന പതിപ്പുകളുടെ വശത്ത്. ഒരു മോശം നടന് നിങ്ങളുടെ ഓപ്പൺ റേഞ്ചുമായി പൊരുത്തപ്പെടുന്ന ഉയർന്ന പതിപ്പുള്ള ഒരു പൊതു ശേഖരത്തിൽ ഒരു ക്ഷുദ്ര ഘടകം പ്രസിദ്ധീകരിക്കാൻ കഴിഞ്ഞാൽ, നിങ്ങളുടെ അടുത്ത ബിൽഡിൽ ക്ഷുദ്ര ഘടകം ഉൾപ്പെടും, ഒരുപക്ഷേ യാന്ത്രികമായി നടപ്പിലാക്കാൻ സാധ്യതയുള്ള ഇൻസ്റ്റലേഷൻ സ്ക്രിപ്റ്റുകളിൽ മാൽവെയർ പ്രവർത്തിപ്പിക്കപ്പെടാം. ആക്രമണ പേലോഡ് അവ്യക്തമാക്കുന്നത് ഒരുതരം കലയാണ്.

ഇത് അറിയപ്പെടുന്നത് പതിപ്പ് പിന്നിംഗിന്റെ അഭാവം ഇഷ്യൂ.

ജനപ്രിയ ഓപ്പൺ സോഴ്‌സ് പാക്കേജുകളുടെ ക്ഷുദ്ര പതിപ്പുകൾ ഉൾപ്പെടുത്താൻ മോശം അഭിനേതാക്കൾ എപ്പോഴും ശ്രമിക്കുന്നു. പാക്കേജ് റിപ്പോസിറ്ററികളുടെ കീകളിലേക്ക് അവർക്ക് ആക്‌സസ് ലഭിച്ചേക്കാം; അവർ പലപ്പോഴും സോഷ്യൽ എഞ്ചിനീയറിംഗ് ഉപയോഗിക്കുന്നു അല്ലെങ്കിൽ പ്രത്യക്ഷത്തിൽ ഉപയോഗപ്രദമായ ഒരു പ്രോഗ്രാമിൽ ഒരു നെസ്റ്റഡ് മാലിഷ്യസ് ഡിപൻഡൻസി മറയ്ക്കുന്നു. pull request. ലോകം നീതിയുക്തമല്ലെന്ന് ഒരു ദിവസം കുറച്ച് എഴുത്തുകാർ പോലും തീരുമാനിക്കുകയും അവരുടെ ക്ലയന്റുകളെ കടിക്കുകയും ചെയ്യുന്നു പ്രതിഷേധ വെയർ സ്വന്തം പാക്കേജുകളിൽ!

ഇനി നിങ്ങൾ ആന്തരിക ഘടകങ്ങളും ഓപ്പൺ സോഴ്‌സ് ഘടകങ്ങളും ഉപയോഗിക്കുന്ന ഒരു സ്ഥാപനത്തിൽ ജോലി ചെയ്യുന്നുവെന്ന് സങ്കൽപ്പിക്കുക.
ഒരു മോശം നടന് അത്തരം ആന്തരിക ഘടകങ്ങളുടെ പേര് അറിയാമെങ്കിൽ, അയാൾക്ക്/അവൾക്ക് അതേ പേരിൽ ഒരു ഘടകം പൊതു ശേഖരത്തിൽ പ്രസിദ്ധീകരിക്കാൻ കഴിയും. പല പാക്കേജ് മാനേജർമാരും ആദ്യം പൊതു ഘടകങ്ങൾ നേടുന്നു, കൂടാതെ പതിപ്പ് ശരിയായി തിരഞ്ഞെടുത്തിട്ടുണ്ടെങ്കിൽ നിങ്ങളുടെ പ്രഖ്യാപിത ആശ്രിതത്വത്തിലെ പതിപ്പ് തുറന്നിട്ടുണ്ടെങ്കിൽ, ബൂം! ഈ ലക്കത്തിന് പേര് നൽകിയിരിക്കുന്നു ആശ്രിതത്വ ആശയക്കുഴപ്പം.

ഒരു ഉദാഹരണം കാണിക്കാം. നമ്മുടെ NPM പ്രോജക്റ്റിൽ നമുക്ക് ഒരു സ്വകാര്യ ഘടകത്തെ ആശ്രയിക്കുന്നുവെന്ന് കരുതുക:

• • എൻ‌പി‌എം: package.json

{
  "പേര്": "എന്റെ-പ്രോജക്റ്റ്",

 

  പങ്ക് € |
  "ആശ്രിതത്വം": {

    പങ്ക് € |
    “എന്റെ-സ്വകാര്യ-വകുപ്പ്”: “>=1.0.0”,

    പങ്ക് € |

   }

   പങ്ക് € |

}

 

ആക്രമണകാരി എന്റെ സ്വകാര്യ ഡെപ്പിന്റെ (99.0.0 പോലുള്ളവ) ഒരു ഉയർന്ന മേജർ പതിപ്പ് സൃഷ്ടിച്ച് സ്വന്തം വ്യാജ അക്കൗണ്ട് ഉപയോഗിച്ച് പൊതു npm ശേഖരത്തിൽ പ്രസിദ്ധീകരിച്ചേക്കാം (ആക്രമണകാരിക്ക് എന്റെ സ്ഥാപനവുമായി ഒന്നും ചെയ്യേണ്ടതില്ല). NPM പാക്കേജ് മാനേജർ ക്ഷുദ്രകരമായ ആശ്രിതത്വം ഇൻസ്റ്റാൾ ചെയ്യും, പലപ്പോഴും വിനാശകരമായ ഫലങ്ങൾ ഉണ്ടാകും.

പരിഹാരം

നമ്മുടെ സോഫ്റ്റ്‌വെയർ നിർമ്മാണ പ്രക്രിയയിൽ ഈ പ്രശ്നങ്ങൾ ഒഴിവാക്കാൻ, ഉപയോഗിക്കുന്ന സാങ്കേതികവിദ്യയെ ആശ്രയിച്ച് ഘടക പതിപ്പുകൾ എങ്ങനെ പ്രഖ്യാപിക്കണം എന്നതിനെക്കുറിച്ചുള്ള കർശനമായ മാനദണ്ഡങ്ങൾ പാലിക്കണം. പ്രധാന കാര്യം, ഒരു റിപ്പോസിറ്ററിയിൽ പ്രസിദ്ധീകരിച്ചുകഴിഞ്ഞാൽ, ഒരു പാക്കേജിന്റെ ഒരു പ്രത്യേക പതിപ്പ് മാറ്റമില്ലാത്തതായിരിക്കണം (സുരക്ഷാ കാരണങ്ങളാൽ മാത്രമല്ല, ആശ്രിതരെ തകർക്കുന്നത് ഒഴിവാക്കാൻ).

പൊതുവായ ആശയം സ്ഥിരപ്പെടുത്തുക എന്നതാണ് (മൊട്ടുസൂചി) പതിപ്പുകൾ, ഘടകങ്ങളുടെ സ്ഥിര പതിപ്പുകൾ (എല്ലാ ട്രാൻസിറ്റീവ് ഡിപൻഡൻസികളും ഉൾപ്പെടെ) മാൽവെയറിൽ നിന്ന് മുക്തമാണോ എന്ന് എപ്പോഴും പരിശോധിക്കുന്നു, കൂടാതെ ഇത് സാധ്യമാകുന്നത് ലോക്ക് ഫയലുകൾ പല പാക്കേജ് മാനേജർമാരും വാഗ്ദാനം ചെയ്യുന്നുണ്ട്. വ്യത്യസ്ത പാക്കേജ് മാനേജർമാർക്ക് പതിപ്പ് പിന്നിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നമുക്ക് നോക്കാം. ഇവയ്ക്കിടയിൽ ഒരു സൂക്ഷ്മമായ ഇടപാട് ഉണ്ട് പതിവ് പതിപ്പ് അപ്‌ഡേറ്റുകൾ അറിയപ്പെടുന്ന കേടുപാടുകൾ പരിഹരിക്കുന്നതിനും പതിപ്പ് പിന്നിംഗ് നിർണ്ണായകമല്ലാത്ത നിർമ്മാണങ്ങളും സാധ്യതയുള്ള വിതരണ ശൃംഖല ആക്രമണങ്ങളും ഒഴിവാക്കാൻ.

• • NPM:
    npm അല്ലെങ്കിൽ yarn പാക്കേജ് മാനേജർമാർ വ്യത്യസ്ത ലോക്ക്ഫയലുകൾ (യഥാക്രമം npm-shrinkwrap.json / package-lock.json അല്ലെങ്കിൽ yarn.lock) ഉപയോഗിക്കുന്നു, അവ എല്ലാ ഡിപൻഡൻസികൾക്കും നേരിട്ടും അല്ലാതെയും സ്ഥിരമായ പതിപ്പുകൾ പട്ടികപ്പെടുത്തുന്നു. ലോക്ക്ഫയലുകൾ പതിപ്പ് നിയന്ത്രണത്തിലായിരിക്കണം, അല്ലാത്തപക്ഷം മറ്റ് ഡെവലപ്പർമാർ / ബിൽഡ് നോഡുകൾ വ്യത്യസ്ത പതിപ്പുകളിൽ അവസാനിച്ചേക്കാം. വികസനത്തിലായിരിക്കുമ്പോൾ നിങ്ങൾ ഡിപൻഡൻസികൾ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതില്ലെങ്കിൽ (ഉദാ. സുരക്ഷാ പരിഹാരങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ) npm ഇൻസ്റ്റാൾ ഒഴിവാക്കുക. പൊതുവെ കൂടുതൽ നിർണായകമായ npm ci (ക്ലീൻ ഇൻസ്റ്റാൾ) ഉപയോഗിക്കുക, അതിനാൽ പാക്കേജ് മാനേജർ ലോക്ക്ഫയൽ ഉപയോഗിക്കും അല്ലെങ്കിൽ ലോക്ക്ഫയൽ ഇല്ലെങ്കിൽ പിശക് ഉപയോഗിച്ച് അവസാനിപ്പിക്കും, അല്ലെങ്കിൽ അത് package.json-മായി പൊരുത്തപ്പെടുന്നില്ല. ലിസ്റ്റുചെയ്തിരിക്കുന്ന പതിപ്പുകൾ മാൽവെയറിനായി പരിശോധിച്ചിട്ടുണ്ടെങ്കിൽ, നിർമ്മാണ സമയത്ത് മോശമായ ഒന്നും സംഭവിക്കില്ലെന്ന് ലോക്ക്ഫയൽ ഉറപ്പാക്കുന്നു.

    ആന്തരിക ഘടകങ്ങൾക്ക്, ഒരു സൃഷ്ടിക്കാൻ ശുപാർശ ചെയ്യുന്നു NPM സ്കോപ്പ് ഓർഗനൈസേഷൻ നിയന്ത്രിക്കുന്നത് (@myorg പോലെ), കൂടാതെ സ്വകാര്യ ദൃശ്യപരത മാത്രമുള്ള ഡിപൻഡൻസിയിൽ (@myorg/my-private-dep പോലെ) ആ സ്കോപ്പ് ഉപയോഗിക്കുന്നു. ഇത് തടയുന്നു ആശ്രിതത്വ ആശയക്കുഴപ്പം എഴുത്ത് ആക്‌സസ് ഉള്ള ഓർഗനൈസേഷനിലെ അംഗത്തിന് മാത്രമേ അത്തരം പരിധിയിൽ പാക്കേജുകൾ പ്രസിദ്ധീകരിക്കാൻ കഴിയൂ എന്നതിനാൽ, ആക്രമണങ്ങൾ ഉണ്ടാകാം.

• • മാവൻ:
    മാവെൻ / ഗ്രാഡിൽ ലോക്ക്ഫയലുകൾ ഇല്ല (പക്ഷേ കാണുക ഈ സ്റ്റാക്ക്ഓവർഫ്ലോ ലേഖനം).

    മറ്റ് ആവാസവ്യവസ്ഥകളിൽ ഉപയോഗിക്കുന്നതുപോലെ മാവെൻ/ഗ്രാഡിലിൽ പതിപ്പ് ശ്രേണികൾ ഉപയോഗിക്കാറില്ല. ഒഴിവാക്കുക പതിപ്പ് ശ്രേണികൾ ഏറ്റവും പുതിയതോ പുറത്തിറങ്ങിയതോ ആയ മെറ്റാ പതിപ്പുകൾ. പരോക്ഷ പതിപ്പുകളും പരിശോധിക്കേണ്ടതാണ്. പതിപ്പുകൾ മാവെൻ പ്ലഗിൻ പതിപ്പ് നിയന്ത്രണത്തിനുള്ള ഒരു നല്ല ഉപകരണമാണ്.

    മാവന് എപ്പോഴും ഓർഗനൈസേഷൻ സ്കോപ്പ് (ആശ്രയത്വത്തിന്റെ ഗ്രൂപ്പ് ഐഡി ഭാഗം) എന്ന ആശയം ഉണ്ടായിരുന്നു എന്ന കാര്യം ദയവായി ശ്രദ്ധിക്കുക, ആ ആവാസവ്യവസ്ഥയ്ക്ക് ആശ്രിതത്വ ആശയക്കുഴപ്പം ഒരു പ്രശ്നമല്ലെന്ന് തോന്നുന്നു.

• • PIP:
    ലോക്ക്ഫയലുകൾ കൈകാര്യം ചെയ്യുന്നതിന് പൈത്തണിൽ വ്യത്യസ്ത ഉപകരണങ്ങൾ ഉണ്ട്:

    - പൈപ്പെൻവി, ഇത് ഒരു Pipfile.lock ലോക്ക് ഫയൽ സൃഷ്ടിക്കുന്നു.
    - കവിത, അത് കവിത സൃഷ്ടിക്കുന്നു.ലോക്ക്.
    - പൈപ്പ് ഫ്രീസ്, ഒരു ലോക്ക് ഫയലായി പ്രവർത്തിക്കുന്ന ഒരു requirements.txt സൃഷ്ടിക്കുന്ന കമാൻഡ്. എല്ലാ ഡിപൻഡൻസികളും == ഓപ്പറേറ്ററുള്ള ഫിക്സഡ് പതിപ്പുകൾ ഉപയോഗിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുക. തുടർന്ന് pip install -r requirements.txt ഫിക്സഡ് ഡിപൻഡൻസികൾ ഉപയോഗിക്കുന്നു.

മുകളിലുള്ള ലോക്ക്ഫയലുകൾ പതിപ്പ് നിയന്ത്രണത്തിലായിരിക്കണമെന്നും തിരഞ്ഞെടുത്ത ബിൽഡ് കമാൻഡ് ലോക്ക്ഫയൽ ഉപയോഗിക്കണമെന്നും ഓർമ്മിപ്പിക്കുക.

പൈപ്പിനൊപ്പം (PyPI) ഉപയോഗിക്കുന്ന സാധാരണ പാക്കേജ് റിപ്പോസിറ്ററിയിൽ നാമകരണ സ്കോപ്പുകൾ ഇല്ല, കൂടാതെ ഇത് ആശ്രിതത്വ ആശയക്കുഴപ്പ ആക്രമണങ്ങൾക്ക് ഇരയാകാൻ സാധ്യതയുണ്ട്. പൈത്തൺ ആവാസവ്യവസ്ഥയിലെ ആശ്രിതത്വ ആശയക്കുഴപ്പം ഒഴിവാക്കുന്നു. എളുപ്പമല്ല, ചില എഴുത്തുകാർ PyPI-യിൽ നിന്ന് ലഭിക്കുന്ന പൊതു ആശ്രിതത്വങ്ങൾക്കുള്ള പ്രോക്സിയായി പ്രവർത്തിക്കാൻ ഒരു ആന്തരിക ശേഖരം ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു, എന്നാൽ ആന്തരിക ശേഖരത്തിൽ നിന്ന് ആദ്യം സ്വകാര്യ ആശ്രിതത്വങ്ങൾ എടുക്കുക (-index-url PyPI-യെയല്ല, ആന്തരിക ശേഖരത്തിലേക്ക് പോയിന്റ് ചെയ്യണം, കൂടാതെ –extra-index- url നീക്കം ചെയ്യണം).

ചില യഥാർത്ഥ ആക്രമണങ്ങൾ

ഗെറ്റ്‌കൂക്കീസ് ​​ആക്രമണം: നടൻ dustin87 ജനപ്രിയ npm മെയിൽപാർസർ പാക്കേജിലേക്ക് ഒരു RCE ബാക്ക്‌ഡോർ (gCOMMANDhDATAi) ഉള്ള ഒരു ക്ഷുദ്ര പാക്കേജിലേക്ക് ഒരു പരോക്ഷ ആശ്രിതത്വം ചേർത്തു:

JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, p, v) => {})

ഒഴിവാക്കിയെങ്കിലും (അവലോകകരില്ല!), മെയിൽപാഴ്‌സറിന് ഇപ്പോഴും ഏകദേശം 64,000 ആഴ്ചതോറുമുള്ള ഡൗൺലോഡുകൾ ലഭിച്ചു. RCE യഥാർത്ഥത്തിൽ പ്രായോഗികമായി പ്രവർത്തിച്ചിട്ടില്ലാത്തതിനാൽ, ഇത് ഒരു നിസ്സാര ആക്രമണമായിരുന്നു.cisഎഡി.

NPM പ്രസിദ്ധീകരിച്ചു ഈ പോസ്റ്റ് getcookies ആക്രമണത്തെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾക്കൊപ്പം.

ആശ്രിതത്വ ആശയക്കുഴപ്പം:

2021-ൽ അലക്സ് ബിർസൻ ആശ്രിതത്വ ആശയക്കുഴപ്പം എന്ന പ്രശ്നം കണ്ടെത്തി “” എന്ന തലക്കെട്ടിൽ ഒരു പോസ്റ്റ് പ്രസിദ്ധീകരിച്ചു.ആപ്പിൾ, മൈക്രോസോഫ്റ്റ്, മറ്റ് ഡസൻ കണക്കിന് കമ്പനികൾ എന്നിവയിലേക്ക് ഞാൻ എങ്ങനെ ഹാക്ക് ചെയ്തു".

npm-ന് @myorg പോലുള്ള ഓർഗനൈസേഷൻ സ്കോപ്പ് റിസർവ് ചെയ്യണമെന്നും സ്കോപ്പ് ഉപയോഗിക്കുന്നതിന് ആന്തരിക പാക്കേജുകൾ പരിഷ്കരിക്കണമെന്നും ഓർമ്മിക്കുക.

പൈപ്പ് ഉള്ളപ്പോൾ, പൊതു പബ്ലിക് രജിസ്ട്രി PyPI-യിൽ സ്കോപ്പുകൾ/നെയിംസ്‌പെയ്‌സുകൾ ഇല്ല. ഓരോ സ്വകാര്യ പാക്കേജിനും ആന്തരിക പാക്കേജിന്റെ അതേ പേരിൽ ഒരു പബ്ലിക് പാക്കേജ് സ്ക്വാറ്റ് ഉണ്ടായിരിക്കാം, പക്ഷേ ശൂന്യമായിരിക്കും, ഉപയോഗിക്കുമ്പോൾ ഒരു പിശക് സൃഷ്ടിക്കുന്നുണ്ടാകാം, അതിനാൽ അത് അബദ്ധത്തിൽ ലഭിച്ചതാണെങ്കിൽ അത് തിരിച്ചറിയാൻ കഴിയും.

നോഡ്-ഐപിസി:

റഷ്യ-ഉക്രെയ്ൻ യുദ്ധം ആരംഭിച്ചപ്പോൾ, പാക്കേജ് ഉടമ റഷ്യൻ, ബെലാറഷ്യൻ ഹോസ്റ്റുകളിൽ ഇൻസ്റ്റാൾ ചെയ്തപ്പോൾ റാൻഡം ഫയലുകൾ നീക്കം ചെയ്യുന്നതിനായി ക്ഷുദ്ര കോഡ് കുത്തിവച്ചു. ssl-geospec.js ഫയൽ ഭൂമിശാസ്ത്രപരമായ വ്യത്യാസം ഇങ്ങനെയായിരുന്നു:

രസകരമെന്നു പറയട്ടെ, മറ്റ് പാക്കേജുകൾ നോഡ്-ഐപിസി ഡിപൻഡൻസിക്കായി ഓപ്പൺ പതിപ്പുകൾ ഉപയോഗിച്ചു, ജനപ്രിയ Vue.js ഫ്രെയിംവർക്ക് പോലെ, അതിന്റെ പരിപാലകർക്ക് ഒരു ലഭിച്ചു അടിയന്തര അപ്പീൽ ഒരു സുരക്ഷിത പതിപ്പിൽ നോഡ്-ഐപിസി ആശ്രിതത്വം പിൻ ചെയ്യാൻ.

ഈ പോസ്റ്റിൽ കൂടുതൽ വിശദാംശങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഈ അട്ടിമറിയെക്കുറിച്ച്, ഇത് മറ്റുള്ളവയിൽ നിന്ന് ഒരു പടി കൂടി മുന്നോട്ട് പോകുന്നു പ്രൊട്ടസ്റ്റ്‌വെയർ പ്രശ്നങ്ങൾ.

ഉപസംഹാര കുറിപ്പ്

തുറന്ന പതിപ്പുകൾ ഒരിക്കലും ഏകീകൃത സോഫ്റ്റ്‌വെയർ പ്രോജക്റ്റുകളിൽ ഉപയോഗിക്കാൻ കഴിയും. അവ ബിൽഡുകൾ പുനരുൽപ്പാദിപ്പിക്കാനാവാത്തതാക്കുന്നു, കൂടാതെ ആക്രമണകാരികൾ അവയെ ചൂഷണം ചെയ്യുകയും മുകളിൽ പറഞ്ഞ ആശ്രിതത്വ ആശയക്കുഴപ്പം പോലുള്ള ആശ്രിതത്വ വൃക്ഷങ്ങളിലേക്ക് ആക്രമണങ്ങൾ വഴി മാൽവെയർ കുത്തിവയ്ക്കുകയും ചെയ്തേക്കാം.

പോലുള്ള തെറ്റായ കോൺഫിഗറേഷനുകൾ തുറന്ന പതിപ്പുകൾ, പതിപ്പ് പിന്നിംഗിന്റെ അഭാവം, അല്ലെങ്കിൽ സ്കോപ്പ് ചെയ്യാത്ത ആന്തരിക ഘടകങ്ങൾ ഒഴിവാക്കണം. ആദ്യം ചെയ്യേണ്ടത് അത്തരം പ്രശ്നങ്ങൾ കണ്ടെത്തുക എന്നതാണ്, ഒരുപക്ഷേ അവ കണ്ടെത്തുമ്പോൾ ബിൽഡിനെ തടയുക പോലും, കൂടാതെ നടപടിയെടുക്കുന്നതിനുള്ള ഒരു പ്രോട്ടോക്കോൾ സ്റ്റാൻഡേർഡൈസ് ചെയ്യുക എന്നതാണ്.

ആശ്രിതത്വങ്ങളിലെ പിഴവുകളും തെറ്റായ കോൺഫിഗറേഷനുകളും സ്വയമേവ കണ്ടെത്തൽ, നിർദ്ദിഷ്ട വിതരണ ശൃംഖല ആക്രമണങ്ങൾക്ക് ഇരയാകാൻ സാധ്യതയുള്ള സംശയാസ്പദമായ ആശ്രിതത്വങ്ങൾ റിപ്പോർട്ട് ചെയ്യൽ, ആശ്രിതത്വ ആശയക്കുഴപ്പംപ്രവർത്തനക്ഷമമായ പരിഹാര ഉപകരണങ്ങൾ ഉപയോഗിച്ച്, എല്ലാം പ്രധാന ലക്ഷ്യങ്ങളിലൊന്നാണ് സൈജെനി പ്ലാറ്റ്‌ഫോം.