ყოველ pull request რაც ამატებს ან ცვლის საბოლოო წერტილს, ცვლის თქვენი API შეტევის ზედაპირს. API უსაფრთხოების ინსტრუმენტების უმეტესობა ამას ვერ ამჩნევს მანამ, სანამ საბოლოო წერტილი არ იქნება აქტიური და უკვე არ მიიღებს ტრაფიკს. ამ დროისთვის, გამოსწორება აღარ არის კოდის მიმოხილვის ერთი ხაზის ცვლილება, ეს არის ინციდენტზე რეაგირების საუბარი.
API-ის უსაფრთხოება არის რისკების პოვნისა და დახურვის პრაქტიკა, თუ როგორ ავლენს აპლიკაცია თავის საბოლოო წერტილებს: ვის შეუძლია მათი გამოძახება, რა მონაცემებს აბრუნებენ და ასრულებენ თუ არა ისინი დოკუმენტაციაში მითითებულს.
ამ პრობლემისთვის შექმნილი ხელსაწყოების უმეტესობა API-ს გაშვების დროს, გარედან ამოწმებს, ისევე როგორც თავდამსხმელი. ეს მიდგომა მუშაობს, მაგრამ მხოლოდ API-ს განლაგების შემდეგ. ქსიგენი იღებს ადრინდელ გზას: ის კითხულობს თქვენს საწყის კოდს და თქვენი API სპეციფიკაციას, სანამ ერთი მოთხოვნა საბოლოო წერტილს მიაღწევს.
API-ის ტესტირების ოთხი გზა და თითოეული მათგანის პასუხები
მოწიფული პროგრამების უმეტესობა ამ პროგრამებიდან ერთზე მეტს იყენებს:
- სტატიკური ტესტირება განლაგებამდე აანალიზებს საწყისი კოდისა და API სპეციფიკაციების ანალიზს. ის პასუხობს კითხვას „რა გამოვავლინეთ ახლახან?“. ეს სტატია სწორედ ამ მიდგომაზეა ორიენტირებული.
- დინამიური ტესტირება (DAST) რეალურ ტრაფიკს აგზავნის გაშვებულ API-ზე და აკვირდება, თუ როგორ რეაგირებს ის. ის პასუხობს კითხვას: „რა არის ამჟამად რეალურად ხელმისაწვდომი და გამოსაყენებელი?“
- საეჭვო არასწორად ფორმირებულ ან მოულოდნელ შეყვანას ბოლო წერტილებში აგზავნის ზედაპირულ კრახებსა და კიდეების ჩავარდნებში. ის პასუხობს კითხვას „რა იშლება შეყვანის დროს, რომელსაც არ ველოდით?“
- ხელით შეღწევადობის ტესტირება ავტომატიზირებული ხელსაწყოების მიერ გამოტოვებული ლოგიკური ხარვეზების აღმოსაჩენად ადამიანის განსჯას ამატებს. ის პასუხობს კითხვას, თუ რას შეაერთებდა ჭკვიანი თავდამსხმელი?
არცერთი მათგანი არ ცვლის სხვებს. ისინი სხვადასხვა კითხვას პასუხობენ სასიცოცხლო ციკლის სხვადასხვა ეტაპზე და ყველაზე ხშირად პროგრამების შორის არსებული ხარვეზი პირველია.
რატომ ხედავენ API უსაფრთხოების ინსტრუმენტების უმეტესობა რისკს ძალიან გვიან
Runtime API-ის უსაფრთხოების ტესტირება აგზავნის ტრაფიკს რეალურ აპლიკაციაში და აკვირდება, თუ როგორ რეაგირებს ის. ეს არის ლეგიტიმური და აუცილებელი ფენა. ის ასევე, კონსტრუქციით, შეფერხების ინდიკატორია: საბოლოო წერტილი უნდა არსებობდეს, იყოს განლაგებული და ხელმისაწვდომი, სანამ Runtime სკანერი რამეს იტყვის მის შესახებ. რასაც ის აღმოაჩენს, უკვე გამოვლენილი იყო იმდენი ხნის განმავლობაში, რამდენი ხანიც დასჭირდა სკანირების გასაშვებად.
ამ დროის პრობლემის ქვეშ მეორე ხარვეზიც იმალება. გაშვების დროს ინსტრუმენტებს მხოლოდ იმის შემოწმება შეუძლიათ, რისი არსებობის შესახებაც იციან. თუ საბოლოო წერტილი არასდროს ყოფილა დოკუმენტირებული, ან OpenAPI სპეციფიკაცია მოძველდა ახალი მარშრუტის გაგზავნისთანავე, გაშვების დროს სკანერს არ აქვს საშუალება იცოდეს, რომ ის იქ არის. ის ამოწმებს რუკას და არა ტერიტორიას.
სტატიკური API უსაფრთხოების ტესტირება ორივე ხარვეზს ავსებს შემოწმების იმ ადგილას გადატანით, სადაც საბოლოო წერტილია განსაზღვრული: თქვენი კოდი და თქვენი API სპეციფიკაცია, განლაგებამდე. იგივე pull request რომელიც წარმოგვიდგენს საბოლოო წერტილს, არის pull request რაც მის რისკს ავლენს.
რას ნიშნავს სინამდვილეში სტატიკური API უსაფრთხოება
Xygeni თქვენი API ინვენტარს ორი წყაროდან აშენებს: თქვენი აპლიკაციის საწყისი კოდიდან და თქვენი API სპეციფიკაციებიდან, მათ შორის OpenAPI-დან და Swagger-დან.
მხოლოდ სპეციფიკაციების ინვენტარი აჩვენებს საბოლოო წერტილებს, რომელთა დოკუმენტირებაც ვინმეს დამახსოვრებული ჰქონდა. მხოლოდ კოდის ინვენტარი აჩვენებს რა არსებობს, მაგრამ არა აუცილებლად იმას, თუ როგორ იყო ის განკუთვნილი. ორივეს წაკითხვა სრულ სურათს გაძლევთ: როგორც საბოლოო წერტილებს, რომლებიც თქვენმა გუნდებმა დააფიქსირეს, ასევე იმ წერტილებს, რომლებიც არავის დაუფიქსირებია.
ეს ინვენტარი არის საფუძველი, რომელზეც ყველაფერი დანარჩენი აშენებულია:
- აღმოჩენილი API-ების ჯამური რაოდენობა და რისკის ქვეშ მყოფი აქტივების გაზომვა საწყის დონესთან შედარებით
- HTTP მეთოდით დაყოფილი საბოლოო წერტილები
- სერვისების მიხედვით დაჯგუფებული პრობლემები
- ყველა საბოლოო წერტილი თავისი მეთოდით, ბილიკით, სერვისით, მოდულით, ავტორიზაციის მდგომარეობითა და რისკის ქულით
თქვენი ინჟინერიის ლიდერები ხედავენ თქვენი API ზედაპირის ფორმას ერთი ბილეთის გახსნის გარეშე.
Xygeni-ის მიერ ნაპოვნი ყველა საბოლოო წერტილი, თავისი მეთოდით, ავთენტიფიკაციის მდგომარეობითა და რისკის ქულით, კოდისა და სპეციფიკაციის ერთად აგებული.
Production note ნებისმიერი API Security-ის ეკრანის ანაბეჭდიდან ხელოვნური ინტელექტის ტრიაჟის პანელის ჩამოჭრა.
OWASP API-ის უსაფრთხოების ტოპ 10-თან მიმაგრებული
დასკვნები ასახავს თქვენი უსაფრთხოების გუნდების და აუდიტორების მიერ უკვე გამოყენებულ ჩარჩოს. Xygeni აფიქსირებს რისკს OWASP API-ის მეშვეობით. ტოპ 10 (2023):
ერთი კატეგორია განზრახ არ არის მოცემული. API6, მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა, მოითხოვს იმის გაგებას, თუ რა უნდა დაუშვას ბიზნეს პროცესმა და ვერცერთი სტატიკური ანალიზატორი ვერ აფიქსირებს ამას სანდოდ. ნებისმიერი გამყიდველი, რომელიც საპირისპიროს ამტკიცებს, თქვენ გყიდით მონიშვნის ველს. ეს თქვენი საფრთხის მოდელირებისა და შეღწევადობის ტესტერების საკითხში რჩება.
ყველა დასკვნა ერთნაირი არ არის: მონაცემთა მგრძნობელობა და ტოქსიკური კომბინაციები
დასკვნების ბრტყელი სია არაავთენტიფიცირებულ ჯანმრთელობის შემოწმების საბოლოო წერტილს ისევე ეპყრობა, როგორც არაავთენტიფიცირებულ საბოლოო წერტილს, რომელიც მომხმარებლის ჩანაწერებს აბრუნებს. ეს ერთი და იგივე პრობლემა არ არის და პრიორიტეტიზაციის მოდელი, რომელიც მათ იდენტურად აფასებს, თქვენს გუნდებს სიის იგნორირებას ასწავლის.
Xygeni ახდენს თითოეული საბოლოო წერტილის მიერ დამუშავებული მონაცემების კლასიფიკაციას, მოთხოვნის პარამეტრებსა და პასუხებში PII, PCI და PHI-ის მონიშვნით და ამ მონაცემებს საბოლოო წერტილის ავტორიზაციის მდგომარეობასთან აკავშირებს.
ის ასევე აკავშირებს ერთსა და იმავე საბოლოო წერტილზე მიღებულ დასკვნებს და ზრდის სიმძიმეს, როდესაც ისინი გროვდება. პასუხში პირადი ინფორმაციის გაჟონვა თავისთავად სერიოზული დასკვნაა. იგივე გაჟონვა საბოლოო წერტილზე, რომელიც არ საჭიროებს ავთენტიფიკაციას, კრიტიკულია და პლატფორმა მას ამ გზით აფასებს, კავშირის ხელით შემჩნევის ნაცვლად.
Zombie and Orphan Endpoints: კოდსა და სპეციფიკაციას შორის რყევა
რადგან Xygeni თქვენს კოდსა და თქვენი API სპეციფიკაციას გვერდიგვერდ კითხულობს, ის ხედავს, სად შეუსაბამობენ ისინი. ეს გადახრა სამი ამოსაცნობი ნიმუშის სახით ვლინდება:
- დაუსაბუთებელი საბოლოო წერტილები. ისინი კოდში ცხოვრობენ და სპეციფიკაციაში არასდროს დამატებულან.
- ზომბების საბოლოო წერტილები. ისინი მონიშნულია, როგორც მოძველებული ან გაუქმებული და ისინი კვლავ ხელმისაწვდომია.
- ობოლი საბოლოო წერტილები. ამჟამინდელ გუნდში ისინი არავის ეკუთვნის.
არცერთი მათგანი არ ჩანს მხოლოდ სპეციფიკაციების ინვენტარში, რადგან ზუსტად სპეციფიკაციაა ის, რაც მათ აკლია.
მტკიცებულება, რომელზეც შეგიძლიათ იმოქმედოთ და არა გამოძიების ბილეთი
თითოეული აღმოჩენა მიუთითებს ზუსტ დამმუშავებელზე, რომელიც პასუხისმგებელია ხარვეზზე: ფაილზე, კლასზე, მეთოდსა და კონკრეტულ სტრიქონზე, რომელმაც შეცდომა შეიტანა, მასთან ერთად დატანილი კოდით. თითოეულ მათგანს ასევე აქვს თავისი სიმძიმე, OWASP API Security Top 10 კატეგორია, CWE, საბოლოო წერტილის ავთენტიფიკაციის მდგომარეობა და ჩართული მონაცემების მგრძნობელობის კლასიფიკაცია.
აღმოჩენა, რომელიც მხოლოდ საბოლოო წერტილს ასახელებს, დეველოპერს კოდის ბაზაში ძებნაში აიძულებს, სანამ რაიმეს გამოსწორებას დაიწყებს. აღმოჩენა, რომელიც ხაზს ასახელებს, მას დაუყოვნებლივ აიძულებს გამოსწორებას.
დასკვნები ექსპორტირდება JSON, CSV, Markdown და SARIF 2.1.0 ფორმატებში, ამიტომ ისინი t-ში ხვდებიან.ools, რომლებზეც თქვენი გუნდები უკვე მუშაობენ.
დამმუშავებელი, ხაზი და კოდი, რომელმაც გამოავლინა ექსპოზიცია. ეს არ არის გამოძიების ბილეთი.
რატომ არის ეს ერთ პლატფორმაზე და არა სხვა კონსოლზე
Xygeni API Security-თან ერთად იყენებს SAST, SCA, საიდუმლოებები უსაფრთხოება, IaC მდე Dast ერთ პლატფორმაში, კორელირებული გზით ASPM, იმის ნაცვლად, რომ ის ცალკე ხელსაწყოდ გაეგზავნათ საკუთარი login და საკუთარი ჩამორჩენილობა.
ეს მნიშვნელოვანია, რადგან სტატიკური და გაშვების დროის მონაცემები პასუხობენ სხვადასხვა კითხვებს ერთი და იგივე საბოლოო წერტილის შესახებ და ისინი უფრო სასარგებლოა ერთად, ვიდრე ცალ-ცალკე. სტატიკური მონაცემები გაშვებამდე გეუბნებათ, რომ საბოლოო წერტილი სარისკოა. DAST ადასტურებს, თუ რა არის რეალურად ხელმისაწვდომი და გამოსაყენებელი მისი გაშვების შემდეგ.
თუ ამას ორ კონსოლზე გადაყოფთ, კორელირებული რისკი ორ ერთმანეთთან დაუკავშირებელ დაგროვილ საკითხად იქცევა. ვერავინ ახერხებს მათ შერიგებას და დაუდოკუმენტებელი და დაუდასტურებელი საბოლოო წერტილი არცერთ რიგში არ ჯდება.
ნახეთ თქვენი რეალური API შეტევის ზედაპირი. API უსაფრთხოება ხელმისაწვდომია როგორც Enterprise Xygeni პლატფორმის დამატება და სკანირება ჩატარდება თქვენს საკუთარ საცავებზე თქვენს ინფრასტრუქტურაში.
კითხვა-პასუხი
შეუძლია თუ არა მას იმის თქმა, თუ რომელი საბოლოო წერტილები ამუშავებენ მგრძნობიარე მონაცემებს?
დიახ. Xygeni აფიქსირებს PII-ს, PCI-ს და PHI-ს საბოლოო წერტილის პარამეტრებსა და პასუხებში და იყენებს ამ კლასიფიკაციას რეალური ზემოქმედების მიხედვით დასკვნების რანჟირებისთვის.
შეუძლია თუ არა ყველაზე გაშვება? pull request?
დიახ. ინკრემენტული სკანირება აანალიზებს მხოლოდ იმ საბოლოო წერტილებს, რომლებიც შეიცვალა და მის მიერ წარმოქმნილ მანიფესტს შეუძლია შემდგომი DAST სკანირება იმავე საბოლოო წერტილებზე გაამახვილოს, ამიტომ სტატიკური და გაშვების დროს ტესტირება შეესაბამება რეალურად გადაადგილებულ წერტილებს.
ჩემი კოდი ტოვებს ჩემს გარემოს?
არა. სკანირება თქვენს ინფრასტრუქტურაში ხორციელდება. მხოლოდ შედეგები იტვირთება, რომლებიც დაცულია ტრანზიტისა და შეჩერების დროს.
როგორ მივიღო API უსაფრთხოება?
API უსაფრთხოება ხელმისაწვდომია როგორც Enterprise დამატება. მოითხოვეთ PoC და ის თქვენთან ერთად განიხილება.
