TL; DR
API დარღვევების უმეტესობა ავტორიზაციის დარღვევას უკავშირდება და არა ეგზოტიკურ ექსპლოიტებს. OWASP API Security Top 10-ის ხუთი ტოპ კატეგორიიდან სამი ავტორიზაციის ჩავარდნებია, რომელთაგან ყველაზე ხშირად გვხვდება: ბურთი.
თქვენ არ შეგიძლიათ უზრუნველყოთ ის, რისი არსებობის შესახებაც არ იცით. ინვენტარის არასწორი მართვა არის საკუთარი სახელწოდების OWASP რისკის კატეგორია და ეს არის საფუძველი, რომელზეც ყველა სხვა კონტროლია დამოკიდებული.
დააფიქსირეთ ექსპოზიცია განლაგებამდე და არა მის შემდეგ. კოდისა და API სპეციფიკაციების სტატიკური ანალიზი აღმოაჩენს გაფუჭებულ საბოლოო წერტილს a-ში. pull request, ერთის ფასად commit; გაშვების დროს ტესტირება იმავე პრობლემას რეალურ დროში პოულობს, ინციდენტის ფასად.
ეს არის საკონტროლო სია, რომელიც მუდმივად უნდა შესრულდეს. ყოველ pull request, არა გამოშვებამდელი მიმოხილვა: 10 პრაქტიკა, ინვენტარიზაციისა და ავტორიზაციისგან დაწყებული, სიჩქარის შეზღუდვით, რეაგირების მონაცემების ზემოქმედებითა და მესამე მხარის ნდობით დამთავრებული.
თქვენი API შეტევის ზედაპირი ყოველ ჯერზე იზრდება pull requestგუნდების უმეტესობა მხოლოდ მაშინ აღმოაჩენს, რომ საბოლოო წერტილი დაუცველია, როდესაც ის აქტიურდება და ტრაფიკს იღებს, რაც იმას ნიშნავს, რომ შეკეთება, რომლის ფასიც დაჯდებოდა, commit განხილვის პროცესშია ინციდენტის ანგარიშის ღირებულება. ეს სახელმძღვანელო განიხილავს API-ის უსაფრთხოების საუკეთესო პრაქტიკებს, რომლებიც რეალურად მუშაობს წარმოებაში და ორგანიზებულია საკონტროლო სიის სახით, რომლის გამოყენებაც დღესვე შეგიძლიათ თქვენივე კოდის ბაზაზე და არა აბსტრაქტული პრინციპების სიის სახით, რომელსაც არავინ ახორციელებს.
რატომ გამოიყურება API უსაფრთხოების საუკეთესო პრაქტიკა ახლა განსხვავებულად
API-ები ოდესღაც სისტემებს შორის შემაერთებელი ქსოვილი იყო. ახლა ისინი თითქმის ყველაფრის ძირითადი ინტერფეისია: მობილური აპლიკაციები, პარტნიორული ინტეგრაციები, ხელოვნური ინტელექტის აგენტები, შიდა მიკროსერვისები. ამ ცვლილებამ შეცვალა ის, რაც API-ს დაცვის საუკეთესო პრაქტიკამ უნდა მოიცვას. აღარ არის საკმარისი მხოლოდ თქვენს მიერ დოკუმენტირებული API-ს დაცვა; თქვენ უნდა გაითვალისწინოთ ის API-ები, რომლებიც თქვენმა გუნდებმა შექმნეს და რომელთა ჩაწერაც დაავიწყდათ.
ორი რიცხვი განმარტავს, თუ რატომ არის ეს მნიშვნელოვანი. OWASP API უსაფრთხოების ტოპ 10 ავტორიზაციის პრობლემების გატეხვას ხუთი ძირითადი კატეგორიიდან სამში ათავსებს, რაც იმას ნიშნავს, რომ რეალურ სამყაროში API ინციდენტების უმეტესობა რამდენიმე თავიდან აცილებადი ნიმუშით იწყება და არა ეგზოტიკური ნულოვანი დღეებით. ინვენტარიზაციის არასწორი მართვა კი იმავე სიაშია, როგორც საკუთარი რისკების კატეგორია: გუნდები API-ების მეშვეობით ხდებიან გატეხილი, რომელთა შესახებაც არ იცოდნენ.
ეს არის თემა, რომელიც ქვემოთ მოცემულ თითოეულ პუნქტს მოიცავს. API-ის მართვის კარგი საუკეთესო პრაქტიკა იწყება იმის ცოდნით, თუ რა გაქვთ და არა მხოლოდ იმის დაცვით, რაც დოკუმენტირება გახსოვთ.
API უსაფრთხოების საუკეთესო პრაქტიკები ერთი შეხედვით
დეტალურ საკონტროლო სიამდე, აქ მოცემულია მისი მოკლე ვერსია: რა უნდა განხორციელდეს, რისგან იცავს ის სინამდვილეში და რამდენად სასწრაფოდ.
„სავალდებულო“ სტრიქონი განიხილეთ, როგორც ნებისმიერი API-სთვის, შიდა თუ საჯაროდ განკუთვნილი, უცვლელი საბაზისო ხაზი. „მაღალი“ პრიორიტეტის მქონე ელემენტები განასხვავებს პროგრამას, რომელიც პრობლემებს აფიქსირებს. pull request ისეთიდან, რომელიც ინციდენტის ანგარიშში აღმოჩნდება.
API უსაფრთხოების საუკეთესო პრაქტიკის საკონტროლო სია
1. თავდაცვის სისტემის შექმნამდე შეადგინეთ სრული ინვენტარი
თქვენ არ შეგიძლიათ დაიცვათ ისეთი საბოლოო წერტილი, რომლის არსებობის შესახებაც არ იცით. დაიწყეთ API დაცვის ყველა საუკეთესო პრაქტიკის კვლევა რეალური ინვენტარით: თითოეული საბოლოო წერტილი, მისი მეთოდი, მისი გზა, სერვისი და მოდული, რომელსაც ის ეკუთვნის და საჭიროებს თუ არა ავთენტიფიკაციას. ეს ინფორმაცია ერთად ამოიღეთ საწყისი კოდიდან და თქვენი API სპეციფიკაციებიდან (OpenAPI, Swagger) და არა მხოლოდ დოკუმენტაციიდან, რადგან ამ ორ წერტილს შორის არსებული უფსკრული სწორედ ის ადგილია, სადაც დავიწყებული და ობოლი საბოლოო წერტილები იმალება.
სად ჯდება Xygeni: Xygeni API-ის უსაფრთხოება ამ ინვენტარს პირდაპირ თქვენი აპლიკაციის საწყისი კოდიდან და API სპეციფიკაციებიდან აშენებს, ავლენს თქვენი გუნდის მიერ დოკუმენტირებული საბოლოო წერტილების და იმ წერტილების ზედაპირს, რომლებიც არავის დაუფიქსირებია, სანამ რომელიმე მათგანი წარმოებაში მივა.
2. ობიექტისა და ფუნქციის დონეზე ავტორიზაციის აღსრულება
ობიექტის დონის და ფუნქციის დონის ავტორიზაციის დარღვევა მუდმივად პირველ ადგილზეა OWASP API-ის უსაფრთხოების ტოპ 10-ში. საუკეთესო პრაქტიკა არ არის „ავტორიზაციის დამატება“, არამედ შემოწმება, ყოველ მოთხოვნაზე, არის თუ არა ამ კონკრეტულ მომხმარებელს წვდომა დაშვებულია ამ კონკრეტული ობიექტისდა არა მხოლოდ ის, საერთოდ არიან თუ არა ისინი შესულები სისტემაში. ავთენტიფიკაცია პასუხობს ვინ არის ადამიანი. ავტორიზაცია პასუხობს იმას, თუ რას შეეხებიან ისინი და ეს ყოველ ჯერზე უნდა შემოწმდეს და არა ვალიდური ტოკენიდან გამომდინარე.
3. API-ს მიერ მიღებული ყველაფრის დადასტურება და დეზინფექცია
ყველა პარამეტრი, სათაური და ძირითადი ველი არასანდო შეყვანაა, სანამ საპირისპირო არ დამტკიცდება. განახორციელეთ სქემის მკაცრი ვალიდაცია, უარყავით მოულოდნელი ველები (ეს თქვენი დაცვაა მასობრივი მინიჭებისგან) და არასოდეს ენდოთ კლიენტის მიერ მოწოდებულ მონაცემებს წვდომის ფარგლების ან ფასების ლოგიკის დასადგენად.
4. სიჩქარის ლიმიტი და გაზის მექანიზმი შექმნილია და არა როგორც დამატებითი იდეა
შეუზღუდავი რესურსების მოხმარება საშუალებას აძლევს ერთ კლიენტს ამოწუროს თქვენი ინფრასტრუქტურა ან გაზარდოს ხარჯები გამოყენებისთვის გადახდილი ბექენდ სერვისებზე. დააწესეთ ლიმიტები თითოეული საბოლოო წერტილისთვის, თითოეული მომხმარებლისთვის და თითოეული API გასაღებისთვის და დარწმუნდით, რომ ლიმიტები შეესაბამება ოპერაციის რეალურ ღირებულებას და არა ყველგან ფიქსირებულ რიცხვს.
5. ყველა პასუხი პოტენციურ მონაცემთა გაჟონვად მიიჩნიეთ
მონაცემების გადაჭარბებული ექსპოზიცია ხდება მაშინ, როდესაც API კლიენტის საჭიროებაზე მეტ ინფორმაციას აბრუნებს და მის გასაფილტრად ფრონტენდს ეყრდნობა. ეს ჩვევაა და არა იშვიათი შეცდომა, და ეს API-ს დაცვის საუკეთესო პრაქტიკის ერთ-ერთი ყველაზე გავრცელებული დარღვევაა, რადგან ის უხილავია მანამ, სანამ ვინმე არ შეამოწმებს ნედლ პასუხებს რენდერირებული ინტერფეისის ნაცვლად.
სად ჯდება Xygeni: Xygeni API Security პირად ინფორმაციაზე ზემოქმედების შესახებ პირდაპირ API პასუხებში აფიქსირებს, ზედმეტად გაზიარებას გამოგზავნამდე აფიქსირებს და არა მას შემდეგ, რაც მომხმარებელი ან მარეგულირებელი შეამჩნევს ამას.
6. შეინახეთ API-ების ზუსტი და განახლებული ინვენტარი, მათ შორის მოძველებული ინვენტარის
არასწორი ინვენტარი მენეჯმენტი OWASP სიაში ცალკე კატეგორიას წარმოადგენს გარკვეული მიზეზის გამო: მოძველებული API ვერსიები და დაუდასტურებელი სამონტაჟო გარემო ხშირად კვლავ ხელმისაწვდომია და ხშირად დაუცველია მას შემდეგაც, რაც ვინმემ მათი არსებობის შესახებ გაიხსენა. API მართვის საუკეთესო პრაქტიკის პროგრამა უნდა მოიცავდეს დემონტაჟს და არა მხოლოდ აღმოჩენას.
7. შეამოწმეთ, თუ რას ენდობა თქვენი API მესამე მხარისგან
მესამე მხარის API-ების არასაიმედო გამოყენება არასაკმარისად შეფასებული რისკია. დეველოპერები, როგორც წესი, სხვა API-დან მომდინარე მონაცემებს უფრო მეტად ენდობიან, ვიდრე მომხმარებლის მიერ შეყვანილ მონაცემებს, რაც სრულიად საპირისპიროა; მესამე მხარის ინტეგრაცია კვლავ გარე, დაუდასტურებელი წყაროა და იმავე გზით უნდა დადასტურდეს.
8. დეველოპერებს წარუდგინეთ მტკიცებულებები და არა მხოლოდ შეტყობინებები
დასკვნა, რომელიც წერს, რომ „ამ საბოლოო წერტილზე ავტორიზაცია გატეხილია“, არის ბილეთი, რომლის გამოსწორებამდეც კი უნდა გამოიძიოს ადამიანმა. დასკვნა, რომელიც ზუსტ ფაილზე, კლასზე, მეთოდსა და ხაზზე მიუთითებს, არის ის, რაზეც დეველოპერს შეუძლია დაუყოვნებლივ იმოქმედოს. ეს საუკეთესო პრაქტიკაა თავად უსაფრთხოების პროგრამისთვის და არა მხოლოდ API-სთვის: აღმოჩენები, რომლებიც გამოსწორებამდე გამოკვლევას მოითხოვს, ყველაფერს ანელებს.
სად ჯდება Xygeni: Xygeni API Security-ის ყველა აღმოჩენა მიუთითებს ზუსტ დამმუშავებელზე, ფაილზე, კლასზე, მეთოდსა და ხაზზე, რომელმაც ის შემოიღო, ამიტომ გამოსწორება იწყება აღმოჩენისთანავე.
9. ექსპოზიციის დადგენა განლაგებამდე და არა მის შემდეგ
Runtime API ტესტირება გეუბნებათ, რომ საბოლოო წერტილი დაუცველია მას შემდეგ, რაც ის უკვე ემსახურება ტრაფიკს. კოდისა და API სპეციფიკაციების სტატიკური ანალიზი იმავე დაუცველობას პოულობს, სანამ ის ჯერ კიდევ იმყოფება. pull request, როდესაც შეკეთება ერთი ღირს commit ინციდენტზე რეაგირების ნაცვლად. API-ის მართვის უძლიერესი საუკეთესო პრაქტიკა სტატიკურ აღმოჩენას პირველ ფენად მიიჩნევს, ხოლო გაშვების დროს ტესტირებას უკვე არსებულის მეორე, დამატებით შემოწმებად.
სად ჯდება Xygeni: Xygeni API Security დიზაინს სტატიკური აქვს, გამოშვებამდე აანალიზებს კოდსა და სპეციფიკაციებს და მუშაობს მასთან ერთად. Xygeni DAST უკვე წარმოებაში მყოფი აპლიკაციების გაშვების დროის დაფარვისთვის.
10. API რისკი შეინახეთ თქვენი აპლიკაციის სხვა რისკებთან ერთად
API-ები იზოლირებულად არ იშლება. API-ის დაუცველობა ხშირად დამოკიდებულების პრობლემის, არასწორად კონფიგურირებული სისტემის შემდეგ ჩნდება. pipelineან გაჟონილი საიდუმლო. API-ის უსაფრთხოების ცალკე ინსტრუმენტად მიჩნევა საკუთარი კონსოლით ნიშნავს ამ კონტექსტის დაკარგვას ზუსტად მაშინ, როდესაც ის ყველაზე მნიშვნელოვანია.
სად ჯდება Xygeni: API უსაფრთხოება გვერდით დგას SAST, SCA, საიდუმლოებები, IaCდა DAST ერთ Xygeni პლატფორმაზე, ამიტომ API აღმოჩენა ჩანს კოდისა და დამოკიდებულების რისკის გვერდით, რომელმაც ის წარმოქმნა და არა ცალკეულში. login.
საკონტროლო სიის ჩვევად გადაქცევა
API-ის უსაფრთხოების საუკეთესო პრაქტიკა მხოლოდ უწყვეტი პრაქტიკის სახით მუშაობს და არა გაშვებამდელი მიმოხილვის სახით. ჩაატარეთ ინვენტარი და სტატიკური ანალიზი ყველა pull requestდა არა კვარტალში ერთხელ. ახალ, დაუდოკუმენტირებელ საბოლოო წერტილს ისევე მოეპყარით, როგორც ახალ, დაუდოკუმენტირებელ დამოკიდებულებას: როგორც რაღაცას, რაც დაუყოვნებლივ უნდა იქნას გამოკვლეული და არა საბოლოოდ. და გაზომეთ თქვენი API დაცვის საუკეთესო პრაქტიკა ისევე, როგორც გაზომავთ ნებისმიერ სხვა ნაწილს. SDLC, იმით, თუ რამდენად ადრე შეამჩნევთ პრობლემას და არა მხოლოდ იმით, საერთოდ შენიშნეთ თუ არა ის.
სწრაფი პასუხები: API უსაფრთხოების საუკეთესო პრაქტიკის კითხვა-პასუხი
ძირითადი Takeaways
- ინვენტარი დაცვაზე წინ დგას. თქვენ არ შეგიძლიათ გამოიყენოთ ავტორიზაცია, სიჩქარის ლიმიტები ან მონაცემთა კონტროლი ისეთ საბოლოო წერტილზე, რომლის არსებობის შესახებაც არ იცით და ინვენტარის არასათანადო მართვა თავისთავად დასახელებული რისკია OWASP API Security Top 10-ში.
- დარღვევების უმეტესობა ავტორიზაციაში, და არა მხოლოდ ავთენტიფიკაციაში, ხდება. OWASP API-ის უსაფრთხოების ხუთი ძირითადი რისკიდან სამი ავტორიზაციის ჩავარდნაა. იმის შემოწმება, თუ ვინ არის ადამიანი, არ არის იგივე, რაც იმის შემოწმება, თუ რაზე აქვს მას შეხების უფლება.
- სტატიკური ანალიზი იჭერს იმას, რასაც გაშვების დროს ტესტირება ძალიან გვიან იჭერს. ექსპოზიციის პოვნა pull request ერთი ღირს commitწარმოებაში მისი პოვნა ინციდენტის ხარჯებს გულისხმობს.
- ყველა პასუხი პოტენციური მონაცემთა გაჟონვაა. მონაცემთა გადაჭარბებული გამოყენება ჩვევაა და არა იშვიათი შეცდომა, და ის შეუმჩნეველია მანამ, სანამ ვინმე არ შეამოწმებს ნედლ API პასუხებს რენდერირებული ინტერფეისის ნაცვლად.
- API უსაფრთხოების საუკეთესო პრაქტიკა მხოლოდ უწყვეტი ჩვევის სახით მუშაობს, ყოველ pull requestდა არა კვარტალური მიმოხილვა ან გაშვებამდელი საკონტროლო სია.
- API რისკი არ უნდა იყოს ცალკე ინსტრუმენტში. API დაცვის ყველაზე სასარგებლო საუკეთესო პრაქტიკა API-ის დასკვნებს იმავე რისკის სურათის ნაწილად მიიჩნევს, როგორც კოდი, დამოკიდებულება და pipeline security, არა იზოლირებული კონსოლი.
კითხვა-პასუხი
რომელია API უსაფრთხოების ყველაზე მნიშვნელოვანი საუკეთესო პრაქტიკა დასაწყებად?
დაიწყეთ ინვენტარიზაციით. თქვენ არ შეგიძლიათ გამოიყენოთ ავტორიზაციის შემოწმებები, სიჩქარის ლიმიტები ან მონაცემთა ზემოქმედების კონტროლი ისეთ საბოლოო წერტილზე, რომლის არსებობის შესახებაც არ იცით, ამიტომ თითოეული API საბოლოო წერტილის სრული და ზუსტი ინვენტარი არის საფუძველი, რომელზეც ამ საკონტროლო სიაში ყველაფერი დანარჩენი დამოკიდებულია.
რა განსხვავებაა API უსაფრთხოების საუკეთესო პრაქტიკასა და ზოგადი აპლიკაციის უსაფრთხოების საუკეთესო პრაქტიკას შორის?
API-ები ისეთ რისკებს შეიცავს, რომლებსაც AppSec-ის ზოგადი პრაქტიკა სრულად არ მოიცავს: ობიექტისა და ფუნქციის დონის ავტორიზაცია მასშტაბურად, მესამე მხარის API პასუხების ნდობის სპეციფიკური საფრთხე და მოძველებული ან დაუდოკუმენტებელი საბოლოო წერტილების თვალყურის დევნების სირთულე. API-ების უსაფრთხოების საუკეთესო პრაქტიკა არის აპლიკაციის უსაფრთხოების საუკეთესო პრაქტიკა, რომელიც გამოიყენება შეტევის ზედაპირის იმ ნაწილებზე, რომელთა დავიწყება ყველაზე ადვილია.
API-ის უსაფრთხოების ტესტირება უნდა ჩატარდეს დანერგვამდე თუ მის შემდეგ?
ორივე, მაგრამ ყველაზე მაღალი ბერკეტის წერტილი ადრეა. კოდისა და API სპეციფიკაციების სტატიკური ანალიზი აფიქსირებს ექსპოზიციას, სანამ ის ჯერ კიდევ pull requestგაშვების დროს ტესტირება (DAST) შემდეგ ამოწმებს, თუ რა არის რეალურად ხელმისაწვდომი აპლიკაციის გაშვების შემდეგ. მხოლოდ გაშვების დროს ტესტირებაზე დაყრდნობა ნიშნავს, რომ ყველა შესწორება საჭიროზე მეტი ჯდება.
რა სიხშირით უნდა განახლდეს API ინვენტარი?
უწყვეტად, იდეალურ შემთხვევაში ყოველ pull requestერთხელ შედგენილი და კვარტალურად გადახედილი ინვენტარი ახალი საბოლოო წერტილის გამოშვებისთანავე უკვე მოძველებულია, რაც ზუსტად ის ხარვეზია, რომელსაც არასათანადო ინვენტარიზაციის მართვა იყენებს.
API მართვის საუკეთესო პრაქტიკა ვრცელდება თუ არა შიდა API-ებზე და არა მხოლოდ საჯაროდ განკუთვნილებზე?
დიახ. შიდა API-ები ხშირად უფრო დაბალ უსაფრთხოების ნიშნულზეა დაყენებული, რადგან ისინი „ინტერნეტთან კონტაქტში არ არიან“, თუმცა ისინი მაინც ამუშავებენ მგრძნობიარე მონაცემებს და მათზე წვდომა შეუძლია ნებისმიერ პირს, ვისაც აქვს შიდა ქსელზე წვდომა, მათ შორის კომპრომეტირებულ ანგარიშს ან ინსაიდერს.
