संस्करण पिनिङको अभाव र निर्भरता भ्रम

सफ्टवेयर विकासमा हामी आफ्नै र तेस्रो-पक्ष कम्पोनेन्ट वा कलाकृतिहरूमा निर्भर हुन्छौं। आधुनिक सफ्टवेयरको लागि लचिलो निर्भरता व्यवस्थापन आवश्यक छ। प्याकेज प्रबन्धकहरू जस्तै NPM, Maven, PIP or नुगेट सफ्टवेयर निर्भरताहरू निर्दिष्ट गर्न प्रायः प्रयोग गरिन्छ। यी उपकरणहरू सुरक्षालाई होइन, सुविधा र प्रयोगमा सहजतालाई ध्यानमा राखेर डिजाइन गरिएका थिए।

समस्या

समस्या यो हो कि विकासकर्ताहरूको लागि लचिलोपन र प्रयोगको सहजताले खराब मान्छेहरूलाई बोलाउँछ, जसले सफ्टवेयर निर्भरताहरूलाई आफ्नो व्यवसायको लागि अप्रतिरोध्य आकर्षक ठान्छन्। परिणाम: खराब अभिनेताहरूले यहाँ देखाइएका सबै सम्भावित आक्रमण मार्गहरू पछ्याए। स्रोत: "ब्याकस्ट्याबरको चक्कु संग्रह: खुला स्रोत सफ्टवेयर आपूर्ति श्रृंखला आक्रमणहरूको समीक्षा"

यस पोस्टमा हामी खुला संस्करण घोषणाहरूको प्रयोगमा ध्यान केन्द्रित गर्नेछौं, यस अर्थमा कि डाउनलोड गरिएको संस्करण निश्चित छैन तर निश्चित दायरामा हुनुपर्छ। निर्माण समयमा, निर्दिष्ट संस्करण दायरासँग उपयुक्त उच्चतम अवस्थित संस्करण प्याकेज प्रबन्धकद्वारा छनोट र डाउनलोड / स्थापना गरिन्छ।

विभिन्न प्याकेज प्रबन्धकहरूको लागि निर्भरता घोषणाहरूमा खुला घोषणाहरू चित्रण गरौं:

• • एनपीएम: package.json

{

 

   ...

   "निर्भरताहरू": {
      ...
      “स्वीकार गर्दछ”: “>=१.३.८”,
      “लोडास”: “~४.१६.०”,
      ...
   },
   ...
}

Accepts प्याकेजको लागि १.३.८ भन्दा कम नभएको सबैभन्दा ठूलो अवस्थित संस्करण स्थापना गरिनेछ, साथै ४.१६.x दायरामा lodash को लागि सबैभन्दा ठूलो 'प्याच' अपडेट पनि स्थापना गरिनेछ।

• • माभेन: pom.xML

...

...

     कमन्स-आईओ
     कमन्स-आईओ
     रिलिज गर्नुहोस्

...

...

commons-io (jar फाइल) को लागि उपलब्ध अन्तिम उपलब्ध रिलीजलाई निर्भरताको रूपमा थपिनेछ।

• • पिप: setup.py

...
सेटअप (
    ...
    install_requires=['खुर्सानी', 'launchpadlib'],
    ...
)
...

यस्ता खुला संस्करण योजनाहरूको राम्रो र नराम्रो पक्ष हुन्छ। राम्रो पक्ष भनेको नयाँ संस्करणहरू सामान्यतया कार्यात्मक र गुणस्तर सुधारहरू, बग समाधानहरू, र सुरक्षा प्याचहरू समावेश गर्दछ, जुन स्वचालित रूपमा अपग्रेड गरिन्छ। कृपया ध्यान दिनुहोस् कि धेरैजसो वास्तविक-विश्व परियोजनाहरूको लागि, समाधानहरू अघिल्लो साना रिलीजहरूमा ब्याकपोर्ट गरिएको छैन, सायद विनाशकारी सुरक्षा कमजोरीहरू बाहेक। खुला संस्करणहरू पुस्तकालयहरूमा प्रयोगको लागि पनि राम्रो छन्, सबै निर्भरताहरू समाधान भएपछि स्थापना गर्न आवश्यक पर्ने संस्करणहरूको संख्या कम गर्न।

तर खुला संस्करण दायराहरूको नराम्रो पक्ष पनि छ। तपाईंलाई निर्माण समयमा कुन संस्करणहरू स्थापना हुनेछन् भन्ने कुरा ठ्याक्कै थाहा हुँदैन, र निर्माणहरू दोहोरिने योग्य हुँदैनन्। र त्यहाँ एक गाढा खुला संस्करणहरूको पक्षमा। यदि कुनै खराब अभिनेताले तपाईंको खुला दायरासँग मिल्दो उच्च संस्करणको साथ सार्वजनिक भण्डारमा खराब कम्पोनेन्ट प्रकाशित गर्न व्यवस्थापन गर्छ भने, तपाईंको अर्को निर्माणमा खराब कम्पोनेन्ट समावेश हुनेछ, सायद स्वचालित रूपमा कार्यान्वयन हुन सक्ने स्थापना स्क्रिप्टहरूमा मालवेयर पनि कार्यान्वयन गर्नेछ। आक्रमण पेलोडलाई अस्पष्ट पार्नु एक कला हो।

यो को रूपमा चिनिन्छ संस्करण पिनिङको अभाव मुद्दा

खराब अभिनेताहरूले सधैं लोकप्रिय खुला-स्रोत प्याकेजहरूको दुर्भावनापूर्ण संस्करणहरू राख्ने प्रयास गरिरहेका हुन्छन्। तिनीहरूले गोप्य चुहावटमा प्याकेज भण्डारहरूको लागि कुञ्जीहरूमा पहुँच प्राप्त गर्न सक्छन्; तिनीहरू प्रायः सामाजिक इन्जिनियरिङ प्रयोग गर्छन् वा स्पष्ट रूपमा उपयोगी रूपमा नेस्टेड दुर्भावनापूर्ण निर्भरता लुकाउँछन्। pull request। केही लेखकहरू आफैंले पनि एक दिन संसार निष्पक्ष छैन भनेर निर्णय गर्छन् र आफ्ना ग्राहकहरूलाई टोक्छन् प्रोटेस्टवेयर आफ्नै प्याकेजहरूमा!

अब कल्पना गर्नुहोस् कि तपाईं एउटा संस्थाको लागि काम गर्दै हुनुहुन्छ जसले आन्तरिक कम्पोनेन्टहरू र खुला स्रोतहरू प्रयोग गर्दछ।
यदि कुनै खराब व्यक्तिलाई यस्ता आन्तरिक कम्पोनेन्टहरूको नाम थाहा छ भने, उसले सार्वजनिक भण्डारमा उही नामको कम्पोनेन्ट प्रकाशित गर्न सक्छ। धेरै प्याकेज प्रबन्धकहरूले पहिले सार्वजनिक कम्पोनेन्टहरू प्राप्त गर्छन्, र यदि संस्करण सही रूपमा छनोट गरिएको छ र तपाईंको घोषित निर्भरतामा संस्करण खुला छ भने, बूम! यो मुद्दाको नाम दिइएको छ। निर्भरता भ्रम.

एउटा उदाहरण देखाउनुहोस्। मानौं हाम्रो NPM परियोजनामा ​​हामीसँग एउटा निजी कम्पोनेन्टमा निर्भरता छ:

• • एनपीएम: package.json

{
  "नाम": "मेरो-परियोजना",

 

  ...
  "निर्भरताहरू": {

    ...
    “मेरो-निजी-डेप”: “>=१.०.०”,

    ...

   }

   ...

}

 

आक्रमणकारीले my-private-dep को उच्च प्रमुख संस्करण (जस्तै 99.0.0) सिर्जना गर्न सक्छ र यसलाई सार्वजनिक npm भण्डारमा प्रकाशित गर्न सक्छ, यसको आफ्नै नक्कली खाताको साथ (आक्रमणकारीले मेरो संस्थासँग केहि गर्न आवश्यक छैन)। NPM प्याकेज प्रबन्धकले दुर्भावनापूर्ण निर्भरता स्थापना गर्नेछ, प्रायः विनाशकारी परिणामहरू सहित।

समाधान

हाम्रो सफ्टवेयर निर्माण प्रक्रियामा यी समस्याहरूबाट बच्नको लागि, हामीले प्रयोग गरिएको प्रविधिमा निर्भर हुने कम्पोनेन्ट संस्करणहरू कसरी घोषणा गर्ने भन्ने बारे कडा मापदण्डहरू पालना गर्नुपर्छ। महत्त्वपूर्ण कुरा यो हो कि प्याकेजको एक विशिष्ट संस्करण, एक पटक भण्डारमा प्रकाशित भएपछि, अपरिवर्तनीय हुनुपर्छ (सुरक्षा कारणहरूले मात्र होइन, आश्रितहरूलाई तोड्नबाट बच्न)।

सामान्य विचार भनेको फिक्स गर्नु हो (पिन) संस्करणहरू, सधैं जाँच गर्दै कि कम्पोनेन्टहरूको निश्चित संस्करणहरू (सबै ट्रान्जिटिभ निर्भरताहरू सहित) मालवेयरबाट मुक्त छन्, र यो सम्भव छ धन्यवाद लकफाइलहरू धेरै प्याकेज प्रबन्धकहरूले प्रस्ताव गर्ने कुरा। विभिन्न प्याकेज प्रबन्धकहरूको लागि संस्करण पिनिङले कसरी काम गर्छ हेरौं। बीचमा एउटा नाजुक व्यापार छ बारम्बार संस्करण अद्यावधिकहरू ज्ञात कमजोरीहरू समाधान गर्न र संस्करण पिनिङ गैर-निर्धारित निर्माणहरू र सम्भावित आपूर्ति श्रृंखला आक्रमणहरूबाट बच्न।

• • एनपीएम:
    npm वा यार्न प्याकेज प्रबन्धकहरूले विभिन्न लकफाइलहरू (क्रमशः npm-shrinkwrap.json / package-lock.json वा yarn.lock) प्रयोग गर्छन् जसले प्रत्यक्ष र अप्रत्यक्ष सबै निर्भरताहरूको लागि निश्चित संस्करणहरू सूचीबद्ध गर्दछ। लकफाइलहरू संस्करण नियन्त्रण अन्तर्गत हुनुपर्छ, अन्यथा अन्य विकासकर्ताहरू / निर्माण नोडहरू फरक संस्करणहरूसँग समाप्त हुन सक्छन्। विकासमा हुँदा तपाईंले निर्भरताहरू अद्यावधिक गर्न आवश्यक नभएसम्म npm स्थापनाबाट बच्नुहोस् (जस्तै सुरक्षा समाधानहरू स्थापना गर्न)। सामान्य रूपमा थप निर्धारणात्मक npm ci (क्लिन इन्स्टल) प्रयोग गर्नुहोस्, त्यसैले प्याकेज प्रबन्धकले लकफाइल प्रयोग गर्नेछ वा यदि कुनै लकफाइल छैन भने त्रुटिको साथ समाप्त गर्नेछ, वा यो package.json सँग मेल खाँदैन। यदि सूचीबद्ध संस्करणहरू मालवेयरको लागि जाँच गरिएको थियो भने, लकफाइलले निर्माण समयमा केहि पनि नराम्रो हुने छैन भनेर सुनिश्चित गर्दछ।

    आन्तरिक कम्पोनेन्टहरूको लागि, यो सिर्जना गर्न सिफारिस गरिन्छ NPM स्कोप संस्थाद्वारा व्यवस्थित (जस्तै @myorg), र त्यो स्कोपलाई निर्भरतामा प्रयोग गर्नुहोस् (जस्तै @myorg/my-private-dep), जसमा निजी दृश्यता मात्र हुन सक्छ। यसले ब्लक गर्छ निर्भरता भ्रम आक्रमणहरू, किनकि लेखन पहुँच भएको संस्थाको सदस्यले मात्र यस्तो दायरा अन्तर्गत प्याकेजहरू प्रकाशित गर्न सक्छ।

• • Maven:
    Maven / Gradle सँग लकफाइलहरू छैनन् (तर हेर्नुहोस् यो स्ट्याकओभरफ्लो लेख).

    अन्य पारिस्थितिक प्रणालीहरूमा जत्तिकै Maven/Gradle मा संस्करण दायराहरू प्रयोग गरिँदैन। केवल बेवास्ता गर्नुहोस् संस्करण दायराहरू र पछिल्लो वा रिलीज मेटा-संस्करणहरू। अप्रत्यक्ष संस्करणहरू पनि जाँच गर्नुपर्छ। संस्करणहरू Maven Plugin संस्करण नियन्त्रणको लागि एक राम्रो उपकरण हो।

    कृपया ध्यान दिनुहोस् कि माभेनसँग सधैं संगठन क्षेत्रको अवधारणा थियो (निर्भरताको समूहआईडी भाग), र निर्भरता भ्रम त्यो पारिस्थितिक प्रणालीको लागि कुनै समस्या जस्तो देखिँदैन।

• • पिप:
    पाइथनमा लकफाइलहरू ह्यान्डल गर्न विभिन्न उपकरणहरू छन्:

    - पिपेनभ, जसले Pipfile.lock लकफाइल उत्पन्न गर्छ।
    - कविता, जसले poetry.lock उत्पन्न गर्छ।
    - पिप फ्रिज, कमाण्ड जसले requirements.txt उत्पन्न गर्छ जसले लकफाइलको रूपमा काम गर्छ। सबै निर्भरताहरूले == अपरेटरसँग निश्चित संस्करणहरू प्रयोग गर्छन् कि गर्दैनन् जाँच गर्नुहोस्। त्यसपछि pip install -r requirements.txt ले निश्चित निर्भरताहरू प्रयोग गर्दछ।

माथिका लकफाइलहरू संस्करण नियन्त्रण अन्तर्गत हुनुपर्छ, र छनौट गरिएको बिल्ड कमाण्डले लकफाइल प्रयोग गर्नुपर्छ भन्ने कुरा सम्झाउनुहोस्।

pip (PyPI) सँग प्रयोग हुने सामान्य प्याकेज भण्डारमा नामकरण स्कोप हुँदैन, र यो निर्भरता भ्रम आक्रमणहरूको लागि कमजोर हुन्छ। पाइथन इकोसिस्टममा निर्भरता भ्रमबाट बच्ने सजिलो छैन, र केही लेखकहरूले PyPI बाट प्राप्त सार्वजनिक निर्भरताहरूको लागि प्रोक्सीको रूपमा काम गर्न आन्तरिक भण्डार प्रयोग गर्न सिफारिस गर्छन्, तर आन्तरिक भण्डारबाट पहिले निजी निर्भरताहरू लिन्छन् (-index-url ले PyPI होइन, आन्तरिक भण्डारमा औंल्याउनुपर्छ, र –extra-index- url हटाउनुपर्छ)।

केही वास्तविक आक्रमणहरू

गेटकुकीज आक्रमण: अभिनेता dustin87 ले लोकप्रिय npm mailparser प्याकेजमा RCE ब्याकडोर (gCOMMANDhDATAi) भएको दुर्भावनापूर्ण प्याकेजमा अप्रत्यक्ष निर्भरता थप्यो:

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

हटाइए पनि (कुनै समीक्षक छैनन्!), मेलपार्सरले अझै पनि लगभग ६४,००० साप्ताहिक डाउनलोडहरू प्राप्त गर्यो। यो लगभग छुटेको आक्रमणको मामला थियो, किनकि RCE वास्तवमा प्रयोग गरिएको थिएन।cised।

NPM प्रकाशित भयो यो पोष्ट गेटकुकीज आक्रमणको बारेमा विवरणहरू सहित।

निर्भरता भ्रम:

एलेक्स बिर्सनले २०२१ मा निर्भरता भ्रमको समस्या पत्ता लगाए र "शीर्षकको पोस्ट प्रकाशित गरे।मैले एप्पल, माइक्रोसफ्ट र दर्जनौं अन्य कम्पनीहरूमा कसरी ह्याक गरें"।

याद गर्नुहोस् कि npm को लागि @myorg जस्तो संगठन स्कोप आरक्षित हुनुपर्छ, र स्कोप प्रयोग गर्न आन्तरिक प्याकेजहरू परिमार्जन गर्नुपर्छ।

pip को साथ, सामान्य सार्वजनिक रजिस्ट्री PyPI मा स्कोप/नेमस्पेस हुँदैन। प्रत्येक निजी प्याकेजमा आन्तरिक प्याकेजको नाम जस्तै सार्वजनिक प्याकेज स्क्वाट हुन सक्छ, तर खाली छ, र प्रयोग गर्दा त्रुटि उत्पन्न हुन सक्छ, त्यसैले यदि यो गल्तिले प्राप्त भयो भने यसलाई पहिचान गर्न सकिन्छ।

नोड-आईपीसी:

रूस-युक्रेन युद्ध सुरु हुँदा प्याकेज मालिकले रूसी र बेलारूसी होस्टहरूमा स्थापना गर्दा अनियमित फाइलहरू हटाउनको लागि दुर्भावनापूर्ण कोड इन्जेक्ट गरे। ssl-geospec.js फाइलले यस्तो भौगोलिक भिन्नता गरिरहेको थियो:

रोचक कुरा के छ भने, अन्य प्याकेजहरूले नोड-आईपीसी निर्भरताको लागि खुला संस्करणहरू प्रयोग गर्थे, जस्तै लोकप्रिय Vue.js फ्रेमवर्क, र यसको मर्मतकर्ताहरूले प्राप्त गरे तत्काल अपील सुरक्षित संस्करणमा नोड-आईपीसी निर्भरता पिन गर्न।

यो पोस्टमा थप विवरणहरू छन्। यस तोडफोडमा, जुन अन्य भन्दा एक कदम अगाडि जान्छ प्रोटेस्टवेयर समस्याहरू।

सार संक्षेप

खुला संस्करणहरू हुनुपर्छ कहिल्यै समेकित सफ्टवेयर परियोजनाहरूमा प्रयोग गर्न सकिन्छ। तिनीहरूले निर्माणहरूलाई पुनरुत्पादन गर्न नसकिने बनाउँछन्, र आक्रमणकारीहरूले तिनीहरूलाई शोषण गर्न सक्छन् र माथि उल्लेखित निर्भरता भ्रम जस्तै निर्भरता रूखहरूमा आक्रमणहरू मार्फत मालवेयर इन्जेक्ट गर्न व्यवस्थापन गर्न सक्छन्।

गलत कन्फिगरेसनहरू जस्तै खुला संस्करणहरू, संस्करण पिनिङको अभाव, वा अनस्कोप गरिएको आन्तरिक कम्पोनेन्टहरू बेवास्ता गर्नुपर्छ। पहिलो कुरा भनेको त्यस्ता समस्याहरू पत्ता लगाउनु हो, सायद तिनीहरू फेला पर्दा निर्माणलाई अवरुद्ध गर्नु पनि हो, र कार्यको लागि मानकीकृत प्रोटोकल बनाउनु हो।

निर्भरताहरूमा त्रुटिहरू र गलत कन्फिगरेसनहरूको स्वचालित पहिचान, विशिष्ट आपूर्ति-श्रृंखला आक्रमणहरूको लागि कमजोर हुन सक्ने शंकास्पद निर्भरताहरू रिपोर्ट गर्दै जस्तै निर्भरता भ्रम, सबै कार्ययोग्य समाधान उपकरणहरू सहित, को मुख्य लक्ष्यहरू मध्ये एक हो Xygeni प्लेटफर्म.