ម៉ាស៊ីនស្វែងរកត្រូវបានបង្កើតឡើងដើម្បីធ្វើលិបិក្រមខ្លឹមសារ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកវាយប្រហារប្រើប្រាស់វាដើម្បីធ្វើលិបិក្រមកំហុសរបស់អ្នក។ សំណួរ អត្ថបទទាំងអស់៖login ប្រភេទឯកសារ៖ កំណត់ហេតុ អាចមើលទៅគ្មានគ្រោះថ្នាក់។ តាមពិតទៅ វាគឺជាវិធីមួយក្នុងចំណោមវិធីសាមញ្ញបំផុតដើម្បីស្វែងរកឯកសារកំណត់ហេតុដែលលាតត្រដាង ដែលមានលំហូរផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ លិខិតសម្គាល់ ថូខឹន និងទិន្នន័យហេដ្ឋារចនាសម្ព័ន្ធផ្ទៃក្នុង។
ប្រសិនបើ Google អាចមើលឃើញកំណត់ហេតុទាំងនោះ អ្នកវាយប្រហារក៏អាចមើលឃើញដែរ។ នៅពេលដែលត្រូវបានធ្វើលិបិក្រមរួចហើយ ការលាតត្រដាងនឹងជៀសមិនរួច។ លើសពីនេះ នៅពេលដែលព័ត៌មានសម្ងាត់លេចឡើងក្នុងឯកសារដែលអាចចូលមើលបានជាសាធារណៈ ការរំលោភបំពាននេះកំពុងដំណើរការរួចហើយ។
១. ហេតុអ្វី allintext៖login filetype:log មានគ្រោះថ្នាក់ជាងអ្វីដែលវាមើលទៅ
Google dork គឺជាសំណួរស្វែងរកដែលប្រើប្រតិបត្តិករកម្រិតខ្ពស់ដើម្បីស្វែងរកខ្លឹមសាររសើប ឬកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវដែលត្រូវបានដាក់លិបិក្រមដោយម៉ាស៊ីនស្វែងរក។ វាមិនកេងប្រវ័ញ្ច Google ទេ។ ផ្ទុយទៅវិញ វាកេងប្រវ័ញ្ចការបង្ហាញរបស់អ្នក។
សំណួរនេះផ្សំប្រតិបត្តិករពីរ៖
- អត្ថបទទាំងអស់៖ បង្ហាញទំព័រដែលពាក្យទាំងអស់លេចឡើងក្នុងអត្ថបទ
- ប្រភេទឯកសារ៖ កំណត់ហេតុ កំណត់លទ្ធផលទៅ
.logឯកសារ
ដូច្នេះ:
មានន័យថា៖ "បង្ហាញខ្ញុំពីឯកសារកំណត់ហេតុដែលមានពាក្យនេះ login"។
នៅពេលមើលដំបូង វាហាក់ដូចជារឿងតូចតាច។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តជាក់ស្តែង ជារឿយៗវាបង្ហាញមកវិញថា៖
- កំណត់ហេតុម៉ាស៊ីនបម្រើគេហទំព័រដែលបានបង្ហាញជាសាធារណៈ
- CI/CD កំណត់ហេតុដែលបានផ្ទុកឡើងជាវត្ថុបុរាណ
- កែកំហុសកំណត់ហេតុដោយចៃដន្យ commitបានបញ្ជូនទៅឃ្លាំង
- កំណត់ហេតុកម្មវិធីដែលមានព័ត៌មានសម្ងាត់ជាអក្សរធម្មតា
នេះមិនមែនជាកំហុសរបស់ម៉ាស៊ីនស្វែងរកទេ។ ផ្ទុយទៅវិញ វាគឺជា ភាពងាយរងគ្រោះនៃការបង្ហាញទិន្នន័យ បណ្តាលមកពីការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ។ Google គ្រាន់តែធ្វើលិបិក្រមអ្វីដែលអាចចូលប្រើបានជាសាធារណៈ។
២. អ្វីដែលអ្នកវាយប្រហារពិតជារកឃើញនៅក្នុងឯកសារកំណត់ហេតុដែលលាតត្រដាង
ពេលអ្នកវាយប្រហាររត់គេចខ្លួន អត្ថបទទាំងអស់៖login ប្រភេទឯកសារ៖ កំណត់ហេតុពួកគេមិនកំពុងរុករកដោយចៃដន្យទេ។ ពួកគេកំពុងស្វែងរកដាននៃការផ្ទៀងផ្ទាត់។
២.១ លិខិតបញ្ជាក់អត្តសញ្ញាណជាអក្សរធម្មតា
កំណត់ហេតុច្រើនតែមានធាតុដូចជា៖
or
ឬសូម្បីតែលិខិតសម្គាល់ SMTP៖
ការកត់ត្រាបន្ទុកទិន្នន័យផ្ទៀងផ្ទាត់គឺជាវិធីមួយក្នុងចំណោមវិធីលឿនបំផុតដើម្បីលេចធ្លាយព័ត៌មានសម្ងាត់ផលិតកម្ម។ ជាលទ្ធផល ឯកសារកំណត់ហេតុតែមួយដែលបានបង្ហាញអាចធ្វើឱ្យគំរូគ្រប់គ្រងការចូលប្រើរបស់អ្នកទាំងមូលមិនមានសុពលភាព។
២.២ ថូខឹនវគ្គ និង JWT
សូម្បីតែពេលដែលពាក្យសម្ងាត់មិនត្រូវបានកត់ត្រាទុកក៏ដោយ ថូខឹនជារឿយៗត្រូវបានកត់ត្រាទុក។
ឧទាហរណ៍:
ខូគី JWT ឬវគ្គដែលមានសុពលភាពនៅខាងក្នុង .log ឯកសារអាចអនុញ្ញាត៖
- ប្លន់វេន
- ការកើនឡើងសិទ្ធិ
- ចលនាចំហៀងឆ្លងកាត់ប្រព័ន្ធខាងក្នុង
ម្យ៉ាងទៀត ថូខឹននៅក្នុងកំណត់ហេតុប្រែក្លាយលទ្ធផលនៃការបំបាត់កំហុសទៅជាវ៉ិចទ័ររំលងការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ។
2.3 CI/CD វត្ថុបុរាណ
ឈើសំណង់មានគ្រោះថ្នាក់ជាពិសេស។ តាមពិតទៅ CI/CD ប្រព័ន្ធជារឿយៗបោះពុម្ពអថេរបរិស្ថានកំឡុងពេលជំហានសាងសង់។
អ្នកវាយប្រហារច្រើនតែរកឃើញ៖
ដែលមានបន្ទាត់ដូចជា៖
If CI/CD វត្ថុបុរាណគឺជាសាធារណៈ បន្ទាប់មកអាថ៌កំបាំងគឺជាសាធារណៈ។ Google dork គ្រាន់តែបង្កើនល្បឿនការរកឃើញ។
២.៤ ទិន្នន័យលើពពក និងហេដ្ឋារចនាសម្ព័ន្ធ
កំណត់ហេតុដែលលាតត្រដាងជាញឹកញាប់បង្ហាញ៖
- សោចូលប្រើ AWS
- ខ្សែអក្សរតភ្ជាប់ផ្ទុក Azure
- URL សេវាកម្មផ្ទៃក្នុង
- អត្តសញ្ញាណមូលដ្ឋានទិន្នន័យ
- ចំណុចបញ្ចប់ Redis
ទោះបីជាព័ត៌មានសម្គាល់ត្រូវបានប្តូរនៅពេលក្រោយក៏ដោយ អ្នកវាយប្រហារឥឡូវនេះមាន៖
- ការធ្វើផែនទីហេដ្ឋារចនាសម្ព័ន្ធ
- អនុសញ្ញានៃការដាក់ឈ្មោះ
- ចារកម្មគោលដៅសម្រាប់ការវាយប្រហារនាពេលអនាគត
ដូច្នេះ កំណត់ហេតុដែលលាតត្រដាងផ្តល់ទាំងការចូលប្រើប្រាស់ និងការឈ្លបយកការណ៍។
៣. របៀបដែលកំណត់ហេតុទាំងនេះក្លាយជាសាធារណៈតាំងពីដំបូង
កំណត់ហេតុមិនលេចឡើងក្នុង Google ដោយអព្ភូតហេតុទេ។ ពួកវាត្រូវបានធ្វើលិបិក្រម ពីព្រោះវាអាចចូលមើលបានជាសាធារណៈ។
៣.១ ម៉ាស៊ីនបម្រើគេហទំព័រដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ
លំនាំទូទៅរួមមាន៖
/logs/ថតឯកសារដែលអាចចូលប្រើបានដោយមិនចាំបាច់ផ្ទៀងផ្ទាត់- បញ្ជីបញ្ជីត្រូវបានបើក
- Nginx ឬ Apache កំពុងបម្រើឆៅ
.logឯកសារ
ប្រសិនបើកំណត់ហេតុអាចចូលបានតាមរយៈ HTTP វាអាចធ្វើបានលិបិក្រម។
3.2 CI/CD ការលាតត្រដាងវត្ថុបុរាណ
កំហុសធម្មតា៖
- វត្ថុបុរាណសាធារណៈត្រូវបានបើកនៅក្នុង សកម្មភាព GitHub
- កំណត់ហេតុត្រូវបានផ្ទុកឡើងទៅក្នុងធុង S3 ដែលបើកចំហ
- Pipeline ដានអាចចូលប្រើបានដោយមិនចាំបាច់ផ្ទៀងផ្ទាត់
A pipeline ដែលរក្សាទុកកំណត់ហេតុនៅក្នុងធុងសាធារណៈ ផ្សព្វផ្សាយអាថ៌កំបាំងរបស់វាប្រកបដោយប្រសិទ្ធភាព។
៣.៣ របៀបបំបាត់កំហុសនៅក្នុងផលិតកម្ម
លំនាំដើមនៃក្របខ័ណ្ឌអាចមានគ្រោះថ្នាក់៖
លើសពីនេះ ការកត់ត្រាសំណើច្រើនពេកអាចបោះពុម្ព៖
- បឋមកថា
- ថូខឹន
- ស្ថាប័នស្នើសុំពេញលេញ
ការកត់ត្រាកំហុសក្នុងផលិតកម្មប្រែក្លាយកម្មវិធីរបស់អ្នកទៅជាឧបករណ៍នាំចេញព័ត៌មានសម្គាល់។
៣.៤ កំណត់ហេតុ Docker និង Container
បរិស្ថានកុងតឺន័រណែនាំផ្លូវប៉ះពាល់ថ្មី៖
- កំណត់ហេតុត្រូវបានម៉ោនទៅក្នុងភាគដែលបានចែករំលែក
- រថយន្តចំហៀងនាំចេញកំណត់ហេតុទៅកាន់ចំណុចបញ្ចប់ដែលមិនមានសុវត្ថិភាព
- ចូល dashboards ជាមួយនឹងការចូលប្រើប្រាស់ជាសាធារណៈ
ប្រសិនបើកំណត់ហេតុកុងតឺន័រត្រូវបានបង្ហាញតាមរយៈ HTTP ឬកន្លែងផ្ទុកបើកចំហ ពួកវាអាចស្វែងរកបាន។ នៅទីបំផុត ពួកវាត្រូវបានដាក់លិបិក្រម។
៤. លំហូរវាយប្រហារប្រាកដនិយម៖ ពី Dork ដល់ Breach
ខ្សែសង្វាក់វាយប្រហារធម្មតាមើលទៅដូចនេះ៖
អ្នកវាយប្រហាររត់៖
- ការរកឃើញដែលបានបង្ហាញ
.logឯកសារ - ដកស្រង់៖
- ថូខឹន JWT
- បឋមកថាអនុញ្ញាតមូលដ្ឋាន
- ខ្សែតភ្ជាប់មូលដ្ឋានទិន្នន័យ
ការប៉ុនប៉ងផ្ទៀងផ្ទាត់ប្រឆាំងនឹង៖
- ចំណុចបញ្ចប់ API
- ផ្ទាំងគ្រប់គ្រង
- សេវាកម្មផ្ទៃក្នុង
ប្រសិនបើការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវទទួលបានជោគជ័យ អ្នកវាយប្រហារអាច៖
- បង្កើនសិទ្ធិ
- ផ្លាស់ទីទៅចំហៀង
- ការចូលប្រើប្រាស់ CI/CD
- សម្របសម្រួលខ្សែសង្វាក់ផ្គត់ផ្គង់
អ្វីដែលចាប់ផ្តើមជាសំណួរស្វែងរកបានក្លាយជា៖
- ប្លន់វេន
- ការបំពេញឯកសារបញ្ជាក់អត្តសញ្ញាណផ្ទៃក្នុង
- Pipeline ការកាន់កាប់
- ការពុលវត្ថុបុរាណ
ទាំងអស់មកពីឯកសារកំណត់ហេតុដែលបានធ្វើលិបិក្រមជាសាធារណៈ។
៥. ហេតុអ្វីបានជាការកត់ត្រា "ច្រើនពេក" ជាបញ្ហា AppSec
ការកត់ត្រាមិនមែនជាអព្យាក្រឹតទេ។ ផ្ទុយទៅវិញ វាបង្កើត ឃ្លាំងទិន្នន័យបន្ទាប់បន្សំ.
ប្រសិនបើអ្នកកត់ត្រាទិន្នន័យរសើប អ្នកនឹងបង្កើតច្បាប់ចម្លងទីពីរនៃអាថ៌កំបាំងរបស់អ្នកយ៉ាងមានប្រសិទ្ធភាព។
ទោះជាយ៉ាងណាក៏ដោយ កំណត់ហេតុជារឿយៗត្រូវបានដកចេញពីការធ្វើគំរូគំរាមកំហែង។ នៅក្រោម STRIDE នេះបង្ហាញយ៉ាងច្បាស់អំពី៖
ព័ត៌មានបង្ហាញ
ដូច្នេះ សុវត្ថិភាព SDLC ការអនុវត្តគួរតែចាត់ទុកកំណត់ហេតុដូចជា៖
- វត្ថុបុរាណពាក់ព័ន្ធនឹងសុវត្ថិភាព
- ទ្រព្យសកម្មដែលងាយរងគ្រោះ
- សមាសធាតុហេដ្ឋារចនាសម្ព័ន្ធដែលត្រូវការការការពារ
ប្រសិនបើគំរូគំរាមកំហែងរបស់អ្នកមិនអើពើនឹងកំណត់ហេតុទេ វាមិនពេញលេញទេ។
៦. របៀបការពារការលេចធ្លាយព័ត៌មានសម្ងាត់នៅក្នុងឯកសារកំណត់ហេតុ
៦.១ បញ្ឈប់ការកត់ត្រាអាថ៌កំបាំង
កុំកត់ត្រាទុក៖
- ពាក្យសម្ងាត់
- ថូខឹន
- សោ API
- លេខសម្គាល់វគ្គ
- បឋមកថានៃការអនុញ្ញាត
សូម្បីតែនៅក្នុងរបៀបបំបាត់កំហុសក៏ដោយ។
នៅពេលណាដែលអាចធ្វើទៅបាន សូមអនុវត្តការកែដោយស្វ័យប្រវត្តិ។
៦.២ ការកត់ត្រាដែលមានរចនាសម្ព័ន្ធ និងសុវត្ថិភាព
ប្រើការកត់ត្រាដែលមានរចនាសម្ព័ន្ធជាមួយនឹងការបិទបាំង និងការច្រោះ។
ឧទាហរណ៍ (Node.js):
ឧទាហរណ៍ (Python):
គោលការណ៍សំខាន់គឺសាមញ្ញ៖ អាថ៌កំបាំងមិនត្រូវទៅដល់អាងស្តុកឈើឡើយ។
៦.៣ ការផ្ទុកកំណត់ហេតុដោយចាក់សោរ
ការគ្រប់គ្រងសុវត្ថិភាពគួរតែរួមមាន៖
- បិទការចុះបញ្ជីថតឯកសារ
- ការពារ
/logs/ផ្លូវដែលមានការផ្ទៀងផ្ទាត់ - ដាក់កម្រិតការចូលប្រើធុង
- អនុវត្តគោលការណ៍រក្សាទុក
- អ៊ិនគ្រីបកំណត់ហេតុនៅពេលសម្រាក
កំណត់ហេតុមិនត្រូវអាចចូលមើលជាសាធារណៈតាមរយៈ HTTP ឡើយ។
6.4 CI/CD Guardrails
ការពិនិត្យដោយដៃមិនគ្រប់គ្រាន់ទេ។ ផ្ទុយទៅវិញ សូមអនុវត្តការគ្រប់គ្រងដោយស្វ័យប្រវត្តិ៖
- ការស្កេនកំណត់ហេតុដោយសម្ងាត់មុនពេលបោះពុម្ពផ្សាយវត្ថុបុរាណ
- ការបង្កើតបរាជ័យប្រសិនបើសញ្ញាសម្ងាត់ត្រូវបានរកឃើញ
- ទប់ស្កាត់ការបង្ហោះវត្ថុបុរាណដែលមានព័ត៌មានសម្ងាត់
- ការផ្ទៀងផ្ទាត់ហាសសម្រាប់វត្ថុបុរាណ
CI/CD គួរតែទប់ស្កាត់ការប៉ះពាល់មុនពេលការធ្វើលិបិក្រមកើតឡើង។
៧. របៀបដែល Xygeni ការពារ allintext៖login ប្រភេទឯកសារ៖ កំណត់ហេតុឧប្បត្តិហេតុ
បញ្ហាមិនមែនជា Google dork ទេ។ បញ្ហាគឺការប៉ះពាល់។ ដូច្នេះ ការបង្ការត្រូវតែកើតឡើងមុនពេលធ្វើ indexing។
៧.១ ការរកឃើញសម្ងាត់នៅក្នុងកំណត់ហេតុ និងវត្ថុបុរាណ
ការស្កេន Xygeni៖
- កំណត់ហេតុកម្មវិធី
- CI/CD ដានការងារ
- សាងសង់វត្ថុបុរាណ
- ស្រទាប់ Docker
- លទ្ធផលដែលបានធ្វើជាស៊េរី
ប្រសិនបើព័ត៌មានសម្ងាត់ ថូខឹន ឬតម្លៃរសើបលេចឡើងក្នុង .log ឯកសារទាំងនោះ Xygeni នឹងដាក់ទង់សម្គាល់ពួកវាភ្លាមៗ។
7.2 CI/CD Guardrails ការបិទបាំងការប៉ះពាល់នោះ
ជំនួសឲ្យការពឹងផ្អែកលើការពិនិត្យដោយដៃ Xygeni ពង្រឹងសន្តិសុខនៅ pipeline កម្រិត:
នេះ៖
- ការបរាជ័យកើតឡើងនៅពេលដែលអាថ៌កំបាំងលេចឡើងក្នុងកំណត់ហេតុ
- ការបោះពុម្ពផ្សាយវត្ថុបុរាណប្លុក
- ការពារការប៉ះពាល់ដោយចៃដន្យនៅទីសាធារណៈ
- បញ្ឈប់ការបញ្ចូលគ្នាដែលមិនមានសុវត្ថិភាពមុនពេលទៅដល់ចំណុចសំខាន់
ប្រសិនបើការងារ CI បោះពុម្ពសញ្ញាសម្ងាត់ នោះ pipeline បរាជ័យ។
គ្មានការធ្វើលិបិក្រមទេ។
គ្មានការប៉ះពាល់ទេ។
គ្មានហេតុការណ៍អ្វីទេ។
7.3 ការការពារ Shift-Left មុនពេល Google ឃើញវា
ពេលវេលាសំខាន់។
ជំនួសឲ្យប្រតិកម្មចំពោះ៖
Xygeni បញ្ឈប់បញ្ហានេះ៖
- At commit ពេល
- ក្នុងកំឡុងពេល pull request validation
- ក្នុងកំឡុងពេល pipeline ការប្រតិបត្តិ
- មុនពេលបោះពុម្ពផ្សាយស្នាដៃ
ប្រសិនបើកំណត់ហេតុមិនដែលក្លាយជាសាធារណៈទេ Google មិនដែលធ្វើលិបិក្រមវាឡើយ។
ចំណុចចុងក្រោយ៖ ប្រសិនបើ Google អាចធ្វើលិបិក្រមវាបាន អ្នកវាយប្រហារបានធ្វើរួចហើយ
កំណត់ហេតុមិនមែនជារឿងគ្មានគ្រោះថ្នាក់ទេ។ តាមពិតទៅ ពួកវាកម្រមានលក្ខណៈបណ្ដោះអាសន្នណាស់។ តាមលំនាំដើម ពួកវាមិនមែនជាឯកជនទេ។ ដូច្នេះ ឯកសារកំណត់ហេតុនីមួយៗគួរតែត្រូវបានចាត់ទុកថាជាទ្រព្យសកម្មដែលពាក់ព័ន្ធនឹងសុវត្ថិភាព មិនមែនគ្រាន់តែជាលទ្ធផលនៃការបំបាត់កំហុសនោះទេ។
ប្រសិនបើទិន្នន័យរសើបឈានដល់ .log ឯកសារ ហើយអាចចូលមើលបានជាសាធារណៈ វាប្រែជាផ្ទៃវាយប្រហារភ្លាមៗ។ លើសពីនេះ នៅពេលដែលត្រូវបានដាក់លិបិក្រមដោយម៉ាស៊ីនស្វែងរក ការប៉ះពាល់នឹងធ្វើមាត្រដ្ឋានហួសពីការគ្រប់គ្រងរបស់អ្នក។
ដំណោះស្រាយគឺមិនត្រូវបញ្ឈប់ការកត់ត្រាទិន្នន័យនោះទេ។ ផ្ទុយទៅវិញ វាគឺជាការកត់ត្រាទិន្នន័យដោយមានការទទួលខុសត្រូវ និងអនុវត្តការគ្រប់គ្រងយ៉ាងតឹងរ៉ឹងជុំវិញការផ្ទុក និងការចែកចាយ។ ម្យ៉ាងវិញទៀត សុវត្ថិភាពត្រូវតែពង្រីកហួសពីកម្មវិធីខ្លួនឯង និងចូលទៅក្នុងស្រទាប់ដែលអាចសង្កេតបាន។
ជំនួស៖
- ឈប់កត់ត្រាអាថ៌កំបាំង
- ចាក់សោរកន្លែងផ្ទុកកំណត់ហេតុ
- អនុវត្ត pipeline guardrails
- ស្វ័យប្រវត្តិកម្មការរកឃើញ និងការអនុវត្តគោលនយោបាយ
ទីបំផុត, ការបង្ការគឺនិយាយអំពីពេលវេលា។ ពីព្រោះម្តង អត្ថបទទាំងអស់៖login ប្រភេទឯកសារ៖ កំណត់ហេតុ ប្រគល់ដែនរបស់អ្នកវិញ ឧប្បត្តិហេតុនេះបានចាប់ផ្តើមរួចហើយ។
