რა არის IDOR? რატომ უნდა აინტერესოთ დეველოპერებს?
რა არის IDOR? დაუცველი პირდაპირი ობიექტის მითითება (IDOR) არის კრიტიკული უსაფრთხოების ხარვეზი, რომელიც წარმოიქმნება მაშინ, როდესაც აპლიკაციები ავლენენ შიდა ობიექტებს, როგორიცაა მომხმარებლის ID-ები, ფაილები ან მონაცემთა ბაზის გასაღებები, სათანადო წვდომის კონტროლის აღსრულების გარეშე. DevSecOps გარემოში, სადაც უსაფრთხოება ინტეგრირებულია განვითარების მთელი სასიცოცხლო ციკლის განმავლობაში, IDOR-ის დაუცველობების თავიდან აცილება აუცილებელია მგრძნობიარე მონაცემების დასაცავად და სისტემის მთლიანობის შესანარჩუნებლად.
IDOR დაუცველობა თავდამსხმელებს საშუალებას აძლევს, მანიპულირება მოახდინონ ობიექტის მითითებებზე (მაგ., URL-ში მომხმარებლის ID-ის შეცვლა) არაავტორიზებული რესურსების მისაღებად. ამან შეიძლება გამოიწვიოს მონაცემთა გაჟონვა, კონფიდენციალურობის დარღვევა და სისტემაში არაავტორიზებული ქმედებები. მაგალითად, თუ API-ის საბოლოო წერტილი, როგორიცაა /api/მომხმარებელი/123 თუ აპლიკაცია აბრუნებს მგრძნობიარე ინფორმაციას იმის დადასტურების გარეშე, რომ მომთხოვნს აქვს მისი ნახვის უფლებამოსილება, ის დაუცველი პირდაპირი ობიექტის მითითების წინაშე დგას.
IDOR-ის დაუცველობის გაგება და თავიდან აცილება უმნიშვნელოვანესია არა მხოლოდ უსაფრთხოების გუნდებისთვის, არამედ დეველოპერებისა და DevOps ინჟინრებისთვისაც. თავიდანვე ძლიერი წვდომის კონტროლის მექანიზმებისა და უსაფრთხო დიზაინის ნიმუშების უზრუნველყოფა ხელს უწყობს ამ რისკების შემცირებას წარმოებამდე. კითხვაზე პასუხის გაცემა „რა არის IDOR?“ არის ფუნდამენტური ნაბიჯი უსაფრთხო ნაგულისხმევი არქიტექტურისკენ.
რატომ ხდება IDOR კვლავ თანამედროვე API-ებში და Pipelines?
თანამედროვე უსაფრთხოების ჩარჩოების გავრცელების მიუხედავად, როგორიცაა OAuth, J.W.T.და RBACIDOR-ის დაუცველობები კვლავ გავრცელებულია.
IDOR-ის დაუცველობის გავრცელებული მიზეზები:
- ობიექტის იდენტიფიკატორების ვალიდაცია ავტორიზაციის იძულების გარეშე: დეველოპერებმა შეიძლება დაადასტურონ ობიექტის არსებობა (მაგ., მომხმარებელი, ბილდი ან ჟურნალის ფაილი), მაგრამ დაივიწყონ დაადასტურონ, აქვს თუ არა მიმდინარე მომთხოვნს მისი ნახვის ან შეცვლის უფლება.
- შინაგანი გამოაშკარავება dashboardწვდომის შემოწმების გარეშე: შიდა აპლიკაციები ხშირად „ნაგულისხმევად უსაფრთხოდ“ ითვლება და განლაგებულია როლებზე დაფუძნებული წვდომის შეზღუდვებით ან მათი გამოყენების გარეშე.
- თუ ვივარაუდებთ, რომ შიდა უდრის უსაფრთხოს: ქსელის საზღვრებზე (მაგ., IP თეთრ სიაში შეყვანა, VPN წვდომა) დაყრდნობა მომხმარებლის ან როლის შემოწმების განხორციელების ნაცვლად, დაუცველი პირდაპირი ობიექტების მითითებების შენარჩუნებას იწვევს.
ეს ხარვეზები ხშირად გამოწვეულია ობიექტის ID-ის ნებართვის პროქსიდად აღქმის არასწორად გაგებით, თუ რა არის IDOR?
რეალური სამყაროს მაგალითები:
- CI სისტემა უზრუნველყოფს URL-ებს აწყობის არტეფაქტების ჩამოსატვირთად, მაგრამ არ ადასტურებს, არის თუ არა მომთხოვნი ავტორიზებული გუნდის ნაწილი.
- შიდა მხარდაჭერა dashboard საშუალებას აძლევს თანამშრომლებს, მოძებნონ მომხმარებელთა პროფილები ადვილად გამოსაცნობი ID-ების გამოყენებით, როლებზე დაფუძნებული წვდომის დადასტურების გარეშე.
- გამართვის დროს მოხერხებულობისთვის, შინაგანად შემუშავებული დანამატები ან სკრიპტები მონაცემებს არაავტორიზებული საბოლოო წერტილების მეშვეობით ავლენენ.
თითოეული ეს აჩვენებს IDOR-ის რეალურ დაუცველობას, რომელიც გამოწვეულია წვდომის კონტროლის გამოტოვებით.
IDOR-ის ექსპოზიციის საერთო წერტილები რეალურ სამუშაო პროცესებში
IDOR-ის დაუცველობები ხშირად ვლინდება განვითარების პროცესში pipelines, შიდა ინსტრუმენტები და API-ები, როდესაც ობიექტის დონის წვდომის შემოწმებები უგულებელყოფილია.
რეალური სამყაროს მაგალითები:
- არტეფაქტების შექმნა: CI/CD პლატფორმებმა შეიძლება არტეფაქტები შეინახონ პროგნოზირებად URL-ებზე. თუ წვდომის შემოწმება არ არის, ეს საბოლოო წერტილები შეიძლება გახდეს დაუცველი პირდაპირი ობიექტის მითითებები.
- ჟურნალის ფაილები: იდენტიფიკატორების საფუძველზე ჟურნალების დაბრუნების ინსტრუმენტები მომთხოვნის როლის დადასტურების გარეშე შეიძლება IDOR-ის კიდევ ერთი დაუცველობის წყარო გახდეს.
- დამხმარე ინსტრუმენტები: სისტემები, რომლებიც შიდა წვდომას ავტორიზაციასთან აიგივებენ, დაუცველია არასწორად გამოყენების მიმართ გამოსაცნობი ობიექტების მითითებების გამო.
თეორიული ხარვეზები:
- კონფიგურაციის ფაილები: გამოაშკარავება /კონფიგურაცია/წარმოება ან მსგავსი საბოლოო წერტილების გამოყენება ავთენტიფიკაციისა და ავტორიზაციის აღსრულების გარეშე იწვევს დაუცველ პირდაპირ ობიექტურ მითითებას, განსაკუთრებით მაშინ, როდესაც საიდუმლოებებია ჩაშენებული.
ყველა შემთხვევაში, ნაკლი იმაში მდგომარეობს, რომ ვივარაუდოთ, რომ პირადობის მოწმობის ცოდნა საკმარისია; სწორედ ამას წარმოადგენს IDOR პრაქტიკაში.
როგორ აღმოვაჩინოთ და შევამოწმოთ IDOR Dev Tools-ში, CI Plugins-სა და შიდა API-ებში
აღმოჩენა გულისხმობს იმის გაგებას, თუ რა არის IDOR? და როგორ ვლინდება კოდში ობიექტზე წვდომის შესახებ ვარაუდები.
IDOR-ის დაუცველობის ნიშნები:
- საბოლოო წერტილები, რომლებიც აბრუნებენ მგრძნობიარე მონაცემებს მხოლოდ ობიექტის ID-ების საფუძველზე.
- შესაძლებელია ისეთი ნიმუშები, რომლებიც ობიექტების ჩამოთვლას გვთავაზობს.
- შიდა ინსტრუმენტები მინიმალური ან საერთოდ არანაირი წვდომის შეზღუდვით, მომხმარებლის როლის მიხედვით.
გამოვლენის სტრატეგია:
- შეაფასეთ, თუ როგორ ეყრდნობიან საბოლოო წერტილები მომხმარებლის მიერ მოწოდებულ ობიექტის მითითებებს.
- დაადგინეთ, სად აკლია ან არ არის გამოყენებული წვდომის ლოგიკა.
- მოთხოვნების სიმულირება ჩაჭრის ხელსაწყოების ან API ტესტერების გამოყენებით, იმის დასადასტურებლად, დაბლოკილია თუ არა არაავტორიზებული წვდომა.
რეალურ სამყაროში აუდიტის მიზნები:
- ისეთი საბოლოო წერტილები, როგორიცაა /build/{id}/არტეფაქტი.
- Dashboards კონფიგურაციის დეტალების რენდერინგი ღია მოთხოვნის პარამეტრებიდან.
- ჟურნალები ან მეტრიკის პანელები, რომლებიც იყენებენ ID-ებს წვდომის დადასტურების გარეშე.
IDOR?-ის გაგება დეველოპერულ გუნდებს საშუალებას აძლევს პროაქტიულად გადაამოწმონ ობიექტის უსაფრთხოება.
როგორ ავიცილოთ თავიდან IDOR-ის დაუცველობები Pipelineდა API-ები
პრევენცია ა IDOR-ის დაუცველობა DevSecOps-ის ერთ-ერთი მთავარი მიზანია. პერიმეტრის დაცვაზე დაყრდნობის ნაცვლად, აღსრულება უნდა მოხდეს განვითარების სასიცოცხლო ციკლის ყველა ეტაპზე.
DevSecOps-ზე ორიენტირებული ზომები:
- ავტომატური ტესტირების დროს CI/CD: არაავტორიზებული წვდომის სიმულირება, რათა უზრუნველყოთ თქვენი pipeline დაჭერები და დროშები გამოვლენილია დაუცველი პირდაპირი ობიექტის მითითებები.
- SAST მდე SCA შერწყმის ბლოკირებით: გამოიყენეთ სტატიკური და კომპოზიციური ანალიზის ინსტრუმენტები, რათა დაბლოკოთ ცვლილებები, რომლებიც იწვევს ან აუარესებს IDOR-ის დაუცველობები.
- საბოლოო წერტილის აუდიტები შემუშავების დროს: კოდის მიმოხილვებში ობიექტის დონის წვდომის დასაბუთებისა და დოკუმენტაციის მოთხოვნა.
- შიდა ინსტრუმენტების სახელმძღვანელო მიმოხილვები: არ გამოტოვოთ მიმოხილვები მხოლოდ იმიტომ, რომ ინსტრუმენტი შიდაა. ბევრი დაუცველი პირდაპირი ობიექტის მითითებები ისინი შიდა სისტემებში იმალება.
როგორ ავტომატიზირებს Xygeni IDOR-ის აღმოჩენას და პრევენციას
IDOR-ის დაუცველობების მასშტაბური პრევენცია ნიშნავს ხელით განხილვებიდან უწყვეტ, ავტომატიზირებულ აღსრულებაზე გადასვლას. სწორედ აქ ქსიგენი მოდის შემოსული
აი, როგორ დაგეხმარებათ Xygeni დაუცველი ობიექტების მითითებების დაჭერასა და დაბლოკვაში მათ გაგზავნამდე:
- IDOR-ის ნიმუშების რეალურ დროში აღმოჩენა
Xygeni აანალიზებს საბოლოო წერტილის ქცევას და საწყისი კოდის ცვლილებებს თქვენს მასშტაბით CI/CD სამუშაოებითუ ის აღმოაჩენს ობიექტზე პირდაპირ წვდომას სათანადო ავტორიზაციის შემოწმების გარეშე, მაგალითად /api/მომხმარებელი/123 როლის დადასტურების გარეშე გამოვლენის შემთხვევაში, ის დაუყოვნებლივ აჩენს განგაშს. - დაუცველი საბოლოო წერტილების წინასწარი განლაგების ბლოკირება
Guardrails თქვენს CI-ში pipelines წყვეტს აწყობას, როდესაც აღმოჩენილია არაავტორიზებული ობიექტის მითითება. შეგიძლიათ დააყენოთ ეს guardrails ბილდის გასატეხად, PR-ის ჩასაშლელად ან განსახილველად მონიშვნისთვის. ის მუშაობს GitHub Actions-თან, GitLab CI-თან, Jenkins-თან და სხვა. - აკავშირებს დასკვნებს PR-ებთან და აუდიტის კვალთან
ყველა აღმოჩენა დაკავშირებულია იმასთან, pull request, commitდა მონაწილე დეველოპერი. ეს გაძლევთ მკაფიო თვალყურის დევნების საშუალებას, თუ ვინ შეიტანა ცვლილება, ვინ გადახედა მას და შეესაბამება თუ არა ის პოლიტიკას.
რეალური სამყაროს მაგალითი
დეველოპერი ახალ საბოლოო წერტილს გვთავაზობს:
მიიღეთ /build/7020/artifact.zip
Xygeni ამოწმებს, დაცულია თუ არა build ID წვდომის კონტროლით. თუ არა:
- PR მონიშნულია გაფრთხილებით
- CI pipeline ბლოკავს განლაგებას
- აუდიტის ჟურნალი აღრიცხავს მოვლენას, აჩვენებს, თუ ვინ განახორციელა ცვლილება და რა უნდა გამოსწორდეს.
Xygeni-ის ავტომატიზირებული დაცვა უზრუნველყოფს, რომ თქვენ შეაჩერებთ IDOR-ის დაუცველობებს იქ, სადაც ისინი იწყება, თქვენს კოდში და pipelines.
დასკვნა: IDOR-ი ზედამხედველობას დარღვევად აქცევს
მაშ ასე, რა არის IDOR? ეს არის დაუცველობა, რომელიც წარმოიქმნება მაშინ, როდესაც კოდი ვარაუდობს, რომ ID-ის ფლობა წვდომის ტოლფასია. ის გავლენას ახდენს შიდა ინსტრუმენტებზე ისევე ხშირად, როგორც საჯაროდ განთავსებულ საბოლოო წერტილებზე.
დაუცველი პირდაპირი ობიექტების მითითებებისგან დაცვა ნიშნავს წვდომის ყოველ ჯერზე დადასტურებას. ავტომატიზირეთ აღმოჩენა, დაბლოკეთ სახიფათო განლაგებები და აღასრულეთ უსაფრთხოების პოლიტიკა თქვენს სტეკზე.
ძირითადი პრაქტიკის შეჯამება:
- ობიექტის დონის ავტორიზაციის აღსრულება.
- არასოდეს ჩათვალოთ, რომ შიდა ტოლია უსაფრთხო.
- გაიგეთ, რა არის IDOR? და როგორ ვლინდება ის თქვენს კოდში.
- IDOR-ის დაუცველობების მონიტორინგი მთელს მსოფლიოში pipeline.
- დაცვის ავტომატიზაცია ისეთი ინსტრუმენტებით, როგორიცაა Xygeni.
IDOR დაუცველობას არ სჭირდება გაფართოებული ექსპლოიტი, მხოლოდ უგულებელყოფილი მითითება. დაიცავით ის, სანამ ვინმე სხვა იპოვის!
