កង្វះនៃការភ្ជាប់កំណែ និងការភាន់ច្រឡំនៃការពឹងផ្អែក

នៅក្នុងការអភិវឌ្ឍកម្មវិធី យើងពឹងផ្អែកលើសមាសធាតុ ឬវត្ថុបុរាណទាំងផ្ទាល់ខ្លួន និងភាគីទីបី។ ការគ្រប់គ្រងការពឹងផ្អែកដែលអាចបត់បែនបានគឺមានសារៈសំខាន់សម្រាប់កម្មវិធីទំនើប។ កម្មវិធីគ្រប់គ្រងកញ្ចប់ដូចជា NPM, Maven, PIP or នូហ្គេត ជារឿយៗត្រូវបានប្រើដើម្បីបញ្ជាក់ពីភាពអាស្រ័យរបស់កម្មវិធី។ ឧបករណ៍ទាំងនេះត្រូវបានរចនាឡើងដោយគិតគូរពីភាពងាយស្រួល និងភាពងាយស្រួលនៃការប្រើប្រាស់ មិនមែនសុវត្ថិភាពទេ។

បញ្ហា

បញ្ហាគឺថា ភាពបត់បែន និងភាពងាយស្រួលនៃការប្រើប្រាស់សម្រាប់អ្នកអភិវឌ្ឍន៍ ហៅមនុស្សអាក្រក់ ដែលមើលឃើញថា ការពឹងផ្អែកនៃកម្មវិធី គឺជាមន្តស្នេហ៍ដែលមិនអាចទប់ទល់បានសម្រាប់អាជីវកម្មរបស់ពួកគេ។ លទ្ធផល៖ ជនអាក្រក់បានដើរតាមមាគ៌ាវាយប្រហារដែលអាចធ្វើទៅបានទាំងអស់ដែលបង្ហាញនៅទីនេះ។ ប្រភព៖ “Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks”

នៅក្នុង​អត្ថបទ​នេះ យើង​នឹង​ផ្តត់​សំខាន់​លើ​ការប្រើប្រាស់​ការប្រកាស​កំណែ​បើកចំហ ក្នុងន័យថា កំណែ​ដែល​បាន​ទាញយក​មិន​ត្រូវ​បាន​ជួសជុល​ទេ ប៉ុន្តែ​ត្រូវតែ​ជា​របស់​ជួរ​ជាក់លាក់​មួយ។ នៅពេល​បង្កើត កំណែ​ដែល​មាន​ស្រាប់​ខ្ពស់បំផុត​ដែល​ឆបគ្នា​ជាមួយ​ជួរ​កំណែ​ដែល​បាន​បញ្ជាក់​ត្រូវ​បាន​ជ្រើសរើស និង​ទាញយក/ដំឡើង​ដោយ​កម្មវិធី​គ្រប់គ្រង​កញ្ចប់។

ចូរយើងបង្ហាញការប្រកាសបើកចំហនៅក្នុងសេចក្តីប្រកាស dependencies សម្រាប់កម្មវិធីគ្រប់គ្រងកញ្ចប់ផ្សេងៗគ្នា៖

• • NPM៖ កញ្ចប់

{

 

   ...

   "ភាពអាស្រ័យ": {
      ...
      "ទទួលយក": ">=1.3.8",
      “ឡូដាស”: “~៤.១៦.០”,
      ...
   },
   ...
}

កំណែ​ដែល​មាន​ស្រាប់​ធំ​បំផុត​ដែល​មិន​ទាប​ជាង 1.3.8 សម្រាប់​កញ្ចប់​ដែល​ទទួល​យក​នឹង​ត្រូវ​បាន​ដំឡើង ក៏ដូចជា​ការ​អាប់ដេត 'បំណះ' ធំ​បំផុត​សម្រាប់ lodash ក្នុង​ជួរ 4.16.x។

• • ម៉ាវេន៖ pom.xml

...

...

     commons-io
     commons-io
     ចេញផ្សាយ

...

...

ការចេញផ្សាយចុងក្រោយដែលមានសម្រាប់ commons-io (ឯកសារ jar) នឹងត្រូវបានបន្ថែមជាការពឹងផ្អែក។

• • ភីភី៖ setup.py

...
រៀបចំ (
    ...
    install_requires=['peppercorn', 'launchpadlib'],
    ...
)
...

គ្រោងការណ៍កំណែបើកចំហបែបនេះមានទាំងផ្នែកល្អ និងផ្នែកអាក្រក់។ ចំណុចល្អគឺថាកំណែថ្មីៗជាងនេះ ជាធម្មតា មានការកែលម្អមុខងារ និងគុណភាព ការជួសជុលកំហុស និងបំណះសុវត្ថិភាព ដែលត្រូវបានធ្វើឱ្យប្រសើរឡើងដោយស្វ័យប្រវត្តិ។ សូមចំណាំថា សម្រាប់គម្រោងភាគច្រើនក្នុងពិភពពិត ការជួសជុលមិនត្រូវបានផ្ទេរទៅការចេញផ្សាយតូចតាចមុនៗទេ លើកលែងតែភាពងាយរងគ្រោះផ្នែកសុវត្ថិភាពដ៏មហន្តរាយ។ កំណែបើកចំហក៏ល្អសម្រាប់ប្រើប្រាស់ក្នុងបណ្ណាល័យផងដែរ ដើម្បីកាត់បន្ថយចំនួនកំណែដែលត្រូវដំឡើងនៅពេលដែលការពឹងផ្អែកទាំងអស់ត្រូវបានដោះស្រាយ។

ប៉ុន្តែជួរកំណែបើកចំហមានផ្នែកអាក្រក់។ អ្នកមិនដឹងច្បាស់ថាកំណែណាខ្លះនឹងត្រូវបានដំឡើងនៅពេលបង្កើតនោះទេ ហើយការបង្កើតមិនអាចធ្វើម្តងទៀតបានទេ។ ហើយក៏មានផងដែរ ងងឹត ចូលទៅខាងកំណែបើកចំហ។ ប្រសិនបើជនខិលខូចម្នាក់អាចបោះពុម្ពផ្សាយសមាសធាតុព្យាបាទនៅក្នុងឃ្លាំងសាធារណៈជាមួយនឹងកំណែខ្ពស់ដែលត្រូវគ្នានឹងជួរបើកចំហរបស់អ្នក ការបង្កើតបន្ទាប់របស់អ្នកនឹងរួមបញ្ចូលសមាសធាតុព្យាបាទ ប្រហែលជាថែមទាំងប្រតិបត្តិមេរោគនៅក្នុងស្គ្រីបដំឡើងដែលអាចត្រូវបានប្រតិបត្តិដោយស្វ័យប្រវត្តិ។ ការបិទបាំងបន្ទុកវាយប្រហារគឺជាសិល្បៈមួយប្រភេទ។

នេះត្រូវបានគេស្គាល់ថាជា កង្វះនៃការភ្ជាប់កំណែ កិច្ចការ។

ជនខិលខូចតែងតែព្យាយាមដាក់កំណែព្យាបាទនៃកញ្ចប់ប្រភពបើកចំហដ៏ពេញនិយម។ ពួកគេអាចទទួលបានសិទ្ធិចូលប្រើសោសម្រាប់ឃ្លាំងកញ្ចប់នៅក្នុងការលេចធ្លាយសម្ងាត់។ ពួកគេជារឿយៗប្រើវិស្វកម្មសង្គម ឬលាក់ការពឹងផ្អែកព្យាបាទដែលដាក់បញ្ចូលគ្នានៅក្នុងអ្វីដែលហាក់ដូចជាមានប្រយោជន៍។ pull requestសូម្បីតែអ្នកនិពន្ធមួយចំនួនតូចក៏សម្រេចចិត្តថាពិភពលោកនេះមិនយុត្តិធម៌ ហើយបានខាំអតិថិជនរបស់ពួកគេដោយកំហឹងនៅថ្ងៃណាមួយ ឧបករណ៍តវ៉ា នៅក្នុងកញ្ចប់ផ្ទាល់ខ្លួនរបស់ពួកគេ!

ឥឡូវស្រមៃថាអ្នកកំពុងធ្វើការឱ្យអង្គការមួយដែលប្រើប្រាស់សមាសធាតុផ្ទៃក្នុង បូករួមទាំងសមាសធាតុប្រភពបើកចំហ។
ប្រសិនបើអ្នកប្រព្រឹត្តិខុសស្គាល់ឈ្មោះនៃសមាសភាគខាងក្នុងបែបនេះ គាត់/នាងអាចគ្រប់គ្រងការបោះពុម្ពផ្សាយសមាសភាគដែលមានឈ្មោះដូចគ្នានៅក្នុងឃ្លាំងសាធារណៈ។ កម្មវិធីគ្រប់គ្រងកញ្ចប់ជាច្រើនទទួលបានសមាសភាគសាធារណៈជាមុនសិន ហើយប្រសិនបើកំណែត្រូវបានជ្រើសរើសយ៉ាងត្រឹមត្រូវ ហើយកំណែនៅក្នុងការពឹងផ្អែកដែលបានប្រកាសរបស់អ្នកគឺបើកចំហ នោះអ្នកនឹងទទួលបានជោគជ័យ! បញ្ហានេះត្រូវបានដាក់ឈ្មោះថា ភាពច្របូកច្របល់នៃការពឹងផ្អែក.

ចូរយើងបង្ហាញឧទាហរណ៍មួយ។ ឧបមាថានៅក្នុងគម្រោង NPM របស់យើង យើងមានការពឹងផ្អែកលើសមាសភាគឯកជនមួយ៖

• • NPM៖ កញ្ចប់

{
  "ឈ្មោះ": "គម្រោងរបស់ខ្ញុំ",

 

  ...
  "ភាពអាស្រ័យ": {

    ...
    "my-private-dep": ">=1.0.0",

    ...

   }

   ...

}

 

អ្នកវាយប្រហារអាចបង្កើតកំណែមេខ្ពស់នៃ my-private-dep (ដូចជា 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) ដែលអាចមានភាពមើលឃើញឯកជនតែប៉ុណ្ណោះ។ នេះរារាំង ភាពច្របូកច្របល់នៃការពឹងផ្អែក ការវាយប្រហារ ព្រោះមានតែសមាជិកនៃអង្គការដែលមានសិទ្ធិចូលសរសេរប៉ុណ្ណោះដែលអាចបោះពុម្ពផ្សាយកញ្ចប់ក្រោមវិសាលភាពបែបនេះ។

• • Maven:
    Maven / Gradle មិនមានឯកសារចាក់សោទេ (ប៉ុន្តែសូមមើល អត្ថបទ StackOverflow នេះ).

    ជួរ​កំណែ​មិន​ត្រូវ​បាន​ប្រើ​ជាមួយ Maven/Gradle ដូច​ជាមួយ​ប្រព័ន្ធ​អេកូឡូស៊ី​ផ្សេង​ទៀត​ទេ។ គ្រាន់តែ​ជៀសវាង ជួរកំណែ និង​កំណែ​មេតា​ចុងក្រោយ​បំផុត ឬ​កំណែ​ចេញផ្សាយ។ កំណែ​ប្រយោល​ក៏​គួរ​ត្រូវ​បាន​ពិនិត្យ​ផងដែរ។ កំណែកម្មវិធីជំនួយ Maven គឺជាឧបករណ៍ដ៏ល្អសម្រាប់ការគ្រប់គ្រងកំណែ។

    សូមចំណាំថា Maven តែងតែមានគោលគំនិតនៃវិសាលភាពនៃអង្គការ (ផ្នែក groupId នៃភាពអាស្រ័យ) ហើយការភាន់ច្រឡំនៃភាពអាស្រ័យហាក់ដូចជាមិនមែនជាបញ្ហាទាល់តែសោះសម្រាប់ប្រព័ន្ធអេកូឡូស៊ីនោះ។

• • pip:
    នៅក្នុង Python មានឧបករណ៍ផ្សេងៗគ្នាសម្រាប់ដោះស្រាយជាមួយ lockfiles៖

    - pipenvដែលបង្កើតឯកសារចាក់សោ Pipfile.lock។
    - កំណាព្យដែលបង្កើត poetry.lock។
    - បង្កកបំពង់ពាក្យបញ្ជាដែលបង្កើត requirements.txt ដែលដើរតួជាឯកសារចាក់សោ។ ពិនិត្យមើលថាតើ dependencies ទាំងអស់ប្រើកំណែថេរជាមួយប្រតិបត្តិករ == ដែរឬទេ។ បន្ទាប់មក pip install -r requirements.txt ប្រើ fixed dependencies។

សូមរំលឹកថា ឯកសារចាក់សោខាងលើគួរតែស្ថិតនៅក្រោមការគ្រប់គ្រងកំណែ ហើយពាក្យបញ្ជា build ដែលបានជ្រើសរើសគួរតែប្រើឯកសារចាក់សោ។

ឃ្លាំងកញ្ចប់ធម្មតាដែលប្រើជាមួយ pip (PyPI) មិនមានវិសាលភាពដាក់ឈ្មោះទេ ហើយវាងាយរងគ្រោះដោយការវាយប្រហារច្រឡំការពឹងផ្អែក។ ការជៀសវាងការភាន់ច្រឡំនៃការពឹងផ្អែកនៅក្នុងប្រព័ន្ធអេកូឡូស៊ី python មិនមែនជារឿងងាយស្រួលនោះទេ ហើយអ្នកនិពន្ធមួយចំនួនណែនាំឱ្យប្រើឃ្លាំងផ្ទុកខាងក្នុងដើម្បីដើរតួជាប្រូកស៊ីសម្រាប់ការពឹងផ្អែកសាធារណៈដែលទាញយកពី PyPI ប៉ុន្តែត្រូវយកការពឹងផ្អែកឯកជនពីឃ្លាំងផ្ទុកខាងក្នុងជាមុនសិន (-index-url គួរតែចង្អុលទៅឃ្លាំងផ្ទុកខាងក្នុង មិនមែន PyPI ទេ ហើយ –extra-index-url គួរតែត្រូវបានដកចេញ)។

ការវាយប្រហារពិតប្រាកដមួយចំនួន

ការវាយប្រហារ Getcookiesតារាសម្តែង 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) => {})

ទោះបីជាត្រូវបានបដិសេធ (គ្មានអ្នកពិនិត្យ!) ក៏ដោយ mailparser នៅតែទទួលបានការទាញយកប្រហែល 64,000 ដងក្នុងមួយសប្តាហ៍។ នេះគឺជាករណីនៃការវាយប្រហារដែលស្ទើរតែខកខាន ព្រោះ RCE មិនត្រូវបានអនុវត្តជាក់ស្តែងទេ។cised ។

បានបោះពុម្ពផ្សាយ NPM ការប្រកាសនេះ ជាមួយនឹងព័ត៌មានលម្អិតអំពីការវាយប្រហារ getcookies។

ភាពច្របូកច្របល់នៃការពឹងផ្អែក:

លោក Alex Birsan បានរកឃើញនៅឆ្នាំ 2021 អំពីបញ្ហាភាន់ច្រឡំនៃការពឹងផ្អែក ហើយបានបោះពុម្ពផ្សាយអត្ថបទមួយដែលមានចំណងជើងថា "របៀបដែលខ្ញុំបានលួចចូល Apple, Microsoft និងក្រុមហ៊ុនរាប់សិបផ្សេងទៀត"។

ចងចាំថាសម្រាប់ npm វិសាលភាពរបស់អង្គការដូចជា @myorg គួរតែត្រូវបានបម្រុងទុក ហើយកញ្ចប់ខាងក្នុងគួរតែត្រូវបានកែប្រែដើម្បីប្រើវិសាលភាព។

ជាមួយ pip បញ្ជីឈ្មោះសាធារណៈទូទៅ PyPI មិនមាន scopes/namespaces ទេ។ កញ្ចប់ឯកជននីមួយៗអាចមានកញ្ចប់សាធារណៈ squat ដែលមានឈ្មោះដូចគ្នានឹងកញ្ចប់ខាងក្នុង ប៉ុន្តែទទេ ហើយប្រហែលជាបង្កើតកំហុសនៅពេលប្រើ ដូច្នេះវាអាចត្រូវបានកំណត់អត្តសញ្ញាណប្រសិនបើវាត្រូវបានទាញយកដោយចៃដន្យ។

Node-ipc:

ម្ចាស់កញ្ចប់ នៅពេលដែលសង្គ្រាមរុស្ស៊ី-អ៊ុយក្រែនបានចាប់ផ្តើម បានចាក់បញ្ចូលកូដព្យាបាទសម្រាប់លុបឯកសារចៃដន្យ នៅពេលដំឡើងនៅលើម៉ាស៊ីនមេរុស្ស៊ី និងបេឡារុស្ស។ ឯកសារ ssl-geospec.js កំពុងធ្វើការបែងចែកភូមិសាស្ត្របែបនេះ៖

គួរឱ្យចាប់អារម្មណ៍គ្រប់គ្រាន់ កញ្ចប់ផ្សេងទៀតបានប្រើកំណែបើកចំហសម្រាប់ការពឹងផ្អែក node-ipc ដូចជាក្របខ័ណ្ឌ Vue.js ដ៏ពេញនិយម ហើយអ្នកថែទាំរបស់វាបានទទួល ការអំពាវនាវបន្ទាន់ ដើម្បីភ្ជាប់ភាពអាស្រ័យ node-ipc លើកំណែដែលមានសុវត្ថិភាព។

នេះ ប្រកាសមានព័ត៌មានលម្អិតបន្ថែម លើការបំផ្លិចបំផ្លាញនេះ ដែលឈានមួយជំហានទៀតពីសកម្មភាពផ្សេងទៀត ប្រូតេស្តវែរ បញ្ហា។

សុន្ទរកថាបញ្ចប់

កំណែបើកចំហគួរតែ មិនដែល ត្រូវបានប្រើនៅក្នុងគម្រោងកម្មវិធីរួមបញ្ចូលគ្នា។ ពួកវាធ្វើឱ្យការបង្កើតមិនអាចបង្កើតឡើងវិញបាន ហើយអ្នកវាយប្រហារអាចកេងប្រវ័ញ្ចពួកវា និងគ្រប់គ្រងការចាក់មេរោគតាមរយៈការវាយប្រហារទៅលើដើមឈើអាស្រ័យដូចជាការភាន់ច្រឡំនៃការពឹងផ្អែកដែលបានរៀបរាប់ខាងលើ។

ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវដូចជា កំណែបើកចំហ កង្វះនៃការភ្ជាប់កំណែ ឬសមាសធាតុខាងក្នុងដែលមិនមានវិសាលភាព គួរតែត្រូវបានជៀសវាង។ រឿងដំបូងគឺត្រូវរកឃើញបញ្ហាបែបនេះ ប្រហែលជាថែមទាំងរារាំងការសាងសង់នៅពេលដែលពួកវាត្រូវបានរកឃើញ ហើយបានធ្វើពិធីការសម្រាប់សកម្មភាពឱ្យមានស្តង់ដារ។

ការរកឃើញដោយស្វ័យប្រវត្តិនៃចំណុចខ្វះខាត និងការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៅក្នុង dependencies ដោយរាយការណ៍អំពី dependencies ដែលគួរឱ្យសង្ស័យ ដែលអាចងាយរងគ្រោះដោយការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់ជាក់លាក់ដូចជា ភាពច្របូកច្របល់នៃការពឹងផ្អែកទាំងអស់ជាមួយនឹងឧបករណ៍ជួសជុលដែលអាចអនុវត្តបាន គឺជាគោលដៅចម្បងមួយរបស់ វេទិកា Xygeni.