ការវាយប្រហារលើប្រព័ន្ធ front-end-back-end ដែលអនុញ្ញាតឱ្យយើងចូលទៅក្នុងសំណើរបស់ភាគីទីបី

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

ចំណុចសំខាន់នៃបញ្ហាគឺថា ផ្នែកខាងមុខ និងផ្នែកខាងក្រោយ តែងតែផ្តល់នូវកម្រិតផ្សេងគ្នានៃការគាំទ្រសម្រាប់ពិធីការ HTTP ប៉ុន្តែនៅពេលជាមួយគ្នានោះ បញ្ចូលសំណើពីអ្នកប្រើប្រាស់ផ្សេងគ្នាទៅក្នុងឆានែលទូទៅមួយ។ ដើម្បីភ្ជាប់សំណើទទួលផ្នែកខាងមុខ និងសំណើដំណើរការផ្នែកខាងក្រោយ ការតភ្ជាប់ TCP ដែលមានអាយុកាលយូរត្រូវបានបង្កើតឡើង ដែលតាមរយៈសំណើរបស់អ្នកប្រើប្រាស់ត្រូវបានបញ្ជូន បញ្ជូនតាមខ្សែសង្វាក់មួយបន្ទាប់ពីមួយផ្សេងទៀត បំបែកដោយមធ្យោបាយនៃពិធីការ HTTP ។ ដើម្បីបំបែកសំណើ បឋមកថា "ប្រវែងមាតិកា" (កំណត់ទំហំសរុបនៃទិន្នន័យក្នុងសំណើ) និង "ការបំប្លែង-អ៊ិនកូដ៖ កំណាត់"(អនុញ្ញាតឱ្យអ្នកផ្ទេរទិន្នន័យជាផ្នែកៗ ដោយបញ្ជាក់ប្លុកនៃទំហំខុសៗគ្នាក្នុងទម្រង់ "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0")។

បញ្ហាកើតឡើងប្រសិនបើផ្នែកខាងមុខគាំទ្រតែ "ប្រវែងមាតិកា" ប៉ុន្តែមិនអើពើ "ការអ៊ិនកូដផ្ទេរប្រាក់៖ កំណាត់" (ឧទាហរណ៍ Akamai CDN បានធ្វើដូច្នេះ) ឬផ្ទុយមកវិញ។ ប្រសិនបើ Transfer-Encoding: chunked ត្រូវបានគាំទ្រទាំងសងខាង លក្ខណៈនៃការអនុវត្តកម្មវិធីញែកបឋមកថា HTTP អាចត្រូវបានប្រើសម្រាប់ការវាយប្រហារមួយ (ឧទាហរណ៍ នៅពេលដែលផ្នែកខាងមុខមិនអើពើនឹងបន្ទាត់ដូចជា “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked ”, “ការបំប្លែង-ការអ៊ិនកូដ”៖ [ផ្ទាំង]បានបំបែក”, “X: X[\n]ការបំប្លែង-អ៊ិនកូដ៖ កំណាត់”, “ការបំប្លែងការអ៊ិនកូដ[\n]៖ កំណាត់” ឬ “ការអ៊ិនកូដផ្ទេរ៖ កំណាត់” និង កម្មវិធីខាងក្រោយដំណើរការពួកវាដោយជោគជ័យ)។

ក្នុងករណីនេះ អ្នកវាយប្រហារអាចផ្ញើសំណើដែលមានទាំងផ្នែក "ប្រវែងមាតិកា" និង "ការបំប្លែងការអ៊ិនកូដ៖ កំណាត់" ប៉ុន្តែទំហំនៅក្នុង "ប្រវែងខ្លឹមសារ" មិនត្រូវគ្នានឹងទំហំនៃខ្សែសង្វាក់ដែលបានកំណាត់នោះទេ ដែល តូចជាងតម្លៃពិត។ ប្រសិនបើផ្នែកខាងមុខដំណើរការ និងបញ្ជូនបន្តសំណើដោយយោងតាម ​​"ប្រវែងខ្លឹមសារ" ហើយផ្នែកខាងក្រោយរង់ចាំការបិទបញ្ចប់ដោយផ្អែកលើ "ការបំប្លែងការអ៊ិនកូដ៖ កំណាត់" នោះចុងបញ្ចប់នៃទិន្នន័យផ្អែកលើ "ការបំប្លែងការអ៊ិនកូដ៖ កំណាត់" នឹង ត្រូវបានកំណត់មុននេះ ហើយកន្ទុយដែលនៅសល់នៃសំណើដែលអ្នកវាយប្រហារនឹងនៅដើមដំបូងនៃសំណើបន្ទាប់ ពោលគឺឧ។ អ្នកវាយប្រហារនឹងអាចភ្ជាប់ទិន្នន័យតាមអំពើចិត្តទៅនឹងការចាប់ផ្តើមនៃសំណើរបស់នរណាម្នាក់ដែលបានបញ្ជូនបន្ទាប់។

ដើម្បីកំណត់បញ្ហានៅក្នុងបន្សំផ្នែកខាងមុខ-ខាងក្រោយដែលបានប្រើ អ្នកអាចផ្ញើសំណើដូចនេះតាមរយៈផ្នែកខាងមុខ៖

ប្រកាស / អំពី HTTP / 1.1
ម៉ាស៊ីន៖ example.com
ការបំប្លែង-អ៊ិនកូដ៖ កំណាត់
ខ្លឹមសារ - ប្រវែង៖ ២៤៧

1
Z
Q

បញ្ហាគឺមានវត្តមាន ប្រសិនបើផ្នែកខាងក្រោយមិនដំណើរការសំណើភ្លាមៗ ហើយរង់ចាំការមកដល់នៃប្លុកសូន្យចុងក្រោយនៃទិន្នន័យដែលបានបំបែក។ សម្រាប់ការត្រួតពិនិត្យពេញលេញបន្ថែមទៀត រៀបចំ ឧបករណ៍ប្រើប្រាស់ពិសេសដែលសាកល្បងវិធីសាស្ត្រដែលអាចធ្វើទៅបានសម្រាប់ការលាក់បឋមកថា "ផ្ទេរ-អ៊ិនកូដ៖ កំណាត់" ពីផ្នែកខាងមុខ។

ការអនុវត្តការវាយប្រហារពិតប្រាកដអាស្រ័យលើសមត្ថភាពនៃគេហទំព័រដែលបានវាយប្រហារ ឧទាហរណ៍ នៅពេលវាយប្រហារកម្មវិធីបណ្តាញ Trello អ្នកអាចជំនួសការចាប់ផ្តើមនៃសំណើ (ជំនួសទិន្នន័យដូចជា “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) ហើយផ្ញើសារ រួមទាំងសំណើដើមរបស់អ្នកប្រើភាគីទីបី និងខូគីការផ្ទៀងផ្ទាត់ដែលបានបញ្ជាក់នៅក្នុងវា។ សម្រាប់ការវាយប្រហារនៅលើ saas-app.com វាបានប្រែក្លាយថាអាចជំនួសកូដ JavaScript ក្នុងការឆ្លើយតបដោយជំនួសវានៅក្នុងប៉ារ៉ាម៉ែត្រសំណើណាមួយ។ សម្រាប់ការវាយប្រហារលើ redhat.com អ្នកដោះស្រាយផ្ទៃក្នុងត្រូវបានប្រើដើម្បីបញ្ជូនបន្តទៅកាន់គេហទំព័ររបស់អ្នកវាយប្រហារ (សំណើនៃទម្រង់ “POST /search?dest=../assets/idx?redir=//[អ៊ីមែលការពារ]/ HTTP/1.1") ។

ការប្រើប្រាស់វិធីសាស្រ្តសម្រាប់បណ្តាញចែកចាយមាតិកាបានធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីជំនួសគេហទំព័រដែលបានស្នើសុំដោយគ្រាន់តែជំនួសបឋមកថា "ម៉ាស៊ីន:" ។ ការវាយប្រហារក៏អាចប្រើដើម្បីបំពុលខ្លឹមសារនៃប្រព័ន្ធឃ្លាំងសម្ងាត់មាតិកា និងទាញយកទិន្នន័យសម្ងាត់ដែលបានលាក់ទុក។ ចំនុចកំពូលនៃវិធីសាស្រ្តគឺការរៀបចំការវាយប្រហារលើ PayPal ដែលធ្វើឱ្យវាអាចស្ទាក់ចាប់ពាក្យសម្ងាត់ដែលផ្ញើដោយអ្នកប្រើប្រាស់ក្នុងអំឡុងពេលផ្ទៀងផ្ទាត់ (សំណើ iframe ត្រូវបានកែប្រែដើម្បីប្រតិបត្តិ JavaScript នៅក្នុងបរិបទនៃទំព័រ paypal.com/us/gifts សម្រាប់ ដែល CSP (គោលការណ៍សុវត្ថិភាពមាតិកា) មិនត្រូវបានអនុវត្ត) ។

គួរឱ្យចាប់អារម្មណ៍នៅឆ្នាំ 2005 មាន បានស្នើ បច្ចេកទេសក្លែងបន្លំសំណើស្រដៀងគ្នាដ៏សំខាន់ដែលអនុញ្ញាតឱ្យអ្នកក្លែងបន្លំទិន្នន័យនៅក្នុងឃ្លាំងសម្ងាត់ប្រូកស៊ី (Tomcat, squid, mod_proxy) ឬឆ្លងកាត់ការទប់ស្កាត់ជញ្ជាំងភ្លើងដោយបញ្ជាក់សំណើ "GET" ឬ "POST" ជាច្រើននៅក្នុងវគ្គ HTTP មួយ។

ប្រភព: opennet.ru