🥇 សវនកម្មសុវត្ថិភាពនៃវេទិកាពពក MCS

SkyShip ពេលព្រលប់ ដោយ SeeerLight

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

អត្ថបទនេះគឺអំពីទស្សនៈដ៏ត្រង់បំផុតរបស់អ្នកជំនាញខាងក្រៅ ដែលបានជួយក្រុម Mail.ru Cloud Solutions (MCS) សាកល្បងសេវាកម្មពពក និងអំពីអ្វីដែលពួកគេបានរកឃើញ។ ក្នុងនាមជា "កម្លាំងខាងក្រៅ" MCS បានជ្រើសរើសក្រុមហ៊ុន Digital Security ដែលត្រូវបានគេស្គាល់ថាមានជំនាញខ្ពស់នៅក្នុងរង្វង់សុវត្ថិភាពព័ត៌មាន។ ហើយនៅក្នុងអត្ថបទនេះ យើងនឹងវិភាគភាពងាយរងគ្រោះដែលគួរឱ្យចាប់អារម្មណ៍មួយចំនួនដែលបានរកឃើញជាផ្នែកមួយនៃសវនកម្មខាងក្រៅ - ដូច្នេះអ្នកជៀសវាងការតុងរួចដូចគ្នានៅពេលអ្នកបង្កើតសេវាកម្មពពកផ្ទាល់ខ្លួនរបស់អ្នក។

продуктаОписание

Mail.ru Cloud Solutions (MCS) គឺជាវេទិកាសម្រាប់កសាងហេដ្ឋារចនាសម្ព័ន្ធនិម្មិតនៅក្នុងពពក។ វារួមបញ្ចូល IaaS, PaaS និងទីផ្សារនៃរូបភាពកម្មវិធីដែលត្រៀមរួចជាស្រេចសម្រាប់អ្នកអភិវឌ្ឍន៍។ ដោយគិតពីស្ថាបត្យកម្ម MCS វាចាំបាច់ត្រូវពិនិត្យមើលសុវត្ថិភាពនៃផលិតផលក្នុងផ្នែកខាងក្រោម៖

ការការពារហេដ្ឋារចនាសម្ព័ន្ធនៃបរិស្ថាននិម្មិត៖ ការត្រួតពិនិត្យខ្ពស់ ការកំណត់ផ្លូវ ជញ្ជាំងភ្លើង។
ការការពារហេដ្ឋារចនាសម្ព័ន្ធនិម្មិតរបស់អតិថិជន៖ ភាពឯកោពីគ្នាទៅវិញទៅមក រួមទាំងបណ្តាញ បណ្តាញឯកជននៅក្នុង SDN;
OpenStack និងសមាសធាតុបើកចំហរបស់វា;
S3 នៃការរចនាផ្ទាល់ខ្លួនរបស់យើង;
IAM: គម្រោងអ្នកជួលច្រើនជាមួយគំរូមួយ;
ចក្ខុវិស័យ (ចក្ខុវិស័យកុំព្យូទ័រ): APIs និងភាពងាយរងគ្រោះនៅពេលធ្វើការជាមួយរូបភាព;
ចំណុចប្រទាក់គេហទំព័រ និងការវាយប្រហារតាមគេហទំព័របុរាណ;
ភាពងាយរងគ្រោះនៃសមាសធាតុ PaaS;
API នៃសមាសធាតុទាំងអស់។

ប្រហែលជាអ្វីដែលសំខាន់សម្រាប់ប្រវត្តិសាស្ត្របន្ថែមទៀត។

តើការងារប្រភេទណាដែលត្រូវបានអនុវត្តហើយហេតុអ្វីបានជាវាត្រូវការ?

សវនកម្មសុវត្ថិភាពមានគោលបំណងកំណត់អត្តសញ្ញាណភាពងាយរងគ្រោះ និងកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធ ដែលអាចនាំឱ្យមានការលេចធ្លាយទិន្នន័យផ្ទាល់ខ្លួន ការកែប្រែព័ត៌មានរសើប ឬការរំខានដល់ភាពអាចរកបាននៃសេវាកម្ម។

ក្នុងអំឡុងពេលការងារដែលមានរយៈពេលជាមធ្យម 1-2 ខែ អ្នកសវនករធ្វើឡើងវិញនូវសកម្មភាពរបស់អ្នកវាយប្រហារដែលមានសក្តានុពល និងស្វែងរកភាពងាយរងគ្រោះនៅក្នុងផ្នែកម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនបម្រើនៃសេវាកម្មដែលបានជ្រើសរើស។ នៅក្នុងបរិបទនៃសវនកម្មនៃវេទិកាពពក MCS គោលដៅខាងក្រោមត្រូវបានកំណត់អត្តសញ្ញាណ៖

ការវិភាគការផ្ទៀងផ្ទាត់នៅក្នុងសេវាកម្ម។ ភាពងាយរងគ្រោះនៅក្នុងសមាសធាតុនេះនឹងជួយឱ្យចូលទៅក្នុងគណនីរបស់អ្នកដទៃភ្លាមៗ។
សិក្សាគំរូ និងការគ្រប់គ្រងការចូលប្រើរវាងគណនីផ្សេងៗ។ សម្រាប់អ្នកវាយប្រហារ សមត្ថភាពក្នុងការចូលប្រើម៉ាស៊ីននិម្មិតរបស់នរណាម្នាក់គឺជាគោលដៅដែលចង់បាន។
ភាពងាយរងគ្រោះរបស់ភាគីអតិថិជន។ XSS/CSRF/CRLF/ល។ តើវាអាចវាយប្រហារអ្នកប្រើផ្សេងទៀតតាមរយៈតំណព្យាបាទឬ?
ភាពងាយរងគ្រោះផ្នែកខាងម៉ាស៊ីនមេ៖ RCE និងការចាក់បញ្ចូលគ្រប់ប្រភេទ (SQL/XXE/SSRF និងផ្សេងៗទៀត)។ ភាពងាយរងគ្រោះរបស់ម៉ាស៊ីនមេ ជាទូទៅពិបាកស្វែងរក ប៉ុន្តែវានាំទៅដល់ការសម្របសម្រួលរបស់អ្នកប្រើប្រាស់ជាច្រើនក្នុងពេលតែមួយ។
ការវិភាគលើភាពឯកោផ្នែកអ្នកប្រើប្រាស់នៅកម្រិតបណ្តាញ។ សម្រាប់អ្នកវាយប្រហារ កង្វះភាពឯកោបង្កើនផ្ទៃវាយប្រហារប្រឆាំងនឹងអ្នកប្រើប្រាស់ផ្សេងទៀត។
ការវិភាគតក្កវិជ្ជាអាជីវកម្ម។ តើវាអាចទៅរួចទេក្នុងការបញ្ឆោតអាជីវកម្ម និងបង្កើតម៉ាស៊ីននិម្មិតដោយឥតគិតថ្លៃ?

នៅក្នុងគម្រោងនេះ ការងារត្រូវបានអនុវត្តតាមគំរូ "Grey-box"៖ សវនករបានធ្វើអន្តរកម្មជាមួយសេវាកម្មជាមួយនឹងសិទ្ធិរបស់អ្នកប្រើប្រាស់ធម្មតា ប៉ុន្តែមានផ្នែកខ្លះនៃកូដប្រភពនៃ API និងមានឱកាសដើម្បីបញ្ជាក់ព័ត៌មានលម្អិតជាមួយអ្នកអភិវឌ្ឍន៍។ នេះជាធម្មតាជាការងាយស្រួលបំផុត ហើយក្នុងពេលជាមួយគ្នានោះ គំរូនៃការងារជាក់ស្តែង៖ ព័ត៌មានខាងក្នុងនៅតែអាចប្រមូលបានដោយអ្នកវាយប្រហារ វាគ្រាន់តែជាបញ្ហានៃពេលវេលាប៉ុណ្ណោះ។

ភាពងាយរងគ្រោះត្រូវបានរកឃើញ

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

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

IDOR

ភាពងាយរងគ្រោះ IDOR (Insecure Direct Object Reference) គឺជាភាពងាយរងគ្រោះមួយក្នុងចំណោមភាពងាយរងគ្រោះទូទៅបំផុតនៅក្នុងតក្កវិជ្ជាធុរកិច្ច ដែលអនុញ្ញាតឱ្យវត្ថុមួយឬមួយផ្សេងទៀតទទួលបានសិទ្ធិចូលប្រើវត្ថុដែលការចូលប្រើមិនត្រូវបានអនុញ្ញាតពិតប្រាកដ។ ភាពងាយរងគ្រោះ IDOR បង្កើតលទ្ធភាពនៃការទទួលបានព័ត៌មានអំពីអ្នកប្រើប្រាស់ដែលមានកម្រិតនៃការរិះគន់ផ្សេងៗគ្នា។

ជម្រើសមួយក្នុងចំណោមជម្រើស IDOR គឺដើម្បីអនុវត្តសកម្មភាពជាមួយវត្ថុប្រព័ន្ធ (អ្នកប្រើប្រាស់ គណនីធនាគារ របស់របរនៅក្នុងរទេះទិញទំនិញ) ដោយរៀបចំឧបករណ៍សម្គាល់ការចូលប្រើទៅកាន់វត្ថុទាំងនេះ។ នេះនាំឱ្យមានផលវិបាកដែលមិនអាចទាយទុកជាមុនបាន។ ឧទាហរណ៍ លទ្ធភាពនៃការជំនួសគណនីរបស់អ្នកផ្ញើមូលនិធិ តាមរយៈនោះអ្នកអាចលួចពួកគេពីអ្នកប្រើប្រាស់ផ្សេងទៀត។

ក្នុងករណី MCS អ្នកសវនករទើបតែរកឃើញភាពងាយរងគ្រោះ IDOR ដែលទាក់ទងនឹងអត្តសញ្ញាណមិនមានសុវត្ថិភាព។ នៅក្នុងគណនីផ្ទាល់ខ្លួនរបស់អ្នកប្រើប្រាស់ ឧបករណ៍កំណត់អត្តសញ្ញាណ UUID ត្រូវបានប្រើដើម្បីចូលប្រើវត្ថុណាមួយ ដែលហាក់ដូចជាអ្នកជំនាញផ្នែកសន្តិសុខបាននិយាយថា មានភាពអសន្តិសុខគួរឱ្យចាប់អារម្មណ៍ (នោះគឺត្រូវបានការពារពីការវាយប្រហារដោយកម្លាំងសាហាវ)។ ប៉ុន្តែសម្រាប់អង្គភាពមួយចំនួន វាត្រូវបានគេរកឃើញថា លេខដែលអាចទស្សន៍ទាយបានទៀងទាត់ត្រូវបានប្រើ ដើម្បីទទួលបានព័ត៌មានអំពីអ្នកប្រើប្រាស់កម្មវិធី។ ខ្ញុំគិតថា អ្នកអាចទាយបានថាវាអាចធ្វើទៅបានក្នុងការផ្លាស់ប្តូរលេខសម្គាល់អ្នកប្រើដោយមួយ, ផ្ញើសំណើម្តងទៀតហើយដូច្នេះទទួលបានពត៌មានដោយរំលង ACL (បញ្ជីការត្រួតពិនិត្យការចូលដំណើរការទិន្នន័យសម្រាប់ដំណើរការនិងអ្នកប្រើ) ។

ការក្លែងបន្លំសំណើរផ្នែកខាងម៉ាស៊ីនមេ (SSRF)

រឿងល្អអំពីផលិតផល OpenSource គឺថាពួកគេមានវេទិកាជាច្រើនជាមួយនឹងការពិពណ៌នាបច្ចេកទេសលម្អិតអំពីបញ្ហាដែលកើតឡើង ហើយប្រសិនបើអ្នកមានសំណាង ការពិពណ៌នាអំពីដំណោះស្រាយ។ ប៉ុន្តែកាក់នេះមានផ្នែកត្រឡប់៖ ភាពងាយរងគ្រោះដែលគេស្គាល់ក៏ត្រូវបានពិពណ៌នាលម្អិតផងដែរ។ ឧទាហរណ៍ មានការពិពណ៌នាដ៏អស្ចារ្យអំពីភាពងាយរងគ្រោះនៅលើវេទិកា OpenStack [XSS] и [SSRF]ដែលសម្រាប់ហេតុផលមួយចំនួនគ្មាននរណាម្នាក់ប្រញាប់ក្នុងការជួសជុលទេ។

មុខងារទូទៅនៃកម្មវិធីគឺជាសមត្ថភាពសម្រាប់អ្នកប្រើប្រាស់ក្នុងការផ្ញើតំណទៅកាន់ម៉ាស៊ីនមេ ដែលម៉ាស៊ីនមេចុចលើ (ឧទាហរណ៍ ដើម្បីទាញយករូបភាពពីប្រភពដែលបានបញ្ជាក់)។ ប្រសិនបើឧបករណ៍សុវត្ថិភាពមិនត្រងតំណភ្ជាប់ដោយខ្លួនឯង ឬការឆ្លើយតបដែលបានត្រឡប់ពីម៉ាស៊ីនមេទៅកាន់អ្នកប្រើប្រាស់ មុខងារបែបនេះអាចត្រូវប្រើដោយអ្នកវាយប្រហារយ៉ាងងាយស្រួល។

ភាពងាយរងគ្រោះ SSRF អាចជំរុញយ៉ាងខ្លាំងដល់ការអភិវឌ្ឍន៍នៃការវាយប្រហារ។ អ្នកវាយប្រហារអាចទទួលបាន៖

ការចូលប្រើមានកំណត់ចំពោះបណ្តាញមូលដ្ឋានដែលត្រូវបានវាយប្រហារ ជាឧទាហរណ៍ តាមរយៈផ្នែកបណ្តាញជាក់លាក់ និងការប្រើប្រាស់ពិធីការជាក់លាក់មួយ។
ការចូលដំណើរការពេញលេញទៅកាន់បណ្តាញមូលដ្ឋាន ប្រសិនបើការបន្ទាបពីកម្រិតកម្មវិធីទៅកម្រិតដឹកជញ្ជូនគឺអាចធ្វើទៅបាន ហើយជាលទ្ធផល ការគ្រប់គ្រងការផ្ទុកពេញលេញនៅកម្រិតកម្មវិធី។
ការចូលប្រើដើម្បីអានឯកសារមូលដ្ឋាននៅលើម៉ាស៊ីនមេ (ប្រសិនបើឯកសារ /// គ្រោងការណ៍ត្រូវបានគាំទ្រ);
និងច្រើនទៀត។

ភាពងាយរងគ្រោះ SSRF ត្រូវបានគេស្គាល់ជាយូរមកហើយនៅក្នុង OpenStack ដែលមានលក្ខណៈ "ខ្វាក់" នៅក្នុងធម្មជាតិ៖ នៅពេលអ្នកទាក់ទងទៅម៉ាស៊ីនមេ អ្នកមិនទទួលបានការឆ្លើយតបពីវាទេ ប៉ុន្តែអ្នកទទួលបានប្រភេទផ្សេងគ្នានៃកំហុស/ការពន្យារពេល អាស្រ័យលើលទ្ធផលនៃសំណើ។ . ដោយផ្អែកលើវា អ្នកអាចធ្វើការស្កេនច្រកនៅលើម៉ាស៊ីននៅលើបណ្តាញខាងក្នុង ជាមួយនឹងផលវិបាកដែលកើតឡើងទាំងអស់ដែលមិនគួរត្រូវបានប៉ាន់ស្មាន។ ជាឧទាហរណ៍ ផលិតផលមួយអាចមាន Back-office API ដែលអាចចូលប្រើបានតែពីបណ្តាញសាជីវកម្មប៉ុណ្ណោះ។ ជាមួយនឹងឯកសារ (កុំភ្លេចអំពីខាងក្នុង) អ្នកវាយប្រហារអាចប្រើ SSRF ដើម្បីចូលប្រើវិធីសាស្ត្រខាងក្នុង។ ឧទាហរណ៍ ប្រសិនបើអ្នកអាចទទួលបានបញ្ជីប្រហាក់ប្រហែលនៃ URLs ដែលមានប្រយោជន៍នោះ ដោយប្រើ SSRF អ្នកអាចឆ្លងកាត់ពួកវា ហើយអនុវត្តសំណើ - និយាយដោយទាក់ទងគ្នា ផ្ទេរប្រាក់ពីគណនីទៅគណនី ឬផ្លាស់ប្តូរដែនកំណត់។

នេះមិនមែនជាលើកទីមួយទេ ដែលភាពងាយរងគ្រោះ SSRF ត្រូវបានរកឃើញនៅក្នុង OpenStack ។ កាលពីមុន វាអាចទាញយករូបភាព VM ISO ពីតំណផ្ទាល់ ដែលនាំឱ្យកើតមានផលវិបាកស្រដៀងគ្នានេះផងដែរ។ ឥឡូវនេះមុខងារនេះត្រូវបានដកចេញពី OpenStack ។ ជាក់ស្តែង សហគមន៍បានចាត់ទុកថានេះជាដំណោះស្រាយដ៏សាមញ្ញបំផុត និងគួរឱ្យទុកចិត្តបំផុតចំពោះបញ្ហានេះ។

ហើយនៅក្នុង។ នេះ របាយការណ៍ដែលមានជាសាធារណៈពីសេវា HackerOne (h1) ការកេងប្រវ័ញ្ចនៃ SSRF ដែលលែងពិការភ្នែកជាមួយនឹងសមត្ថភាពក្នុងការអានទិន្នន័យមេតានាំឱ្យមានការចូលប្រើជា Root ទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធ Shopify ទាំងមូល។

នៅក្នុង MCS ភាពងាយរងគ្រោះ SSRF ត្រូវបានរកឃើញនៅក្នុងកន្លែងពីរដែលមានមុខងារស្រដៀងគ្នា ប៉ុន្តែពួកគេស្ទើរតែមិនអាចទាញយកបានដោយសារតែជញ្ជាំងភ្លើង និងការការពារផ្សេងទៀត។ វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត ក្រុមការងារ MCS បានដោះស្រាយបញ្ហានេះ ដោយមិនរង់ចាំសហគមន៍។

XSS ជំនួសឱ្យការផ្ទុកសែល

ទោះបីជាការសិក្សារាប់រយត្រូវបានសរសេរក៏ដោយ ការវាយប្រហារពីមួយឆ្នាំទៅមួយឆ្នាំ XSS (ឆ្លងកាត់គេហទំព័រ) នៅតែជាការវាយប្រហារច្រើនបំផុត ជួបប្រទះញឹកញាប់ ភាពងាយរងគ្រោះនៃគេហទំព័រ (ឬ វាយប្រហារ?) ។

ការបង្ហោះឯកសារគឺជាកន្លែងដែលចូលចិត្តសម្រាប់អ្នកស្រាវជ្រាវផ្នែកសុវត្ថិភាពណាមួយ។ ជារឿយៗវាប្រែថាអ្នកអាចផ្ទុកស្គ្រីបតាមអំពើចិត្ត (asp/jsp/php) និងប្រតិបត្តិពាក្យបញ្ជា OS នៅក្នុងវាក្យស័ព្ទរបស់ pentesters - "load shell" ។ ប៉ុន្តែភាពពេញនិយមនៃភាពងាយរងគ្រោះបែបនេះដំណើរការក្នុងទិសដៅទាំងពីរ៖ ពួកគេត្រូវបានគេចងចាំ ហើយដំណោះស្រាយត្រូវបានបង្កើតឡើងប្រឆាំងនឹងពួកគេ ដូច្នេះថ្មីៗនេះប្រូបាប៊ីលីតេនៃ "ការផ្ទុកសែល" មាននិន្នាការទៅសូន្យ។

ក្រុមវាយប្រហារ (តំណាងដោយ Digital Security) មានសំណាង។ យល់ព្រម នៅក្នុង MCS នៅផ្នែកខាងម៉ាស៊ីនមេ មាតិកានៃឯកសារដែលបានទាញយកត្រូវបានពិនិត្យ មានតែរូបភាពប៉ុណ្ណោះដែលត្រូវបានអនុញ្ញាត។ ប៉ុន្តែ SVG ក៏ជារូបភាពផងដែរ។ តើរូបភាព SVG អាចមានគ្រោះថ្នាក់យ៉ាងដូចម្តេច? ដោយសារតែអ្នកអាចបង្កប់ផ្នែកតូចៗរបស់ JavaScript ទៅក្នុងពួកវា!

វាបានប្រែក្លាយថាឯកសារដែលបានទាញយកមានសម្រាប់អ្នកប្រើប្រាស់ទាំងអស់នៃសេវាកម្ម MCS ដែលមានន័យថាវាអាចធ្វើទៅបានដើម្បីវាយប្រហារអ្នកប្រើប្រាស់ពពកផ្សេងទៀតគឺអ្នកគ្រប់គ្រង។

ឧទាហរណ៍នៃការវាយប្រហារ XSS លើទម្រង់ចូលលួចបន្លំ

ឧទាហរណ៍នៃការវាយប្រហារ XSS៖

ហេតុអ្វីបានជាព្យាយាមលួចវគ្គ (ជាពិសេសចាប់តាំងពីពេលនេះ HTTP-Only cookies មាននៅគ្រប់ទីកន្លែង ការពារពីការលួចដោយប្រើ js scripts) ប្រសិនបើស្គ្រីបដែលបានផ្ទុកអាចចូលប្រើ resource API បានភ្លាមៗ? ក្នុងករណីនេះ payload អាចប្រើសំណើ XHR ដើម្បីផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ ឧទាហរណ៍ បន្ថែមសោ SSH សាធារណៈរបស់អ្នកវាយប្រហារ និងទទួលបានការចូលប្រើ SSH ទៅកាន់ម៉ាស៊ីនមេ។
ប្រសិនបើគោលការណ៍ CSP (គោលការណ៍ការពារមាតិកា) ហាមឃាត់ JavaScript ពីការបញ្ចូល អ្នកវាយប្រហារអាចទទួលបានដោយគ្មានវា។ ដោយប្រើ HTML សុទ្ធ បង្កើតទម្រង់ការចូលក្លែងក្លាយសម្រាប់គេហទំព័រ ហើយលួចពាក្យសម្ងាត់របស់អ្នកគ្រប់គ្រងតាមរយៈការបន្លំកម្រិតខ្ពស់នេះ៖ ទំព័របន្លំសម្រាប់អ្នកប្រើប្រាស់បញ្ចប់នៅ URL តែមួយ ហើយវាកាន់តែពិបាកសម្រាប់អ្នកប្រើប្រាស់ក្នុងការស្វែងរកវា។
ទីបំផុត អ្នកវាយប្រហារអាចរៀបចំបាន។ អតិថិជន DoS - កំណត់ Cookies ធំជាង 4 KB ។ អ្នកប្រើប្រាស់ត្រូវការបើកតំណតែម្តងប៉ុណ្ណោះ ហើយគេហទំព័រទាំងមូលមិនអាចចូលដំណើរការបានរហូតដល់អ្នកប្រើប្រាស់គិតថានឹងសម្អាតកម្មវិធីរុករកតាមអ៊ីនធឺណិតជាពិសេស៖ ក្នុងករណីភាគច្រើន ម៉ាស៊ីនមេគេហទំព័រនឹងបដិសេធមិនទទួលយកម៉ាស៊ីនភ្ញៀវបែបនេះ។

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

នោះគឺជាសេណារីយ៉ូបានប្រែក្លាយដូចខាងក្រោម៖ អ្នកវាយប្រហារបង្កើតច្បាប់ជញ្ជាំងភ្លើងដែលមាន "ផ្ទុក" នៅក្នុងឈ្មោះ អ្នកគ្រប់គ្រងកត់សម្គាល់វាបន្ទាប់ពីមួយរយៈ ហើយចាប់ផ្តើមដំណើរការលុប។ ហើយនេះគឺជាកន្លែងដែល JS ព្យាបាទដំណើរការ។

សម្រាប់អ្នកអភិវឌ្ឍន៍ MCS ដើម្បីការពារប្រឆាំងនឹង XSS នៅក្នុងរូបភាព SVG ដែលបានបង្ហោះ (ប្រសិនបើពួកគេមិនអាចលុបចោលបានទេ) ក្រុមសន្តិសុខឌីជីថលបានណែនាំ៖

ដាក់ឯកសារដែលបានផ្ទុកឡើងដោយអ្នកប្រើប្រាស់នៅលើដែនដាច់ដោយឡែកដែលមិនមានអ្វីដែលត្រូវធ្វើជាមួយ "ខូគី" ។ ស្គ្រីបនឹងត្រូវបានប្រតិបត្តិក្នុងបរិបទនៃដែនផ្សេង ហើយនឹងមិនបង្កការគំរាមកំហែងដល់ MCS ទេ។
នៅក្នុងការឆ្លើយតប HTTP របស់ម៉ាស៊ីនមេ សូមផ្ញើបឋមកថា "Content-disposition: attachment" ។ បន្ទាប់មកឯកសារនឹងត្រូវបានទាញយកដោយកម្មវិធីរុករកហើយមិនត្រូវបានប្រតិបត្តិទេ។

លើសពីនេះ ឥឡូវនេះមានវិធីជាច្រើនដែលមានសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីកាត់បន្ថយហានិភ័យនៃការកេងប្រវ័ញ្ច XSS៖

ដោយប្រើទង់ "HTTP តែប៉ុណ្ណោះ" អ្នកអាចធ្វើឱ្យវគ្គ "ខូគី" បឋមកថាមិនអាចចូលប្រើ JavaScript ព្យាបាទបាន។
បានអនុវត្តគោលនយោបាយ CSP យ៉ាងត្រឹមត្រូវ។ នឹងធ្វើឱ្យវាកាន់តែលំបាកសម្រាប់អ្នកវាយប្រហារក្នុងការទាញយក XSS ។
ម៉ាស៊ីនគំរូទំនើបដូចជា Angular ឬ React ធ្វើអនាម័យទិន្នន័យអ្នកប្រើប្រាស់ដោយស្វ័យប្រវត្តិ មុនពេលបញ្ជូនវាទៅកម្មវិធីរុករករបស់អ្នកប្រើប្រាស់។

ភាពងាយរងគ្រោះនៃការផ្ទៀងផ្ទាត់កត្តាពីរ

ដើម្បីកែលម្អសុវត្ថិភាពគណនី អ្នកប្រើប្រាស់តែងតែត្រូវបានណែនាំឱ្យបើក 2FA (ការផ្ទៀងផ្ទាត់ពីរកត្តា)។ ជាការពិត នេះគឺជាមធ្យោបាយដ៏មានប្រសិទ្ធភាពមួយ ដើម្បីការពារអ្នកវាយប្រហារពីការចូលប្រើសេវាកម្ម ប្រសិនបើព័ត៌មានសម្ងាត់របស់អ្នកប្រើត្រូវបានសម្របសម្រួល។

ប៉ុន្តែតើការប្រើកត្តាផ្ទៀងផ្ទាត់ទីពីរតែងតែធានាសុវត្ថិភាពគណនីដែរឬទេ? មានបញ្ហាសុវត្ថិភាពដូចខាងក្រោមក្នុងការអនុវត្ត 2FA៖

ការស្វែងរក Brute-force នៃកូដ OTP (លេខកូដតែម្តង)។ ទោះបីជាមានភាពសាមញ្ញនៃប្រតិបត្តិការក៏ដោយ កំហុសដូចជាកង្វះការការពារប្រឆាំងនឹង OTP brute force ក៏ត្រូវបានជួបប្រទះដោយក្រុមហ៊ុនធំៗផងដែរ៖ ករណីរអិល, ករណីហ្វេសប៊ុក.
ក្បួនដោះស្រាយជំនាន់ខ្សោយ ឧទាហរណ៍ សមត្ថភាពក្នុងការទស្សន៍ទាយកូដបន្ទាប់។
កំហុសឡូជីខល ដូចជាសមត្ថភាពក្នុងការស្នើសុំ OTP របស់នរណាម្នាក់ផ្សេងទៀតនៅលើទូរស័ព្ទរបស់អ្នកដូចនេះ គឺ ពី Shopify ។

ក្នុងករណី MCS 2FA ត្រូវបានអនុវត្តដោយផ្អែកលើ Google Authenticator និង Duo. ពិធីការខ្លួនវាត្រូវបានសាកល្បងពេលវេលារួចហើយ ប៉ុន្តែការអនុវត្តការផ្ទៀងផ្ទាត់លេខកូដនៅលើផ្នែកកម្មវិធីគឺមានតម្លៃពិនិត្យ។

MCS 2FA ត្រូវបានប្រើនៅកន្លែងជាច្រើន៖

នៅពេលផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់។ មានការការពារប្រឆាំងនឹង brute force៖ អ្នកប្រើប្រាស់គ្រាន់តែព្យាយាមពីរបីដងប៉ុណ្ណោះដើម្បីបញ្ចូលពាក្យសម្ងាត់តែម្តង បន្ទាប់មកការបញ្ចូលត្រូវបានរារាំងមួយរយៈ។ វារារាំងលទ្ធភាពនៃការជ្រើសរើស brute-force នៃ OTP ។
នៅពេលបង្កើតលេខកូដបម្រុងទុកក្រៅបណ្តាញដើម្បីអនុវត្ត 2FA ក៏ដូចជាបិទវា។ នៅទីនេះ គ្មានការការពារដោយបង្ខំណាមួយត្រូវបានអនុវត្តទេ ដែលធ្វើឱ្យវាអាចធ្វើទៅបាន ប្រសិនបើអ្នកមានពាក្យសម្ងាត់សម្រាប់គណនី និងវគ្គសកម្ម ដើម្បីបង្កើតលេខកូដបម្រុងទុកឡើងវិញ ឬបិទ 2FA ទាំងស្រុង។

ដោយពិចារណាថាលេខកូដបម្រុងទុកមានទីតាំងនៅក្នុងជួរដូចគ្នានៃតម្លៃខ្សែអក្សរដែលបង្កើតដោយកម្មវិធី OTP នោះឱកាសនៃការស្វែងរកកូដក្នុងរយៈពេលដ៏ខ្លីគឺខ្ពស់ជាងច្រើន។

ដំណើរការនៃការជ្រើសរើស OTP ដើម្បីបិទ 2FA ដោយប្រើឧបករណ៍ "Burp: Intruder"

លទ្ធផល

សរុបមក MCS ហាក់ដូចជាមានសុវត្ថិភាពជាផលិតផល។ កំឡុងពេលធ្វើសវនកម្ម ក្រុម pentesting មិនអាចចូលប្រើ VMs អតិថិជន និងទិន្នន័យរបស់ពួកគេបានទេ ហើយភាពងាយរងគ្រោះដែលបានរកឃើញត្រូវបានកែតម្រូវយ៉ាងឆាប់រហ័សដោយក្រុម MCS។

ប៉ុន្តែនៅទីនេះវាសំខាន់ក្នុងការកត់សម្គាល់ថាសន្តិសុខគឺជាការងារបន្ត។ សេវាកម្មមិនឋិតិវន្តទេ ពួកគេត្រូវបានវិវឌ្ឍឥតឈប់ឈរ។ ហើយវាមិនអាចទៅរួចទេក្នុងការអភិវឌ្ឍផលិតផលទាំងស្រុងដោយគ្មានភាពងាយរងគ្រោះ។ ប៉ុន្តែអ្នកអាចស្វែងរកពួកវាបានទាន់ពេល និងកាត់បន្ថយឱកាសនៃការកើតឡើងម្តងទៀតរបស់ពួកគេ។

ឥឡូវនេះភាពងាយរងគ្រោះទាំងអស់ដែលបានរៀបរាប់នៅក្នុង MCS ត្រូវបានជួសជុលរួចហើយ។ ហើយដើម្បីរក្សាចំនួនអ្នកថ្មីឱ្យតិចបំផុត និងកាត់បន្ថយអាយុកាលរបស់ពួកគេ ក្រុមវេទិកាបន្តធ្វើដូចនេះ៖

ធ្វើសវនកម្មជាទៀងទាត់ដោយក្រុមហ៊ុនខាងក្រៅ;
គាំទ្រ និងអភិវឌ្ឍការចូលរួម នៅក្នុងកម្មវិធី Mail.ru Group Bug Bounty;
ចូលរួមក្នុងសន្តិសុខ។ 🙂

ប្រភព: www.habr.com

សវនកម្មសុវត្ថិភាពនៃវេទិកាពពក MCS