5. Wrong security Configuration
ចំណុចមួយរបស់វេបសាយដែលអាចជាចន្លោះប្រហោងនៃការវាយប្រហារ នោះគឺ wrong security configuration។ ពួកអ្នកវាយប្រហារអាចអនុវត្តបានយ៉ាងងាយស្រួល ដោយប្រើប្រាស់ សិទ្ធិជាadmin ដោយសារការកំណត់មិនបានត្រឹមត្រូវរបស់អ្នកនៅលើវេបសាយ។ តើការកំណត់មិនត្រឹមត្រូវហ្នឹងមានអ្វីខ្លះ? ជាឧទាហរណ៍សាមញ្ញមួយ គឺការប្រើប្រាស់
default username និង password ការប្រើប្រាស់ services, script, configuration files, sample file -ល- ជាចំនុចមួយដែលនាំឲ្យវេបសាយរបស់អ្នកប្រឈមនឹងការវាយប្រហារ ទៅលើ web server, database, application server និង ចំនុចផ្សេងៗទៀត។ ដូចនេះទាំងអ្នកបង្កើតវេបសាយ និង អ្នកគ្រប់គ្រងវេបសាយត្រូវធានាថា រាល់ configuration ត្រូវបានកំណត់ដោយត្រឹមត្រូវ។ គេអាចដឹងអំពីចន្លោះប្រហោងនេះបាន ដោយប្រើប្រាស់ tool សំរាប់ស្វែងរក (automated scanner)។ នៅពេលដែលdeveloper deploy វេបសាយ គួរណាស់តែប្រើប្រាស់
encryption algorithm ដើម្បីបម្លែងទិន្នន័យ ឬ ព័ត៌មានដែលអាចជាចំនុចគោលដៅនៃការវាយប្រហារ ដោយឡែកអ្នកគ្រប់គ្រងវាយសាយ គួរតែជៀសវាងប្រើប្រាស់ default username និងpassword។
6. Cross Site Request Forgery (CSRF)
Hmmm, ខាងក្រោមនេះដំណើរនៃការ attack ដោយខ្ញុំលើកយកមកពន្យល់៖
១. អ្នកប្រើប្រាស់វេបសាយរបស់ធនាគារមួយ
(itjonbotbank.com) បានឡុកចូលទៅក្នុងវេបសាយរបស់ធនាគារដើម្បីធ្វើប្រតិបត្តិការអ្វីមួយ
២.ស្របពេលជាមួយគ្នា អ្នកប្រើប្រាស់នោះបានបើកវេបសាយមួយ ដែលជាវេបសាយរបស់attacker។ វេបសាយនេះត្រូវបានគេរៀបចំជាស្រេចសំរាប់attack ទៅលើ itjonbotbank.com
៣. នៅលើវេបសាយនោះ កាលណាគេចុចអ្វីមួយ(ឧទារហណ៍ជា button) វានឹងrequest ទៅកាន់ វេបសាយធនាគារ ស្នើរសុំផ្លាស់ប្តូរលេខសំងាត់របស់អ្នកប្រើប្រាស់។ នៅពេលដែលវា requestទៅកាន់វេបសាយរបស់ធនាគារ វាបានប្រើប្រាស់ account របស់អ្នកប្រើប្រាស់ដែលបានឡុកចូល ដោយអ្នកប្រើប្រាស់មិនបានដឹងអំពី ការrequestសុំផ្លាស់ប្តូរលេខសំងាត់ទេ (នៅពេលដែលអ្នកប្រើប្រាស់logចូលវេបសាយរបស់ធនាគារ វាបានរក្សាទុកនូវ session ដូចនេះវេបសាយរបស់ attackerបានប្រើប្រាស់
session នោះដើម្បីrequestទៅកាន់ itjonbotbank.com)។ ទីបំផុត attacker អាចប្តូរលេខសំងាត់ថ្មី ហើយធ្វើប្រតិបត្តិការនានា ដូចជាផ្ទេរលុយជាដើម។
តើក្នុងនាមជាអ្នកបង្កើតវេបសាយប្រភេទនេះ អ្នកត្រូវធ្វើដូចម្ត៉េចដើម្បីជៀសវាងការវេយប្រហារបែបនេះ? ប្រសិនបើអ្នកស្វែងរកពីវិធីការពារវា អ្នកអាចស្វែងរកលើ internet ដោយសរសេរថា CSRF prevention ឬ CSRF protection។ ការប្រើប្រាស់
token នៅក្នុង user session ជាវិធីមួយដែលអ្នកអាចប្រើប្រាស់បាន។ នៅពេលដែល user session ត្រូវបានបង្កើត នោះtoken ត្រូវបានបន្ថែមចូលទៅក្នុង sessionនោះផងដែរ។ ចឹងរាល់ពេលដែលមាន request វានឹងផ្ទៀងផ្ទាត់ token នោះថាវាត្រឹមត្រូវឬអត់។ ចំនុចបន្ទាប់នេះ ក៏អាចអនុវត្តបានផងដែរ ចំពោះ user ដូចជា ការមិនបើកវេបសាយផ្សេងៗទៀត កំឡុងពេលដែលអ្នកឡុកចូលនៅក្នុងវេបសាយរបស់ធនាគារ ជានិច្ចជាកាល ត្រូវlogout រាល់ពេលបញ្ចប់ការងាររបស់អ្នក ហើយជៀសវាងការ save login credential។ សំរាប់ ការប្រើប្រាស់ CSRF Protection ជាមួយ
Laravel framework សូមចុច
7. RCE (Remote Code Execution)
កាលណាattackerអាចaccessចូលទៅកាន់ម៉ាស៊ីនcomputer ឬ server បាន ហើយអនុវត្តឲ្យដំណើការcodeនានា ហៅថា Remote Code execution។ តាមរយៈcode ដែលគេប្រើប្រាស់ដើម្បីrun attacker អាចចូលមើល ឬ កែប្រែព័ត៌មាន ឬ ទិន្នន័យដែលមាននៅលើ server។ ភាគច្រើនចន្លោះប្រហោងនេះ គឺកើតឡើងដោយសារការមិនបានពិនិត្យត្រឹមត្រូវលើ
server (coding error)។ ដូចនេះអ្នកគួរតែដោះស្រាយចន្លោះប្រហោងនេះដើម្បីជៀសផុតពីការវាយប្រហារ។
8.បញ្ហាជាមួយ username (Username Enumeration)
ជាទូទៅ សំរាប់developer គេតែងតែបង្កើត username និង password សំរាប់ test ទៅលើ project ដែលគេបាននិងកំពុងធ្វើ។ ចំនុចនេះកាលណាគេភ្លេច remove username
(admin | demo | test) និង password (admin | demo | 123)ហ្នឹងចេញ នោះattackerអាចព្យាយាមប្រើប្រាស់ username/password ទាំងនោះសំរាប់logចូល។ សូមប្រយ័ត្ន បើមិនដូច្នេះទេ វេបសាយរបស់អាចប្រឈមនឹងការវាយប្រហារហើយ។ ការប្រើប្រាស់ សារ (message) ដែលបញ្ជាក់ច្បាស់អំពី error
( username is invalid | password must be 12 length | username does not exists) វាជួយកាត់បន្ថយការព្យាយាមវាយប្រហារ របស់attackerផងដែរ។ សូមចាំថាattacker តែងប្រើប្រាស់គ្រប់មធ្យោបាយក្នុងការព្យាយាម វាយប្រហារទៅលើវេបសាយ ឬ systemរបស់អ្នក។ អ្នកគួរសិក្សារទៅលើចំនុចទាំង៨ដែលខ្ញុំបានសរសេររៀបរាប់ខាងលើ បើទៅបីជាពួកវាមិនអាចជួយការពារប្រព័ន្ធរបស់អ្នកទាំងស្រុងបានក៏ដោយ កាលណាអ្នកdeploy វេបសាយចូល។ បន្ថែមលើនេះ អ្នកកួរតែធ្វើការupdateវេបសាយឬប្រព័ន្ធរបស់អ្នកឲ្យបានញឹកញាប់ ជាពិសេសកុំភ្លេច backupផង។
តើអ្នកបានដឹង របៀបនៃការវារប្រហារផ្សេងៗពីនេះទេ សូមចូលរួមចែករំលែកផង
