გატეხილი ობიექტის დონის ავტორიზაცია მაგალითებით

ამ პოსტში ჩვენ შეისწავლეთ და განვიხილავთ Broken Object- ის დონის ავტორიზაციის გაუმართაობას.

ჩვენ დავიწყებთ იმის ახსნით, თუ რას ნიშნავს ობიექტის დაშლილი დონის ავტორიზაცია. შემდეგ ჩვენ გავალთ შეტევას და ავუხსნით ასოცირებულ რისკ ფაქტორებს.

ამის შემდეგ ჩვენ შევხედავთ მოწყვლადობის ზოგიერთ შესაძლო გავლენას, სანამ საბოლოოდ გადავხედავთ საერთო დაცვას.




რა არის გატეხილი ობიექტის დონის ავტორიზაცია

მოკლედ რომ ვთქვათ, ამ ტიპის შეტევა ნიშნავს, რომ მონაცემთა მიმართებული ავტორიზაცია არ ხდება ისე, როგორც უნდა შესრულდეს. ეს იწვევს რესურსებსა და მონაცემებზე წვდომის მინიჭებას, როდესაც ეს არ უნდა იყოს.

გატეხილი ობიექტის დონის ავტორიზაცია წარსულში ცნობილი იყო როგორც Insecure Direct Object Reference (IDOR).


როცა სიტყვას ვამბობთ ობიექტი Broken Object Level ავტორიზაციაში, რასაც ვგულისხმობთ არის მნიშვნელობა ან ღირებულებების ჯგუფი. ობიექტი შეიძლება იყოს სოციალური ქსელის პოსტი, რომელიც შეიცავს ავტორს, შინაარსს და პოსტის თარიღს.

ავტორიზაცია ყველაფერი არის იმის შესახებ, თუ რაზე აქვს დაშვება მომხმარებელი. ამიტომ, ჩვენ ვსაუბრობთ მომხმარებელზე, რომელიც უკვე შესულია.

როდესაც მომხმარებელი თხოვს API– ს, თხოვნა გამოიყენება ობიექტებზე წვდომისთვის. ეს არის საკითხი, რომელიც უნდა იქნას მიღებული გადაწყვეტილება ავტორიზაციის შესახებ. მომხმარებელს უნდა ჰქონდეს წვდომა მხოლოდ იმ ობიექტებზე, რომლებზეც წვდომა აქვთ მინიჭებული. ეს არის ავტორიზაცია, რომელიც სწორად მუშაობს.


ავტორიზაციის გაწყვეტის შემთხვევაში, მომხმარებლებს აქვთ უფლება მიიღონ მონაცემები და რესურსები, რომელთა აკრძალვაც მათ არ აქვთ.

API ხელს უწყობს ობიექტებზე სხვადასხვა ოპერაციებს. ჩვენ შეგვიძლია ობიექტების მიღება, შექმნა, განახლება ან თუნდაც წაშლა.

ობიექტთან ინტერაქცია არის API- ს მთელი წერტილი, ამიტომ თუ ავტორიზაციის კონტროლი გატეხილია ამ ობიექტებზე, ჩვენ გვაქვს Broken Object Level Access- ის დაუცველობა.



გატეხილი ობიექტის დონეზე წვდომის დაუცველობა

ზოგადად, ადვილია ამ დაუცველობის გამოყენება მისი აღმოჩენის შემდეგ. თავდამსხმელს უნდა გააკეთოს თხოვნაში იდენტიფიკატორის შეცვლა და მათ პოტენციურად მიუწვდებათ ხელი იმ ობიექტებზე, რომელთა აკრძალვაც არ აქვთ.


მოდით ვნახოთ მაგალითში.

აქ გვაქვს URL, რომელიც გამოიყენება API– ს გამოსაძახებლად:

https://myemail.com/messages/12345

ეს API ზარი გამოიყენება მომხმარებლის პირადი შეტყობინებების მისაღებად. გამოყენებული რესურსია შეტყობინებები .

გაგზავნა არის ობიექტი, რომელსაც ჩვენ ვგულისხმობთ Broken Object Level Authorization- ში. დაშვება არის ის, რომ პირადი შეტყობინებების წაკითხვა მხოლოდ დანიშნულების მიმღებს შეუძლიათ.


შემდეგ, ჩვენ გვაქვს შეტყობინების id 12345. ეს არის მნიშვნელოვანი ნაწილი თავდამსხმელისთვის.

ID ეუბნება მომსახურებას, რომელი ჩანაწერი უნდა დააბრუნოს. API იძენს ამ ჩანაწერს მონაცემთა მაღაზიიდან და უბრუნებს მას საპასუხოდ.

ახლა რა მოხდება, თუ ID– ს შევცვლით 12345 რომ 12346? მაგალითად:

https://myemail.com/messages/12346

თუ გაგზავნა id- ით 12346 ჩვენი მომხმარებლისთვის იყო გათვლილი, მისი მიღება უნდა შეგვეძლოს.


მაგრამ თუ შეტყობინება სხვა მომხმარებელს ეკუთვნოდა, API მას არასდროს უნდა დაუბრუნოს. თუ ჩვენ ვერ მოვახერხეთ გაგზავნა, მაშინ ჩვენ შეგვიძლია გატეხილი დონის ობიექტის ავტორიზაციის შეცდომა.

კიდევ ერთი მაგალითია რესურსის განახლებისთვის POST მოთხოვნის გაგზავნა. ჩვენ შეგვიძლია ვითამაშოთ id- ით JSON დატვირთვაში:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

თუ რაიმე პოტენციალს ჩავდებდით userId მოთხოვნაში და შეძლეს სხვა მომხმარებლის მონაცემების განახლება, მასიური პრობლემა გვაქვს.

ტექნიკური გავლენა

მას შემდეგ, რაც ვიცით, რომ მოწყვლადობა არსებობს, მას ყველანაირი მეთოდით შეგვიძლია გამოვიყენოთ. როგორც უკვე აღვნიშნეთ, ჩვენ შეგვიძლია გამოვიყენოთ სხვადასხვა HTTP მეთოდი API- ზე. ჩვენ შეგვიძლია გამოვიყენოთ ID შეტყობინებების განახლების ან თუნდაც წასაშლელად.

რა მოხდება, თუ ყველა ID– ს საშუალებით შეგვიძლია განმეორება? ჩვენ შეგვიძლია ყველა შენახული წერილის წაშლა. ეს დიდი გავლენაა.



საერთო დაუცველობა

ეს არის ძალიან გავრცელებული დაუცველობა. როგორც უკვე აღვნიშნეთ, API გამოიყენება ობიექტებზე მისასვლელად და უმეტეს შემთხვევაში ვიყენებთ ID- ებს რესურსების იდენტიფიცირების თხოვნაში. კითხვა ისმის, არის თუ არა ავტორიზაციის შემოწმება ამ წვდომისთვის?

ძირითადად, არსებობს ორი მიზეზი, რის გამოც ჩვენ კოდექსში გვხვდება Broken Object Level ავტორიზაციის სისუსტეები.

პირველი ის არის, რომ უსაფრთხოების კონტროლი უბრალოდ არ განხორციელებულა. კოდი არ არის დაწერილი მოთხოვნების ავტორიზაციის შემოწმების მიზნით.

მეორე მიზეზი არის ადამიანის შეცდომა. ადამიანები უშვებენ შეცდომებს. კარგი მაგალითია API– ში, რომელიც მუშაობს როგორც მგრძნობიარე არამგრძნობიარე მონაცემებზე. ზოგიერთ მოთხოვნას უნდა ჰქონდეს ავტორიზაციის შემოწმება და ზოგს არა. ასე რომ, ადვილი იქნება ჩეკის გამოტოვება კოდის წერისას.



როგორ გამოავლინონ

ავტომატიზირებული ინსტრუმენტები ჩვეულებრივ ვერ პოულობენ ამ ტიპის დაუცველობას, რადგან ის თავის ტვინის მცირედი ენერგიის მინიმუმამდე მიყვანას ისწრაფვის.

ადამიანისთვის შედარებით ადვილია ამ დაუცველობის დადგენა. ყველაფერი რაც ჩვენ უნდა გავაკეთოთ არის ვიპოვოთ იდენტიფიკატორი, რომელიც გამოიყენება საგნების მოსაპოვებლად.

გაითვალისწინეთ, რომ იდენტიფიკატორი შეიძლება იყოს Url- ში, მოთხოვნის განყოფილებაში ან სათაურში.

ასევე, ჩვენ უნდა გავაანალიზოთ და განვსაზღვროთ პასუხი, რომელიც ბრუნდება, რომ ვნახოთ არის თუ არა მოწყვლადობა.

ინსტრუმენტები

ჩვენ შეგვიძლია გამოვიყენოთ ნებისმიერი ინსტრუმენტი, რომელიც ამოწმებს HTTP მოთხოვნებსა და პასუხებს. ზოგიერთი მათგანია:

  • Google Developer Tools
  • Burp Suite
  • ფოსტალიონი

Burp Suite ასევე შეიძლება გამოყენებულ იქნას ზოგიერთი მოთხოვნის ავტომატიზირებისთვის.



დამცავი ობიექტის დონის ავტორიზაციისგან დაცვა

აქ ორი დაცვა გვაქვს.

პირველი დაცვა არის გამოყენება არაპროგნოზირებადი ID– ები, როგორიცაა GUID . როდესაც კოდექსში ვიყენებთ ზედიზედ რიცხვებს, მაგ. 12345, ეს ნიშნავს, რომ პირადობის მოწმობები ძალიან პროგნოზირებადია. ობიექტების პოვნის მიზნით თავდამსხმელს არ სჭირდება დიდი ძალისხმევა ციფრების გასავლელად.

GUID- ის მაგალითი:

d3b773e6-3b44-4f5f-9813-c39844719fc4

GUID– ები რთული და ძნელი მისახვედრია და არ არის თანმიმდევრული.

შემდეგი დაცვა არის რეალურად გარკვეული კოდის არსებობა შეამოწმეთ ავტორიზაცია . ეს შემოწმება ხშირად უბრალოდ არ ხდება.

ავტორიზაციის შემოწმება უნდა მოხდეს ნებისმიერ დროს, როდესაც მომხმარებელი წარმოგიდგენთ API- ს ID- ს, რომელიც გამოყენებული იქნება. აქ ძირითადი პრინციპია, რომ ჩვენ არასდროს უნდა ვენდოთ მონაცემებს, რომელსაც მომხმარებელი აძლევს API- ს.

მოთხოვნილი პირადობის მოწმობა უნდა შემოწმდეს, რომ დადასტურდეს, რომ მომხმარებელი უფლებამოსილია წვდომა მოახდინოს ობიექტზე.

ეს შემოწმებები შეიძლება იყოს მხოლოდ მარტივი კოდის მიმოხილვა პროგრამული უზრუნველყოფის დამუშავების დროს და / ან ავტომატიზირებული შემოწმებები, რომლებიც ამოწმებს ავტორიზაციის გაუმართაობას მთელი განვითარების პროცესში.



დასკვნა

როგორც ჩვენ ვნახეთ Broken Object Level ავტორიზაცია არის საერთო მოწყვლადობა და ადვილი შესამჩნევია და შეტევა ხდება. პოტენციური ზემოქმედება დიდია.

ამ მოწყვლადობის ნამდვილი წყაროა მონაცემთა სანდო მონაცემები, რომლებიც კლიენტს გადასცემს API- ს.

თავდაცვის დიდი ნაწილი არის ის, რომ დარწმუნდეთ, რომ ამ მონაცემებს არ ვენდობით. ამიტომ ჩვენ უნდა დავრწმუნდეთ, რომ ავტორიზაციის შემოწმება განხორციელებულია.

საინტერესო სტატიები