262-000177-001 OWASP-ის ტოპ 10 API უსაფრთხოებისთვის

„

პროდუქტის ინფორმაცია

სპეციფიკაციები

• პროდუქტის დასახელება: დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის ტოპ 10-ისთვის API-სთვის
  უსაფრთხოება
• შინაარსი: API უსაფრთხოების ინსტრუქციები, განმარტებები და დეტალური ინფორმაცია
  API უსაფრთხოების 2023 წლის OWASP-ის ტოპ 10 სახელმძღვანელო

პროდუქტის გამოყენების ინსტრუქცია

API უსაფრთხოების შესავალი

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

API უსაფრთხოების ინსტრუქცია

შპარგალკაში ჩამოთვლილია API უსაფრთხოების შემდეგი კატეგორიები
რისკები:

1. ობიექტის დონის ავტორიზაციის დარღვევა
2. გაუმართავი ავთენტიფიკაცია
3. გატეხილი ობიექტის თვისების დონის ავტორიზაცია
4. შეუზღუდავი რესურსების მოხმარება
5. ფუნქციის დონის ავტორიზაცია გატეხილია
6. შეუზღუდავი წვდომა მგრძნობიარე ბიზნეს ნაკადებზე
7. სერვერის მხარის მოთხოვნის გაყალბება
8. უსაფრთხოების არასწორი კონფიგურაცია
9. ინვენტარის არასწორი მართვა
10. API-ების არაუსაფრთხო მოხმარება

დეველოპერის სახელმძღვანელოview

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

ხშირად დასმული კითხვები (FAQ)

კითხვა: რატომ არის API-ის უსაფრთხოება მნიშვნელოვანი?

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

კითხვა: როგორ შემიძლია უსაფრთხო API-ების დანერგვა?

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

„`

თეთრი ქაღალდი
დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

შინაარსი

API უსაფრთხოების მოტყუების ფურცელი

5

განმარტებები

5

API1:2023–ობიექტის დონის ავტორიზაციის დარღვევა

7

API2:2023–ავტორიზაციის დარღვევა

8

API3:2023–გატეხილი ობიექტის თვისების დონის ავტორიზაცია

9

API4:2023–შეუზღუდავი რესურსების მოხმარება

11

API5:2023–გატეხილი ფუნქციის დონის ავტორიზაცია

13

API6:2023 – მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა

14

API7:2023–სერვერის მხარის მოთხოვნის გაყალბება

16

API8:2023–უსაფრთხოების არასწორი კონფიგურაცია

18

API9:2023 – ინვენტარიზაციის არასწორი მართვა

19

API10:2023 – API-ების არაუსაფრთხო მოხმარება

21

API უსაფრთხოების ტოპ-10 საკმარისი არ არის!

23

დასკვნა

23

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

2/23

რადგან კომპანიებმა დანერგეს ღრუბლოვანი ინფრასტრუქტურა და DevOp სტილის მეთოდოლოგიები, web აპლიკაციების პროგრამირების ინტერფეისები, ანუ API-ები, გამრავლდა. ყველაზე პოპულარულ საჯარო API-ებს შორისაა ის, რომლებიც დეველოპერებს საშუალებას აძლევს, წვდომა ჰქონდეთ Google Search-ზე, მოიპოვონ მონაცემები TikTok-დან, თვალყური ადევნონ მანქანებს, შეაგროვონ სპორტული ქულები და შეაგროვონ მონაცემები პოპულარული საიტებიდან სურათების ჩამოტვირთვის შესახებ.1 2023 წელს API-სთან დაკავშირებული ტრაფიკი დინამიური, არაქეშირებადი ტრაფიკის 58 პროცენტს შეადგენს, რაც 54 წლის ბოლოს არსებულ 2021.2 პროცენტთან შედარებით მეტია.XNUMX
API-ები ასევე გახდა საწარმო აპლიკაციების ერთმანეთთან კომუნიკაციისა და ინტეგრაციის საშუალება. კომპანიები თავიანთი API-ების დაახლოებით ორ მესამედს (64%) იყენებენ აპლიკაციების პარტნიორებთან დასაკავშირებლად, ხოლო დაახლოებით ნახევარი (51%) მიკროსერვისებზე წვდომის წერტილებს წარმოადგენს. საერთო ჯამში, ფირმების სამ მეოთხედზე მეტი საშუალოდ იყენებს მინიმუმ 25 API-ს თითო აპლიკაციაში.3
API-ზე დაფუძნებული აპლიკაციების ინფრასტრუქტურის დანერგვა გასაკვირი არ უნდა იყოს: კომპანიები, რომლებიც API-ებს იყენებენ მესამე მხარის დეველოპერების მოსაზიდად და ეკოსისტემების შესაქმნელად, ზრდას ზრდიან. ჩეპმენის უნივერსიტეტისა და ბოსტონის უნივერსიტეტის მკვლევარების მიერ 13 წელს გამოქვეყნებული ნაშრომის თანახმად, ეს „ინვერსიული ფირმები“ - ასე უწოდებენ იმიტომ, რომ ისინი ტექნოლოგიების გარშემო ბარიერების შექმნის ტრადიციულ კონცეფციებს ცვლიან და ზოგიერთ შესაძლებლობებსა და მონაცემებზე ღია წვდომას იძლევიან - ორი წლის განმავლობაში თითქმის 39 პროცენტით და 16 წლის განმავლობაში 2022 პროცენტით გაიზარდა იმ ფირმებთან შედარებით, რომლებმაც API-ები არ დანერგეს.4
მიკროსერვისების, კონტეინერიზაციისა და API-ების დანერგვას თან ახლავს სხვადასხვა რისკები, როგორიცაა დაუცველი პროგრამული კომპონენტები, ცუდი ბიზნეს ლოგიკა და მონაცემთა უსაფრთხოების ნაკლოვანებები. ათიდან ცხრა ორგანიზაციას (92%) განუცდია დაუცველ API-ებთან დაკავშირებული მინიმუმ ერთი უსაფრთხოების ინციდენტი.5 დიდ კომპანიებს, როგორც წესი, ათასობით API აქვთ და ამ სისტემებზე თავდასხმები უსაფრთხოების ინციდენტების დაახლოებით 20 პროცენტს შეადგენს, ხოლო პატარა კომპანიებს ასობით API აქვთ, რომელთა მცირე შეტევის ზედაპირი უსაფრთხოების ინციდენტების ხუთ პროცენტს შეადგენს.6 მარშ მაკლენანის შეფასებით, API-ების დაუცველობით გამოწვეული დარღვევების გამო წლიური ზარალი გლობალურად 40 მილიარდ დოლარს აჭარბებს.7
1 არელანო, კელი. ტოპ 50 ყველაზე პოპულარული API. RapidAPI ბლოგი. RapidAPI. Web გვერდი. 16 წლის 2023 მარტი.
2 ტრემანტე, მაიკლი და სხვ. აპლიკაციის უსაფრთხოების ანგარიში: 2 წლის მეორე კვარტალი. Cloudflare-ის ბლოგი. Cloudflare. ბლოგის პოსტი. 2023 წლის 21 აგვისტო.
3 მარკსი, მელინდა. API შეტევის ზედაპირის უსაფრთხოება. საწარმოს სტრატეგიის ჯგუფი. სპონსორი: Palo Alto Networks. PDF ანგარიში, გვ. 10. 23 წლის 2023 მაისი.
4 ბენზელი, სეთ გ. და სხვ. როგორ ქმნიან API-ები ზრდას ფირმის ინვერსიით. სოციალურ მეცნიერებათა კვლევის ქსელი. კვლევითი ნაშრომი. გადახედვის თარიღი: 30 წლის 2022 დეკემბერი.
5 API შეტევის ზედაპირის უსაფრთხოება. Enterprise Strategy Group, გვ. 14. 6 ლემოსი, რობერტი. API უსაფრთხოების დანაკარგები მილიარდებს შეადგენს, მაგრამ ეს რთულია. ბნელი საკითხავია.
სიახლეების სტატია. 30 წლის 2022 ივნისი. 7 მარშ მაკლენანი. API-ის დაუცველობის ღირებულების რაოდენობრივი განსაზღვრა. სპონსორი Imperva.
PDF ანგარიში. 22 წლის 2022 ივნისი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

3/23

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

პრობლემა იმდენად სერიოზულია, რომ აშშ-ის ეროვნული უსაფრთხოების სააგენტომ ავსტრალიის კიბერუსაფრთხოების ცენტრთან (ACSC) და აშშ-ის კიბერუსაფრთხოებისა და ინფრასტრუქტურის უსაფრთხოების სააგენტოსთან (CISA) ერთად შემოგვთავაზა რჩევები API უსაფრთხოების საკითხებთან დაკავშირებით, განსაკუთრებით ყველაზე გავრცელებულ, დაუცველი პირდაპირი ობიექტის მითითების (IDOR) დაუცველობასთან დაკავშირებით.8
გასაკვირი არ არის, რომ უსაფრთხოების მზარდი შეშფოთების ფონზე, Open Worldwide Application Security Project-მა (OWASP) გამოაქვეყნა API Security Top-10 სიის განახლება. 2019 წლის პირველი სიის განახლებით, 2023 წლის API Security Top-10 სია ხაზს უსვამს ათ ყველაზე გავრცელებულ და სერიოზულ უსაფრთხოების რისკს, რომლებიც წარმოიქმნება API-ების გამომჟღავნებელი ან გამოყენებით აპლიკაციების შემუშავებისას. ისეთი საკითხები, როგორიცაა ობიექტის დონის ავტორიზაციის დარღვევა, რომელიც მოიცავს IDOR დაუცველობებს, წინა სიისგან განსხვავებით იგივე რჩება. თუმცა, ახალი კატეგორიები - ან რეორგანიზებული კატეგორიები - ახლა ხაზს უსვამს წარსულში უგულებელყოფილ პრობლემებს, როგორიცაა სერვერის მხრიდან მოთხოვნის გაყალბება (API7:2023) და მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა (API6:2023).
„ბუნებით, API-ები ავლენენ აპლიკაციის ლოგიკას და მგრძნობიარე მონაცემებს, როგორიცაა პერსონალურად იდენტიფიცირებადი ინფორმაცია (PII) და ამის გამო, API-ები სულ უფრო ხშირად ხდებიან თავდამსხმელების სამიზნე“, - განაცხადა OWASP ჯგუფმა თავის განცხადებაში.9 „უსაფრთხო API-ების გარეშე სწრაფი ინოვაცია შეუძლებელი იქნებოდა“.

კიბერუსაფრთხოების შესახებ 8 ახალი გაფრთხილება Web აპლიკაციის დაუცველობა. ეროვნული უსაფრთხოების სააგენტო. პრესრელიზი. 27 წლის 2023 ივლისი.
9. ღია მსოფლიო აპლიკაციების უსაფრთხოების პროექტი. OWASP API უსაფრთხოების ტოპ 10: წინსვლა. OWASP.org. Web გვერდი. 3 წლის 2023 ივლისი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

4/23

API უსაფრთხოების მოტყუების ფურცელი

OWASP-ის ტოპ 10 კატეგორია 1. ობიექტის დონის ავტორიზაციის დარღვევა 2. ავტორიზაციის დარღვევა 3. ობიექტის თვისების დონის ავტორიზაციის დარღვევა 4. რესურსების შეუზღუდავი მოხმარება 5. ფუნქციის დონის ავტორიზაციის დარღვევა 6. მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა 7. სერვერის მხრიდან მოთხოვნის გაყალბება 8. უსაფრთხოების არასწორი კონფიგურაცია 9. ინვენტარის არასწორი მართვა 10. API-ების არასაიმედო მოხმარება

კიბერუსაფრთხოების გადაწყვეტა SAST SAST, DAST SAST, DAST SAST, DAST, უსაფრთხო API მენეჯერი SAST DAST DAST SAST, DAST უსაფრთხო API მენეჯერი SCA, SAST

განმარტებები
API Endpoint – ორ სისტემას შორის კომუნიკაციის წერტილი, როგორც წესი, URL მიკროსერვისის გაშვებული კონტეინერის ან სერვერის. გამოყენება URL, აპლიკაციას ან დეველოპერს შეუძლია მოითხოვოს ინფორმაცია სერვერიდან ან შეასრულოს მოქმედება API სერვერზე ან მიკროსერვისზე.
API-სთან დაკავშირებული ტრაფიკი – ინტერნეტ ტრაფიკი, რომელიც შედგება HTTP ან HTTPS მოთხოვნისგან და აქვს XML ან JSON პასუხის შინაარსი, რაც მიუთითებს, რომ მონაცემები გადაეცემა აპლიკაციას, როგორც წესი, SOAP, WSDL, REST API ან gRPC-ის მეშვეობით (იხილეთ ქვემოთ).
დინამიური აპლიკაციის უსაფრთხოების ტესტირება (DAST) - აპლიკაციის ან API სერვერის ანალიზის პროცესი ინტერფეისის გამოყენებით, იქნება ეს აპლიკაციის მომხმარებლის ინტერფეისი თუ სხვა. web წინა მხარე web განაცხადი, ან URLAPI-ის საბოლოო წერტილებისთვის. შავი ყუთის ტიპის ტესტირებისას, ეს მიდგომა აფასებს აპლიკაციას „გარედან შიგნით“ შეტევით, ისევე როგორც თავდამსხმელი, ჩვეულებრივ, შიდა პროცესების ცოდნის გარეშე.
სტატიკური აპლიკაციის უსაფრთხოების ტესტირება (SAST) – აპლიკაციის უსაფრთხოების მიდგომა, რომელიც სკანირებს წყაროს, ბინარულ ან ბაიტ კოდს შეცდომების ან დაუცველობის ამოცნობილი ნიმუშების აღმოსაჩენად. ზოგჯერ მოიხსენიება, როგორც თეთრი ყუთის ტესტირება, SAST იყენებს „შიგნიდან გარეთ“ მიდგომას, რომელიც ადგენს პოტენციურ დაუცველობას და შეცდომებს, რომლებიც შეიძლება იყოს ან არ იყოს გამოყენებული გარე თავდამსხმელის მიერ. მსუბუქი სტატიკური ხელსაწყოები შეიძლება რეალურ დროში უზრუნველყოფენ უკუკავშირს დეველოპერებისთვის მათ IDE-ში.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

5/23

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

SOAP/WSDL – XML-ზე დაფუძნებული პროტოკოლი შექმნისთვის Web API-ები. SOAP თავად პროტოკოლია და WSDL (Web სერვისის განმარტების ენა) არის ფორმატი, რომელიც გამოიყენება სერვისების ოფიციალურად აღსაწერად. დიდი ხარჯების გამო, ეს API სტილი არაპოპულარული გახდა ახალი განვითარებისთვის.
REST–A Web API სტილი, რომელიც გულისხმობს შეტყობინებების პირდაპირ HTTP-ის საშუალებით გაცვლას, HTTP-ის სემანტიკის გამოყენებით. URLs და ზმნები, დამატებითი „კონვერტის“ გამოყენების გარეშე. შინაარსი, როგორც წესი, კოდირებულია JSON ფორმატში, თუმცა ზოგიერთ შემთხვევაში ეს XML ფორმატშია.
GraphQL – შეკითხვის ენა, რომელიც შექმნილია API-ებში გამოსაყენებლად (JSON ფორმატში მოთხოვნებითა და პასუხებით), სერვერის მხარეს გაშვების დროსთან ერთად, ამ შეკითხვების შესასრულებლად. ის საშუალებას აძლევს კლიენტებს განსაზღვრონ საჭირო მონაცემების სტრუქტურა და შემდეგ მიიღონ ის სერვერიდან ამ ფორმატში.
gRPC – API პროტოკოლი, რომელიც უფრო მაღალი ხარისხისაა, ვიდრე REST. ის იყენებს HTTP/2-ს და შესრულების ავანგარდს.tages, რომელიც HTTP/1.1-ის საშუალებით გვთავაზობს. ინდივიდუალური შეტყობინებების ფორმატი, როგორც წესი, ორობითია და დაფუძნებულია ProtoBuf-ზე, რაც კვლავ ქმნის შესრულების უპირატესობას.tagREST-სა და SOAP-ზე მეტი.

2023 წლის API უსაფრთხოების ტოპ 10

ანალოგიური 2019 API უსაფრთხოების ჩანაწერი

API1:2023–ობიექტის დონის ავტორიზაციის დარღვევა

API1:2019–ობიექტის დონის ავტორიზაციის დარღვევა

API2:2023–ავტორიზაციის დარღვევა

API2:2019–მომხმარებლის ავტორიზაციის დარღვევა

API3:2023–გატეხილი ობიექტის თვისების დონის ავტორიზაცია

API3:2019–მონაცემთა გადაჭარბებული ექსპოზიცია, API6:2019–მასობრივი მინიჭება

API4:2023–შეუზღუდავი რესურსების მოხმარება

API4:2019–რესურსების ნაკლებობა და სიჩქარის შეზღუდვა

API5:2023–გატეხილი ფუნქციის დონის ავტორიზაცია

API5:2019–გატეხილი ფუნქციის დონის ავტორიზაცია

API6:2023 – მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა

API7:2023–სერვერის მხარის მოთხოვნის გაყალბება

API8:2023–უსაფრთხოების არასწორი კონფიგურაცია API7:2019–უსაფრთხოების არასწორი კონფიგურაცია

API9:2023 – ინვენტარიზაციის არასწორი მართვა

API9:2019–აქტივების არასათანადო მართვა

API10:2023 – API-ების არაუსაფრთხო მოხმარება

API8:2019–ინექცია, API10:2019–არასაკმარისი ჟურნალირება და მონიტორინგი

Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

6/23

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

API1:2023–ობიექტის დონის ავტორიზაციის დარღვევა
რა არის ეს?
API-ები სერვისებსა და მონაცემებზე წვდომას სტანდარტიზებული გამოყენებით იძლევა. web მოთხოვნები. კომპანიები თავიანთ ინფრასტრუქტურასა და მონაცემებს დაუცველი პირდაპირი წვდომის საფრთხის წინაშე აყენებენ, როდესაც ეს აქტივები კარგად არ არის დაცული ან როდესაც ავტორიზაციის კონტროლი ცუდად არის დანერგილი ან საერთოდ არ არსებობს. ობიექტის დონის ავტორიზაციის დარღვევამ, რომელსაც ასევე უწოდებენ ობიექტის არასაიმედო პირდაპირ მითითებას (IDOR), შეიძლება გამოიწვიოს სხვადასხვა რისკი, მონაცემთა გამჟღავნებიდან ანგარიშის სრულ ხელში ჩაგდებამდე.
რა ხდის აპლიკაციას დაუცველს?
ეს ფართოდ გავრცელებული და ადვილად გამოსაყენებელი პრობლემაა web აპლიკაციები. აპლიკაციები დაუცველია, თუ ისინი მომხმარებელს საშუალებას აძლევს, განახორციელოს ქმედებები API-ში იდენტიფიკატორის მითითებით, იმის შემოწმების გარეშე, აქვთ თუ არა მათ ამ ქმედებების განხორციელების ავტორიზაცია.
ყოფილშიampOWASP-ის მიერ დეტალურად აღწერილი, ონლაინ მაღაზიების პლატფორმას შეუძლია მაღაზიის მონაცემებზე წვდომის საშუალება მარტივი ზარის გამოყენებით მოგცეთ:
/მაღაზიები/{მაღაზიისსახელი}/შემოსავლები _ მონაცემები.json
ეს არასაიმედოა, რადგან ნებისმიერ მომხმარებელს შეუძლია shopName-ის სხვა მომხმარებლის მაღაზიის სახელით ჩანაცვლება, რითაც წვდომა ექნება მონაცემებზე, რომლებიც მას არ უნდა ჰქონდეს.
თავდასხმა ყოფილიamples
2021 წელს, უსაფრთხოების მკვლევარმა აღმოაჩინა, რომ web-აპლიკაციურ და ბექენდ სერვერებს, რომლებიც მონაცემებს აწვდიდნენ Peloton-ის სავარჯიშო ველოსიპედებს, ჰქონდათ რამდენიმე API საბოლოო წერტილი, რომელიც არაავტორიზებულ მომხმარებლებს საშუალებას აძლევდა, წვდომა ჰქონოდათ პირად მონაცემებზე. 2021 წლის თებერვალში Peloton-მა დანერგა პრობლემის ნაწილობრივი გამოსწორება, რითაც API-ზე წვდომა მხოლოდ ავტორიზებული მომხმარებლებისთვის შეიზღუდა, მაგრამ მაინც მისცა ამ მომხმარებლებს სხვა წევრების ნებისმიერ პირად მონაცემებზე წვდომის საშუალება. სრული გამოსწორება 2021.10 წლის მაისში მოხდა.XNUMX
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
დეველოპერები ობიექტებზე დაუცველ წვდომას თავიდან აცილებენ მკაცრი კონტროლის დაწესებით, ანგარიშების ჩამოთვლის თავიდან ასაცილებლად არაპროგნოზირებადი მომხმარებლის იდენტიფიკატორების მინიჭებით და მონაცემთა წყაროზე წვდომის მქონე ყველა ფუნქციის ობიექტის დონის ავტორიზაციის შემოწმებით. დეველოპერებმა უნდა მოიცვან ასეთი შემოწმებები, განსაკუთრებით თუ ისინი მომხმარებლის შეყვანაზეა დაფუძნებული, რათა გამოირიცხოს იმის შესაძლებლობა, რომ შემთხვევითი შეცდომები უსაფრთხოებას შეაფერხებს. აპლიკაციების უსაფრთხოებისა და ოპერაციების სპეციალისტებმა უნდა მოითხოვონ ავტორიზაციის შემოწმება მონაცემთა ბაზაზე თითოეული მოთხოვნისთვის.
რით შეუძლია OpenText-ს დახმარება?
OpenText™ სტატიკური აპლიკაციის უსაფრთხოების ტესტირებას (SAST) და OpenText™ დინამიური აპლიკაციის უსაფრთხოების ტესტირებას (DAST) შეუძლია დაუცველი პირდაპირი ობიექტის მითითების (IDOR) კატეგორიაში არსებული დაუცველობების ფართო სპექტრის აღმოჩენა. IDOR-ს შეუძლია მოიცვას ისეთი დაუცველობები, როგორიცაა დირექტორიის გავლა, File ატვირთვა და File ჩართვა. უფრო ზოგადად, IDOR ასევე მოიცავს დაუცველობის კლასებს, სადაც იდენტიფიკატორები
10 მასტერსი, იანვარი. პელოტონის ტური: გამოვლენილი მომხმარებლის მონაცემები. Pen Test Partners-ის ბლოგი. Pen Test Partners. Web გვერდი. 5 წლის 2021 მაისი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

7/23

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

შეიძლება შეიცვალოს მეშვეობით URL, სხეულის ან სათაურის მანიპულირება. სისტემა გააფრთხილებს დეველოპერებს იმ შემთხვევების შესახებ, როდესაც მომხმარებელს შეუძლია პირდაპირ აირჩიოს პირველადი გასაღები API მოთხოვნაში მონაცემთა ბაზის ან შენახვის კონტეინერისთვის, პრობლემა, რომელიც ხშირად იწვევს ამ კლასის დაუცველობას. სისტემა ასევე გააფრთხილებს, როდესაც მოსალოდნელი ავტორიზაციის შემოწმება არ არის.
API2:2023–ავტორიზაციის დარღვევა
რა არის ეს?
ავტორიზაციის შემოწმებები ზღუდავს მონაცემებზე წვდომას კონკრეტული როლების ან მომხმარებლების მიხედვით, მაგრამ ეს შეზღუდვები საკმარისი არ არის სისტემების, მონაცემებისა და სერვისების დასაცავად. დეველოპერებმა და აპლიკაციების უსაფრთხოების გუნდებმა ასევე სათანადოდ უნდა დანერგონ შესაძლებლობები, რათა შეამოწმონ მომხმარებლის ვინაობა ავტორიზაციის გზით. ავტორიზაციის კრიტიკული ხასიათის მიუხედავად, კომპონენტები ხშირად ცუდად არის დანერგილი ან არასწორად გამოიყენება - რაც მომხმარებლის ავტორიზაციის გაუმართაობის ძირითადი მიზეზებია. მომხმარებლის ავტორიზაციის გაუმართაობა თავდამსხმელებს საშუალებას აძლევს, დროებით ან სამუდამოდ მიითვისონ სხვა მომხმარებლების ვინაობა დაუცველი ავტორიზაციის ტოკენების გამოყენებით ან განხორციელების ხარვეზების კომპრომეტირებით.
რა ხდის აპლიკაციას დაუცველს?
ეს გავრცელებული და ადვილად გამოსაყენებელი პრობლემა იმიტომ ჩნდება, რომ ავტორიზაცია რთული პროცესია, რომელიც შეიძლება დამაბნეველი იყოს და, განმარტების თანახმად, საზოგადოებისთვის ხელმისაწვდომია. დეველოპერის შეცდომებმა და აპლიკაციის არასწორმა კონფიგურაციამ შეიძლება გამოიწვიოს საჭირო შემოწმებების ნაკლებობა, რაც თავდამსხმელებს საშუალებას აძლევს თავიდან აიცილონ ავტორიზაცია. დეველოპერები, რომლებიც ვერ ახორციელებენ ავტორიზაციას კონკრეტული საბოლოო წერტილისთვის ან უშვებენ სუსტ ავტორიზაციის მექანიზმს, აპლიკაციებს აყენებენ სხვადასხვა შეტევების წინაშე, როგორიცაა ავტორიზაციის ჩაყრა, ტოკენების ხელახლა თამაში ან პაროლის მოპარვა.
თავდასხმა ყოფილიamples
2023 წლის თებერვლიდან ივნისამდე პერიოდში, ტანსაცმლის საცალო ვაჭრობის კომპანია Hot Topic-ის სამიზნე აუდიტორიას წარმოადგენდა ავტორიზაციის მონაცემების შეგროვების მიზნით თავდასხმები, რომლებმაც თავის მომხმარებლებს აცნობეს, რომ უცნობი რაოდენობის ანგარიშები გატეხეს. თავდამსხმელებმა, უცნობი წყაროებიდან მოპოვებული ავტორიზაციის მონაცემების გამოყენებით, შეძლეს წვდომა ისეთ მგრძნობიარე პერსონალურ მონაცემებზე, როგორიცაა მომხმარებლების სახელები, ელექტრონული ფოსტის მისამართები, შეკვეთების ისტორია, ტელეფონის ნომრები, დაბადების თვეები და დღეები.11
2022 წლის თებერვალში, არასწორად კონფიგურირებული ღრუბლოვანი საცავის ბაკეტის გამო, ელფოსტის მარკეტინგის სერვის Beetle Eye-დან 1 GB მგრძნობიარე მონაცემები პაროლით დაცული ან დაშიფრული არ იყო. მონაცემები მოიცავდა საკონტაქტო ინფორმაციას და ტურიზმთან დაკავშირებულ ინფორმაციას, რომელიც შეგროვებული იყო სხვადასხვა ტურისტული სააგენტოებისა და აშშ-ის შტატების მიერ.12 არასწორად კონფიგურირებული ავტორიზაციის მექანიზმები ითვლება „გაუმართავი მომხმარებლის ავტორიზაციის“ კატეგორიის ვარიანტად.
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
11 ტულასი, ბილ. საცალო ქსელი Hot Topic ავლენს ავტორიზაციის მონაცემების შევსების თავდასხმების ტალღას. BleepingComputer. სიახლეების სტატია. 1 წლის 2023 აგვისტო.
12 ნაირი, პრაჯიტი. 7 მილიონი ადამიანის მონაცემები გამჟღავნდა აშშ-ის მარკეტინგული პლატფორმის მეშვეობით. მონაცემთა დარღვევა დღეს. ISMG ქსელი. 11 წლის 2022 თებერვალი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

8/23

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

სტანდარტიზაცია თქვენი მეგობარია ავთენტიფიკაციისთვის. DevSecOps გუნდებმა უნდა შექმნან ერთი ან შეზღუდული რაოდენობის ავთენტიფიკაციის მეთოდები აპლიკაციებისთვის და უზრუნველყონ, რომ დეველოპერებმა ერთგვაროვნად დანერგონ მექანიზმები ყველა მიკროსერვისსა და API-ში. ნებისმიერი ავთენტიფიკაციის იმპლემენტაცია უნდა გადაიხედოს.viewშექმნილია OWASP აპლიკაციის უსაფრთხოების შემოწმების სტანდარტის (ASVS) კონტექსტში, რომელიც ამჟამად 4,13 ვერსიაშია, იმპლემენტაციისა და მასთან დაკავშირებული უსაფრთხოების კონტროლის სისწორის უზრუნველსაყოფად. სტანდარტიდან ნებისმიერი გადახრა, განსაკუთრებით არაავტორიზებული საბოლოო წერტილების განზრახ გამოვლენა, უნდა შეფასდეს უსაფრთხოების გუნდის მიერ და დაშვებული იყოს მხოლოდ მკაცრი ბიზნეს მოთხოვნის დასაკმაყოფილებლად.
რით შეუძლია OpenText-ს დახმარება?
OAuth და JWT API-ების დანერგვისთვის გამოყენებული ავტორიზაციის ორი ყველაზე გავრცელებული ტიპია, ხოლო OpenText Dynamic Application Security Testing ამოწმებს ორივე სტანდარტის სუსტ იმპლემენტაციას აპლიკაციებში, ასევე არასწორ კონფიგურაციებსა და დაუცველ ნიმუშებს, როგორიცაა CSRF და Session Fixation, რომლებიც გვხვდება მორგებული ავტორიზაციის იმპლემენტაციებში. OpenText-ის მიერ Dynamic Application Security Tool (DAST) სკანირება ავტორიზაციის დაუცველობების აღმოსაჩენად შესანიშნავი საშუალებაა, განსაკუთრებით API-ში.
OpenText სტატიკური აპლიკაციის უსაფრთხოების ტესტირება ასევე საშუალებას იძლევა ჩაატაროს ფართო სპექტრის შემოწმებები, რომლებიც დაკავშირებულია არასწორ ავთენტიფიკაციასთან. სტატიკური ანალიზის ინსტრუმენტი მოიცავს როგორც ზოგადი პრობლემების, როგორიცაა ავტორიზაციის მონაცემების გაჟონვა, ასევე API-სპეციფიკური პრობლემების, როგორიცაა JWT ტოკენებში დაცვის დაკარგული პრეტენზიები ან JWT სათაურებში წარმოშობილი პრეტენზიები, აღმოჩენას.
API3:2023–გატეხილი ობიექტის თვისების დონის ავტორიზაცია
რა არის ეს?
გატეხილი ობიექტის თვისების დონის ავტორიზაცია 2023 წლის OWASP სიის ახალი კატეგორიაა, რომელიც აერთიანებს წინა სიიდან ორ კატეგორიას: მონაცემთა გადაჭარბებული ექსპოზიცია (API3:2019) და მასობრივი მინიჭება (API6:2019). პრობლემა გამოწვეულია მომხმარებლის ავტორიზაციის არარსებობით - ან მომხმარებლის არასათანადო ავტორიზაციით - ობიექტ-თვისების დონეზე. API-ის საბოლოო წერტილებმა უნდა დაადასტურონ, რომ თითოეულ მომხმარებელს აქვს ავტორიზაცია ყველა თვისებისთვის, რომლის წვდომასაც ან შეცვლას ცდილობენ. პრობლემის ექსპლუატაციამ შეიძლება გამოიწვიოს ინფორმაციის ექსპოზიცია ან მონაცემების მანიპულირება არაავტორიზებული მხარეების მიერ.
რა ხდის აპლიკაციას დაუცველს?
გავრცელებული და მარტივად გამოსაყენებელი პრობლემა მაშინ ჩნდება, როდესაც მომხმარებელს შეიძლება ჰქონდეს კონკრეტული ობიექტის ზოგიერთ თვისებაზე წვდომის უფლება, მაგალითად, მოგზაურობის აპლიკაციაში ოთახის დაჯავშნის, მაგრამ არა სხვაზე, მაგალითად, ოთახის ფასზე. როდესაც მომხმარებელი ობიექტის თვისებებზე წვდება API-ს მეშვეობით, აპლიკაციამ უნდა შეამოწმოს, რომ მომხმარებელი:
· უნდა შეეძლოს ობიექტის კონკრეტულ თვისებაზე წვდომა
13 OWASP აპლიკაციის უსაფრთხოების შემოწმების სტანდარტი. OWASP. GitHub გვერდი. ბოლო წვდომა: 17 წლის 2023 ნოემბერი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

9/23

გატეხილი ობიექტის თვისების დონის ავტორიზაცია 2023 წლის OWASP სიაში ახალი კატეგორიაა, რომელიც წინა სიიდან ორ კატეგორიას აერთიანებს: მონაცემთა გადაჭარბებული ექსპოზიცია (API3:2019) და მასობრივი მინიჭება (API6:2019).
OpenText™ სტატიკური აპლიკაციის უსაფრთხოების ტესტირება მონაცემთა ნაკადის ანალიზის საშუალებით ხელს უწყობს როგორც მონაცემთა გადაჭარბებული ზემოქმედების, ასევე მასობრივი მინიჭების თავიდან აცილებას. სისტემა გამოყოფს კერძო მონაცემების მრავალ წყაროს, როგორიცაა ცვლადების სახელებზე ან კონკრეტულ API გამოძახებებზე დაფუძნებული მონაცემები და გამოავლენს ობიექტებს, რომლებიც მასობრივ მინიჭებას იძლევა.

(დარღვევები ადრე ცნობილი იყო, როგორც მონაცემთა გადაჭარბებული ექსპოზიცია) და/ან
· ობიექტის კონკრეტული თვისების შეცვლის უფლება აქვს (ზოგიერთი აპლიკაცია ამას ვერ ამოწმებს, რადგან ისინი იყენებენ ჩარჩოს ავტომატურად შესაბამისობაში მოსაყვანად) web პარამეტრების მოთხოვნა ობიექტის ველებისთვის, პრობლემა, რომელიც ცნობილია როგორც მასის მინიჭება).
OWASP-ის ყოფილ ვერსიაშიampმაგალითად, ონლაინ ვიდეო პლატფორმა მომხმარებელს საშუალებას აძლევს შეცვალოს ვიდეოს აღწერა, თუნდაც დაბლოკილი ვიდეოს, მაგრამ არ უნდა მისცეს მომხმარებელს „დაბლოკილის“ თვისების შეცვლის საშუალება.
PUT /api/video/update _ ვიდეო
{
„აღწერა“: „სასაცილო ვიდეო კატების შესახებ“,
„დაბლოკილია“: ცრუ
}
თავდასხმა ყოფილიamples
2022 წლის იანვარში, შეცდომების აღმოჩენის პროგრამამ Twitter-ში აღმოაჩინა ხარვეზი, რომელიც მომხმარებელს საშუალებას აძლევდა, Twitter-ის სისტემაში მიეწოდებინა ელექტრონული ფოსტის მისამართი ან ტელეფონის ნომერი, რომელიც შემდეგ დააბრუნებდა იმ ანგარიშის სახელს, რომელსაც ინფორმაცია ეკუთვნოდა.14 უცნობმა თავდამსხმელმა გამოიყენა ხარვეზი ტელეფონის ნომრებთან და ელექტრონული ფოსტის მისამართებთან დაკავშირებული მილიონობით მომხმარებლის ანგარიშის სიის შესადგენად. ნებისმიერი პირისთვის ორი საკუთრების დაკავშირების უფლების მიცემით, Twitter-მა უნებლიეთ დაუშვა ფსევდონიმით ცნობილი მომხმარებლების უფრო კონკრეტულად იდენტიფიცირება.
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
დეველოპერებმა ყოველთვის უნდა დანერგონ სათანადო კონტროლი კონკრეტული ობიექტის თვისებებზე წვდომის ან შეცვლის შესაძლებლობაზე. ყოველი თვისებით ზოგადი მონაცემთა სტრუქტურის დაბრუნების ნაცვლად - რაც ხშირად ხდება ზოგადი მეთოდების შემთხვევაში, როგორიცაა to_json() და to_string() - პროგრამისტებმა ძალიან კონკრეტულად უნდა განსაზღვრონ, თუ რა ინფორმაციას აბრუნებენ. უსაფრთხოების დამატებითი ზომის სახით, აპლიკაციებმა უნდა დანერგონ სქემაზე დაფუძნებული პასუხის ვალიდაცია, რომელიც აწესებს უსაფრთხოების კონტროლს API მეთოდებით დაბრუნებულ ყველა მონაცემზე. წვდომა უნდა ეფუძნებოდეს მინიმალური პრივილეგიების პრინციპებს, წვდომის დაშვებით მხოლოდ აბსოლუტურად აუცილებლობის შემთხვევაში.
რით შეუძლია OpenText-ს დახმარება?
OpenText™ სტატიკური აპლიკაციის უსაფრთხოების ტესტირება ხელს უწყობს როგორც მონაცემების გადაჭარბებული ზემოქმედების, ასევე მასობრივი მინიჭების თავიდან აცილებას მონაცემთა ნაკადის ანალიზის გზით. სისტემა გამოყოფს კერძო მონაცემების მრავალ წყაროს, როგორიცაა ცვლადების სახელებზე დაფუძნებული ან კონკრეტული API გამოძახებები და გამოავლენს ობიექტებს, რომლებიც მასობრივ მინიჭებას იძლევა. მომხმარებლებს ასევე შეუძლიათ განსაზღვრონ საკუთარი წყაროები, თვალყური ადევნონ მონაცემებს პროგრამის მეშვეობით და თუ ისინი შეუსაბამო ადგილას აღმოჩნდებიან, რისკის შესახებ აცნობონ დეველოპერს ან ოპერატორს.

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

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

10/23

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

გარდა ამისა, OpenText SAST-ს აქვს JSON და XML სერიალიზაციისა და დესერიალიზაციის ყველაზე მნიშვნელოვანი მექანიზმების ცოდნა. ამის გამოყენებით, ინსტრუმენტს შეუძლია აღმოაჩინოს კოდი, რომელიც სათანადოდ არ ახდენს დომენის გადაცემის ობიექტების (DTO) დესერიალიზაციას, რამაც შეიძლება გამოიწვიოს მისი ატრიბუტების მასობრივი მინიჭება. ინფორმაციის ზემოქმედებისა და მასობრივი მინიჭების ზოგიერთი შემთხვევის აღმოჩენა ასევე შესაძლებელია OpenText დინამიური აპლიკაციის უსაფრთხოების ტესტირების გამოყენებით. დაბოლოს, ზოგიერთი საპასუხო ზომა შეიძლება განხორციელდეს წესების დამატებით. web აპლიკაციის firewall (WAF).
API4:2023–შეუზღუდავი რესურსების მოხმარება
რა არის ეს?
API-ები ბევრ სასარგებლო ბიზნეს ფუნქციას ავლენენ. ამისათვის ისინი იყენებენ გამოთვლით რესურსებს, როგორიცაა მონაცემთა ბაზის სერვერები, ან შეიძლება ჰქონდეთ წვდომა ფიზიკურ კომპონენტზე ოპერაციული ტექნოლოგიის საშუალებით. იმის გამო, რომ სისტემებს აქვთ რესურსების შეზღუდული ნაკრები API ზარებზე რეაგირებისთვის, თავდამსხმელებს შეუძლიათ სპეციალურად შექმნან მოთხოვნები სცენარების შესაქმნელად, რომლებიც იწვევს რესურსების ამოწურვას, მომსახურების უარყოფას ან ბიზნეს ხარჯების ზრდას. ბევრ შემთხვევაში, თავდამსხმელებს შეუძლიათ გაგზავნონ API მოთხოვნები, რომლებიც მნიშვნელოვან რესურსებს ზღუდავს, გადატვირთავს მანქანას ან გამტარუნარიანობის რესურსებს და იწვევს მომსახურების უარყოფის შეტევას. სხვადასხვა IP მისამართიდან ან ღრუბლოვანი ინსტანციებიდან განმეორებითი მოთხოვნების გაგზავნით, თავდამსხმელებს შეუძლიათ გვერდი აუარონ დაცვის მექანიზმებს, რომლებიც შექმნილია გამოყენების საეჭვო მკვეთრ ზრდაზე.
რა ხდის აპლიკაციას დაუცველს?
API მოთხოვნები იწვევს პასუხებს. მიუხედავად იმისა, მოიცავს თუ არა ეს პასუხები მონაცემთა ბაზაზე წვდომას, შეყვანა/გამოყვანის შესრულებას, გამოთვლების გაშვებას თუ (სულ უფრო მეტად) მანქანური სწავლების მოდელიდან გამომავალი მონაცემების გენერირებას, API-ები იყენებენ გამოთვლით, ქსელურ და მეხსიერების რესურსებს. თავდამსხმელს შეუძლია API მოთხოვნები გაუგზავნოს საბოლოო წერტილს, როგორც მომსახურების უარყოფის (DoS) შეტევის ნაწილი, რომელიც გამტარუნარიანობის გადატვირთვის ნაცვლად - მოცულობითი DoS შეტევის მიზანი - ამოწურავს CPU-ს, მეხსიერებას და ღრუბლოვან რესურსებს. აპლიკაციები, რომლებიც არ ზღუდავენ მოთხოვნის დასაკმაყოფილებლად გამოყოფილ რესურსებს, შეიძლება დაუცველი იყოს, მათ შორის ისინი, რომლებიც ვერ ზღუდავენ გამოყოფილ მეხსიერებას, რაოდენობას. fileსხვა ატრიბუტებთან ერთად, წვდომადი პროცესები ან მოთხოვნების დაშვებული სიხშირე.
სერვერის დამუშავების API-ებს უნდა ჰქონდეთ შეზღუდვები, რათა თავიდან აიცილონ მეხსიერებისა და სამუშაო დატვირთვის გადაჭარბებული გამოყოფა, API-ით აქტივირებული ოპერაციების გადაჭარბებული მოთხოვნები ან მესამე მხარის სერვისისთვის გადაჭარბებული გადასახადები ხარჯების ლიმიტის გარეშე.
გავრცელებული შეტევაა API-ის საბოლოო წერტილში გადაცემული არგუმენტების შეცვლა, მაგალითად, პასუხის ზომის გაზრდა და მონაცემთა ბაზაში მილიონობით ჩანაწერის მოთხოვნა, ვთქვათ, პირველი ათი ჩანაწერის ნაცვლად:
/api/users?page=1&size=1000000
გარდა ამისა, თუ თავდამსხმელს შეუძლია წვდომა ჰქონდეს ბექენდ სერვისზე, რომელიც გამოყენებისთვის საფასურს ითხოვს, რესურსების მოხმარების შეტევები შეიძლება გამოყენებულ იქნას აპლიკაციის მფლობელისთვის საკომისიოს გასაზრდელად. კიდევ ერთი OWASP ყოფილიampლე მიუთითებს პაროლის გადატვირთვის ფუნქციაზე, რომელიც იყენებს SMS ტექსტურ შეტყობინებას ვინაობის დასადასტურებლად და რომლის ათასობით გამოძახებაც შესაძლებელია მსხვერპლის ხარჯების გაზრდის მიზნით.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

11/23

ქსელის კიდეზე ფილტრაცია კონტენტის მიწოდების ქსელების (CDN) გამოყენებით, რომლებიც დაწყვილებულია web აპლიკაციების firewall-ებს (WAF) შეუძლიათ შეამცირონ ტრაფიკის წყალდიდობა და ამავდროულად მინიმუმამდე დაიყვანონ ინდივიდუალური მომხმარებლებისთვის ზემოქმედება.

POST /sms/send _ reset _ pass _ code
მასპინძელი: willyo.net {
„ტელეფონის ნომერი“: „6501113434“ }
თავდასხმა ყოფილიamples
ვინაიდან რესურსების მოხმარების შეტევები ხშირად ერთად ხვდება შესრულებისა და ხელმისაწვდომობის პრობლემებთან, სამიზნე კომპანიები მათ ბიზნესის კეთების ხარჯების ნაწილად მიიჩნევენ და არა ინციდენტებად, რომლებიც უნდა შეატყობინონ, რაც ამცირებს საფრთხის ხილვადობას. 2022 წელს, აპლიკაციის დონის განაწილებული მომსახურების უარყოფის (DDoS) შეტევები, API რესურსების მოხმარების შეტევების სუპერნაკრები, შემცირდა ყველა შეტევის წილში, მაგრამ 4 წლის მეოთხე კვარტალში მაინც დაფიქსირდა 2022%-ით მეტი შეტევა, ვიდრე წინა წლის ანალოგიურ კვარტალში.79
2015 წელს აღწერილი ერთ-ერთი შეტევის დროს, დეველოპერმა აღმოაჩინა Android კლიენტი, რომელიც განმეორებით უკავშირდებოდა მათი საიტის... Web შემთხვევით გენერირებული API გასაღებებით API, რამაც გამოიწვია მომსახურების უარყოფის შეტევა. დეველოპერმა გამოთქვა ჰიპოთეზა, რომ Android მოწყობილობებზე დაინსტალირებული მავნე აპლიკაცია ცდილობდა 64-ბიტიანი API გასაღების გამოცნობას.16
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
სიჩქარის ლიმიტებისა და ზღურბლის გამოყენებით, რესურსების მოხმარების შეტევების უმეტესობა შეიძლება შემცირდეს, თუმცა ლეგიტიმურ ტრაფიკზე ასევე შეიძლება გავლენა იქონიოს ცუდად აგებულმა თავდაცვამ. კონკრეტული ლიმიტები უნდა დაწესდეს:
· მეხსიერების განაწილება
· პროცესები
· ღრუბლოვანი ეგზემპლარები
· ატვირთულია file აღმწერები და file ზომა
· დაბრუნებული ჩანაწერები
· მესამე მხარის სერვისებზე გადახდილი ტრანზაქციების რაოდენობა
· ყველა შემომავალი პარამეტრი (მაგ., სტრიქონის სიგრძე, მასივის სიგრძე და ა.შ.)
· API ურთიერთქმედებების რაოდენობა თითო კლიენტზე კონკრეტულ დროის ფანჯარაში
ქსელის კიდეზე ფილტრაცია კონტენტის მიწოდების ქსელების (CDN) გამოყენებით, რომლებიც დაწყვილებულია web აპლიკაციების firewall-ებს (WAF) შეუძლიათ შეამცირონ ტრაფიკის წყალდიდობა და ამავდროულად მინიმუმამდე დაიყვანონ ინდივიდუალური მომხმარებლებისთვის ზემოქმედება. აპლიკაციების მიწოდების პლატფორმები საშუალებას იძლევა მარტივი ფილტრაციის, მათ შორის მეხსიერების, პროცესორების და პროცესების შეზღუდვების.
15 იოახიმიკი, ომერ. Cloudflare-ის DDoS საფრთხის ანგარიში 2022 წლის მეოთხე კვარტალში. Cloudflare-ის ბლოგი. Web გვერდი. 10 წლის 2023 იანვარი.
16 როგორ შევაჩეროთ ჰაკერული/DOS შეტევა web API. StackOverflow. Web გვერდი. 15 წლის 2015 სექტემბერი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

12/23

OpenText Dynamic Application Security Testing-ს შეუძლია სერვერებისა და API ფუნქციების შემოწმება მომსახურების უარყოფის შეტევის მიმართ დაუცველობაზე, სერვისზე გავლენის მოხდენის გარეშე. გარდა ამისა, DAST სკანირების გაშვების თავად აქტმა შეიძლება გარემოს სტრეს-ტესტირება მოახდინოს, რათა რესურსების მოხმარების პოტენციური სისუსტეები აჩვენოს.

რით შეუძლია OpenText-ს დახმარება?
OpenText SAST-ისა და OpenText Dynamic Application Security Testing-ის მეშვეობით, DevSecOps გუნდებს შეუძლიათ შეამოწმონ თავიანთი კოდი და ინფრასტრუქტურა რესურსების ამოწურვის შეტევებისადმი მდგრადობაზე. OpenText SAST-ს შეუძლია აღმოაჩინოს მრავალი სფერო, სადაც თავდამსხმელს შეუძლია აპლიკაციის ლოგიკის ბოროტად გამოყენება რესურსების უკიდურესი მოხმარების შესაქმნელად.
კოდის დონის უსაფრთხოება საკმარისი არ არის აპლიკაციაში ამ პრობლემის მოსაგვარებლად. რესურსების ამოწურვა და სიჩქარის შეზღუდვა მომსახურების უარყოფის შეტევების სპეციფიკური ქვესეგმენტებია, რომლებიც უნდა შემცირდეს გაშვების დროს. OpenText დინამიური აპლიკაციის უსაფრთხოების ტესტირებას შეუძლია სერვერების და API ფუნქციების შემოწმება მომსახურების უარყოფის შეტევის მიმართ დაუცველობაზე, სერვისზე გავლენის მოხდენის გარეშე. გარდა ამისა, DAST სკანირების გაშვების თავად აქტმა შეიძლება გარემოს სტრეს-ტესტირება მოახდინოს საკმარისი იმისათვის, რომ აჩვენოს რესურსების მოხმარების პოტენციური სისუსტეები.
API5:2023–გატეხილი ფუნქციის დონის ავტორიზაცია
რა არის ეს?
თანამედროვე აპლიკაციას აქვს მრავალი განსხვავებული ფუნქცია, რომელიც ეხება მონაცემებზე წვდომას, მათ შექმნას, მანიპულირებას, წაშლას და მართვას. ყველა აპლიკაციის მომხმარებელს არ სჭირდება წვდომა ყველა ფუნქციაზე ან ყველა მონაცემზე და ეს არ უნდა იყოს დაშვებული მინიმალური პრივილეგიის პრინციპით. ყველა API საბოლოო წერტილს აქვს განკუთვნილი აუდიტორია, რომელიც შეიძლება მოიცავდეს ანონიმურ, ჩვეულებრივ არაპრივილეგირებულ და პრივილეგირებულ მომხმარებლებს. ადმინისტრაციული და მართვის ფუნქციები უნდა მოითხოვდეს პრივილეგირებულ ავტორიზაციას, მაგრამ ზოგჯერ მათზე წვდომა ხდება არაავტორიზებული მომხმარებლის ლეგიტიმური API ზარების საშუალებით - რაც ფუნქციის დონის ავტორიზაციის გაფუჭების სათავეა. იმის გამო, რომ განსხვავებული იერარქიები, ჯგუფები და როლები ქმნის სირთულეს წვდომის კონტროლში, აპლიკაციის ფუნქციებს შეიძლება არ ჰქონდეთ შესაბამისი შეზღუდვები იმის შესახებ, თუ ვის შეუძლია მათი გამოძახება.
რა ხდის აპლიკაციას დაუცველს?
აპლიკაციებმა, რომლებიც კონკრეტულ ფუნქციებს ადმინისტრაციული ამოცანების შესრულების საშუალებას აძლევს, არ შეიძლება შეზღუდონ ამ ფუნქციებზე წვდომა უსაფრთხო გზით. API-ები, რომლებიც პირდაპირ უკავშირდება ასეთ ფუნქციებს, ამ სისუსტეებს ექსპლუატაციის საფრთხის ქვეშ დააყენებს. ფუნქციები, რომლებიც არ იყენებენ აპლიკაციის ავტორიზაციისა და ავტორიზაციის მექანიზმს, უნდა ჩაითვალოს უსაფრთხოების პოტენციურ სისუსტეებად.
ყოფილშიampOWASP-ის მიერ მოყვანილი ინფორმაციით, თავდამსხმელი იღებს წვდომას API მოთხოვნებზე, რომლებიც მოწვეული მომხმარებლის ახალ მობილურ აპლიკაციაში დამატებას ეხება, თუმცა აღნიშნულია, რომ მოწვევა მოწვეულის როლის შესახებ ინფორმაციას შეიცავს. სისუსტის გამოყენებით, თავდამსხმელი ახალ მოწვევას აგზავნის:
POST /api/invites/new
{
„ელ. ფოსტა“: „attacker@somehost.com“,
„როლი“: „ადმინისტრატორი“
} ეს მათ სისტემაზე ადმინისტრატორის უფლებების მოპოვების საშუალებას აძლევს.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

13/23

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

თავდასხმა ყოფილიamples
2022 წელს ტეხასის დაზღვევის დეპარტამენტმა საზოგადოებას აცნობა, რომ თითქმის ორი მილიონი ტეხასელის ინფორმაცია გამჟღავნდა მუშათა კომპენსაციის განაცხადის იმ ნაწილის მეშვეობით, რომელმაც უნებლიეთ საზოგადოების წევრებს დაცულ მონაცემებზე წვდომის საშუალება მისცა.17 2022 წელს მომხდარი მეორე ინციდენტის დროს ავსტრალიურმა ტელეკომუნიკაციების ფირმა Optus-მა აღიარა, რომ 10 მილიონამდე ავსტრალიელის პირადი და ანგარიშის ინფორმაცია გამჟღავნდა API-ის მიერ, რომელიც არ საჭიროებდა რაიმე სახის ავთენტიფიკაციას ან ავტორიზაციას. მიუხედავად იმისა, რომ Optus-მა შეტევას „დახვეწილი“ უწოდა, უსაფრთხოების მკვლევარმა, რომელიც იცნობდა თავდასხმის დეტალებს, ის „ტრივიალური“ უწოდა.18
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
DevSecOps გუნდებმა უნდა შეიმუშაონ ავთენტიფიკაციისა და ავტორიზაციის სტანდარტული მიდგომა, რომელიც ნაგულისხმევად ხელს შეუშლის მოთხოვნებზე წვდომას და დააწესებს „ყველას უარყოფის“ ნაგულისხმევ პარამეტრს. ამ ნაგულისხმევიდან გამომდინარე, როლების/ჯგუფების/მომხმარებლების წვდომის განსაზღვრისას ყოველთვის გამოიყენეთ მინიმალური პრივილეგიის პრინციპი. დეველოპერებმა უნდა უზრუნველყონ, რომ ავთენტიფიკაცია და ავტორიზაცია დანერგილია ყველა შესაბამისი HTTP ზმნისთვის/მეთოდისთვის (მაგ., POST, GET, PUT, PATCH, DELETE), რომლებიც დაკავშირებულია თითოეულ API საბოლოო წერტილთან. არარელევანტური ზმნები უნდა აიკრძალოს. გარდა ამისა, დეველოპერებმა უნდა დანერგონ ადმინისტრაციული წვდომისა და მართვის საბაზისო კლასი, კლასის მემკვიდრეობის გამოყენებით, რათა უზრუნველყონ, რომ ავტორიზაციის კონტროლი ამოწმებს მომხმარებლის როლს წვდომის მინიჭებამდე. ყველა კრიტიკულმა ადმინისტრაციულმა ფუნქციამ უნდა გამოიყენოს ავტორიზაციის მექანიზმი პრივილეგიების ესკალაციის თავიდან ასაცილებლად.
რით შეუძლია OpenText-ს დახმარება?
OpenText™ Static Application Security Testing-ის სტატიკური კოდისა და API ანალიზის ფუნქციების OpenText Dynamic Application Security Testing (DAST) პაკეტის გაშვების შემოწმებებთან გაერთიანებით, DevSecOps გუნდებს შეუძლიათ შეაფასონ თავიანთი აპლიკაცია ფუნქციური დონის ავტორიზაციის პრობლემების აღმოსაჩენად და განუწყვეტლივ შეამოწმონ წარმოების კოდი უსაფრთხოების სისუსტეებზე განლაგებამდე. ობიექტის ფუნქციის ავტორიზაციის პრობლემების აღმოსაჩენად, OpenText™ Static Application Security Testing იყენებს წესებს, რომლებიც განსაზღვრავს, თუ როდის არის მოსალოდნელი ავტორიზაციის შემოწმება გარკვეულ პროგრამირების ენებსა და ჩარჩოებში და როდის ხდება ასეთი შემოწმების არარსებობის შესახებ ინფორმაციის მიწოდება.
API6:2023 – მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომა
რა არის ეს?
სნიკერბოტებიდან დაწყებული ბილეთების ბოტებით დამთავრებული, ონლაინ საცალო ვაჭრობის ინვენტარზე მათი API-ების მეშვეობით თავდასხმები ელექტრონული კომერციის საიტებისთვის მნიშვნელოვან პრობლემად იქცა. ბიზნეს მოდელისა და აპლიკაციის ლოგიკის გაგებით, თავდამსხმელს შეუძლია შექმნას API ზარების სერია, რომელსაც შეუძლია ავტომატურად დაჯავშნოს ან შეიძინოს.
17 ბიფერმანი, ჯეისონი. აუდიტის თანახმად, 1.8 მილიონი ტეხასელის პირადი ინფორმაცია, რომლებსაც დაზღვევის დეპარტამენტის მოთხოვნები ჰქონდათ, წლების განმავლობაში გამჟღავნებული იყო. The Texas Tribune. 17 წლის 2022 მაისი.
18 ტეილორი, ჯოშ. Optus-ის მონაცემთა დარღვევა: ყველაფერი, რაც აქამდე ვიცით მომხდარის შესახებ. The Guardian. 28 სექტემბერი, 2022.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

14/23

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

ინვენტარს, რითაც სხვა, ლეგიტიმურ მომხმარებლებს არ შეუძლიათ ბიზნესის პროდუქტებზე ან მომსახურებაზე წვდომა. ნებისმიერი API, რომელიც ბიზნეს პროცესზე წვდომის საშუალებას იძლევა, თავდამსხმელს შეუძლია გამოიყენოს ბიზნესზე ზემოქმედებისთვის და ხვდება მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომის განმარტებაში.
რა ხდის აპლიკაციას დაუცველს?
აპლიკაციების კონტროლი და ლოგიკური ნაკადები ნებისმიერი ონლაინ ბიზნესის გულია და რადგან კომპანიები თავიანთი ოპერაციების მეტ ნაწილს ღრუბელში გადააქვთ, ეს ნაკადები შეიძლება გამოაშკარავდეს და ექსპლუატაციაში შევიდეს. ამ ზედმეტმა წვდომამ შეიძლება ზიანი მიაყენოს ბიზნესს, როდესაც თავდამსხმელები ავტომატიზირებენ პროდუქტების შეძენას, ქმნიან ბოტებს კომენტარების დატოვებისა და ხელახლა გამოყენებისთვის.views, ან საქონლის ან მომსახურების დაჯავშნის ავტომატიზაცია.
თუ აპლიკაცია გთავაზობთ საბოლოო წერტილს, რომელსაც აქვს წვდომა კომპანიის ბიზნეს ნაკადზე საბოლოო წერტილის უკან არსებულ ბიზნეს ოპერაციებზე წვდომის შეზღუდვის გარეშე, მაშინ აპლიკაცია დაუცველი იქნება. დაცვა მოიცავს ერთი მოწყობილობიდან წვდომის მცდელობების რაოდენობის შეზღუდვას თითის ანაბეჭდის აღებით, იმის დადგენას, წარმოიშობა თუ არა აქტივობა ადამიანიდან და იმის დადგენას, ჩართულია თუ არა ავტომატიზაცია.
თავდასხმა ყოფილიamples
როდესაც ტეილორ სვიფტის ბილეთების გაყიდვა Ticketmaster-ზე 2022 წლის ნოემბერში დაიწყო, წინასწარი რეგისტრაცია 1.5 მილიონ მომხმარებელს ჰქონდა გავლილი, თუმცა 14 მილიონზე მეტი მოთხოვნა - მათ შორის სამჯერ მეტი ბოტის ტრაფიკი -...ampბილეთების გაყიდვის დაწყებისთანავე შეძენილი ბმულები და API-ები გაითიშა. საიტი გაითიშა, რამაც ბევრ მომხმარებელს ბილეთების შეძენაში ხელი შეუშალა.19
რესელერ ბოტების შემოტევა ჰგავდა იმ შემოტევას, რომელმაც PlayStation 5-ის გამოშვება 2020 წლის ნოემბერში გაანადგურა. მიწოდების ჯაჭვთან დაკავშირებული პრობლემები უკვე ზღუდავდა მიწოდებას Sony-ს უახლესი სათამაშო კონსოლის გამოშვებამდე, მაგრამ ავტომატიზირებულმა ბოტებმა ხელმისაწვდომი ერთეულების პოვნა კიდევ უფრო გაართულა და ასტრონომიული გადაყიდვის ფასები გამოიწვია. ერთი ელექტრონული კომერციის საიტის შემთხვევაში, „კალათაში დამატების“ ტრანზაქციების რაოდენობა საათში საშუალოდ 15,000 მოთხოვნიდან 27 მილიონზე მეტამდე გაიზარდა, მაღაზიის API-ის გამოყენებით პროდუქტები პირდაპირ SKU ნომრით მოითხოვეს.20
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
დეველოპერებმა უნდა ითანამშრომლონ როგორც ბიზნეს-ოპერაციულ, ასევე საინჟინრო გუნდებთან, რათა მოაგვარონ ბიზნეს ნაკადებზე პოტენციური მავნე წვდომის პრობლემები. ბიზნეს გუნდებს შეუძლიათ API-ების მეშვეობით ამოიცნონ, რომელი ნაკადებია დაუცველი და ჩაატარონ საფრთხის ანალიზი, რათა დაადგინონ, თუ როგორ შეუძლიათ თავდამსხმელებს ამ საბოლოო წერტილების ბოროტად გამოყენება. ამასობაში, დეველოპერებმა DevOps გუნდის ნაწილად უნდა ითანამშრომლონ საინჟინრო ოპერაციებთან, რათა დაადგინონ დამატებითი ტექნიკური თავდაცვითი ზომები, როგორიცაა მოწყობილობის თითის ანაბეჭდის გამოყენება, რათა თავიდან აიცილონ ბრაუზერის ავტომატური ინსტანციების გადატვირთვა და ქცევის ნიმუშების იდენტიფიცირება, რომლებიც განასხვავებენ ადამიანსა და მანქანას შორის მოქმედ პირებს.
19 სტილი, ბილი. Ticketmaster-მა იცის, რომ ბოტებთან დაკავშირებული პრობლემა აქვს, მაგრამ კონგრესისგან მისი გამოსწორება სურს. Engadget. სიახლეების სტატია. 24 წლის 2023 იანვარი.
20 მუვანდი, ტაფარა და უორბარტონი, დავითი. როგორ გააფუჭეს ბოტებმა PlayStation 5-ის გამოშვება მილიონობით მოთამაშისთვის. F5 Labs-ის ბლოგი. F5. Web გვერდი. 18 წლის 2023 მარტი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

15/23

ყველაზე ცნობილი ყოფილიampSSRF-ის თავდასხმის ერთ-ერთი ეპიზოდი, რომელშიც ყოფილი Amazon-ის თანამშრომელი მონაწილეობდა, Web სერვისების (AWS) ინჟინერმა, რომელმაც გამოიყენა არასწორად კონფიგურირებული web აპლიკაციის firewall-ს (WAF), რათა შემდეგ SSRF ხარვეზი გამოიყენოს მონაცემების შესაგროვებლად ფინანსური გიგანტი Capital One-ის კუთვნილი სერვერის ეგზემპლარიდან.

ოპერატიულმა ჯგუფებმა ასევე უნდა გადახედონview ნებისმიერი API, რომელიც შექმნილია სხვა მანქანების მიერ გამოსაყენებლად, მაგალითად, B2B გამოყენების შემთხვევებისთვის, და უზრუნველყოს გარკვეული თავდაცვის მექანიზმების არსებობა, რათა თავდამსხმელებმა არ გამოიყენონ მანქანა-მანქანას შორის ურთიერთქმედება.
რით შეუძლია OpenText-ს დახმარება?
დაუცველი და მგრძნობიარე ბიზნეს ნაკადების დაჭერა ხშირად საბაზისო ნაბიჯების შესრულებაზეა დამოკიდებული. კომპანიებმა უნდა დააფიქსირონ და თვალყური ადევნონ ყველა მოქმედ API-ს და დაადგინონ, რომელი მათგანი ავლენს მგრძნობიარე პროცესებსა და მონაცემებს პოტენციური თავდამსხმელებისთვის. აპლიკაციის ლოგიკა ასევე უნდა გაანალიზდეს ლოგიკური ხარვეზების აღმოსაჩენად, რომელთა გამოყენებაც თავდამსხმელებს შეუძლიათ.
საერთო ჯამში, მგრძნობიარე ბიზნეს ნაკადებზე შეუზღუდავი წვდომის თავიდან აცილება უფრო მეტად აპლიკაციების უსაფრთხოებისადმი ჰოლისტურ მიდგომას ეხება და ნაკლებად კონკრეტული ტექნოლოგიის პოვნას.
API7:2023–სერვერის მხარის მოთხოვნის გაყალბება
რა არის ეს?
ბექენდ სერვერები ამუშავებენ API-ის საბოლოო წერტილების მეშვეობით განხორციელებულ მოთხოვნებს. სერვერის მხარის მოთხოვნის გაყალბება (SSRF) არის დაუცველობა, რომელიც თავდამსხმელს საშუალებას აძლევს, აიძულოს სერვერი, გაგზავნოს მოთხოვნები მისი სახელით და სერვერის პრივილეგიების დონით. ხშირად შეტევა იყენებს სერვერს გარე თავდამსხმელსა და შიდა ქსელს შორის არსებული უფსკრულის შესავსებად. ძირითადი SSRF შეტევები იწვევს თავდამსხმელისთვის პასუხის დაბრუნებას, რაც გაცილებით მარტივი სცენარია, ვიდრე ბრმა SSRF შეტევები, სადაც პასუხი არ ბრუნდება, რის გამოც თავდამსხმელი ვერ ადასტურებს, წარმატებული იყო თუ არა შეტევა.
რა ხდის აპლიკაციას დაუცველს?
სერვერის მხარის მოთხოვნის გაყალბების (SSRF) ხარვეზები არსებითად მომხმარებლის მიერ მოწოდებული შეყვანის მონაცემების არასაკმარისი დადასტურების შედეგია. თავდამსხმელებს შეუძლიათ მოთხოვნების შექმნა და URI-ს ჩართვა, რომელიც სამიზნე აპლიკაციაზე წვდომას უზრუნველყოფს.
თანამედროვე კონცეფციები აპლიკაციების შემუშავებაში, როგორიცაა webOWASP-ის თანახმად, ჰუკები და სტანდარტიზებული აპლიკაციების ჩარჩოები SSRF-ს უფრო გავრცელებულს და უფრო საშიშს ხდის.
ყოფილშიampციტირებულია OWASP-ის მიერ, სოციალური ქსელის მიერ, რომელიც მომხმარებლებს საშუალებას აძლევს ატვირთონ პროfile სურათები შეიძლება დაუცველი იყოს SSRF-ის მიმართ, თუ სერვერი არ დაადასტურებს აპლიკაციაში გაგზავნილ არგუმენტებს. URL სურათზე მითითება, მაგალითად:
POST /api/profile/ატვირთვა _ სურათი
{
„სურათი _ url": "http://example.com/profile _ სურათი.jpg”
}
თავდამსხმელს შეუძლია გააგზავნოს URI, რომელსაც შეუძლია განსაზღვროს, ღიაა თუ არა კონკრეტული პორტი შემდეგი API ზარის გამოყენებით:
{ „სურათი _ url": "ლოკალური მასპინძელი: 8080"
}

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

16/23

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

Blind SSRF-ის შემთხვევაშიც კი, თავდამსხმელს შეეძლო გაეგო, ღიაა თუ არა პორტი პასუხის მისაღებად საჭირო დროის გაზომვით.
თავდასხმა ყოფილიamples
ყველაზე ცნობილი ყოფილიampSSRF-ის თავდასხმის ერთ-ერთი ეპიზოდი, რომელშიც ყოფილი Amazon-ის თანამშრომელი მონაწილეობდა, Web სერვისების (AWS) ინჟინერმა, რომელმაც გამოიყენა არასწორად კონფიგურირებული web აპლიკაციის firewall-ი (WAF), რათა შემდეგ გამოეყენებინა SSRF ხარვეზი ფინანსური გიგანტის Capital One-ის კუთვნილი სერვერის ეგზემპლარიდან მონაცემების შესაგროვებლად. ინციდენტი, რომელიც 2019 წლის ივლისში მოხდა, დაახლოებით 100 მილიონი აშშ-ის მოქალაქის და ექვსი მილიონი კანადის მოქალაქის მონაცემების მოპარვის შედეგად იქნა მოპარული.21 Amazon-ი კომპრომეტირების წყაროდ არასწორ კონფიგურაციას და არა SSRF ხარვეზს მიიჩნევს.22
2022 წლის ოქტომბერში, ღრუბლოვანი უსაფრთხოების ფირმამ Microsoft-ს აცნობა კომპანიის ფლაგმანურ Azure ღრუბლოვან პლატფორმაში არსებული ოთხი SSRF დაუცველობის შესახებ. თითოეული დაუცველობა გავლენას ახდენდა Azure-ის სხვადასხვა სერვისზე, მათ შორის Azure Machine Learning სერვისსა და Azure API Management სერვისზე.23
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
დეველოპერებმა რესურსების მოძიების მექანიზმები თავიანთ კოდში უნდა მოიცვან, გამოყონ ფუნქცია და დაამონტაჟონ დამატების დაცვის ფენები ნებისმიერი მოთხოვნის დასადასტურებლად. რადგან ასეთი ფუნქციები, როგორც წესი, გამოიყენება დისტანციური რესურსების მისაღებად და არა შიდა რესურსების, დეველოპერებმა უნდა დააკონფიგურირონ კაფსულირებული ფუნქციები ისე, რომ გამოიყენონ დაშვებული დისტანციური რესურსების სია და დაბლოკონ შიდა რესურსებზე წვდომის მცდელობები. HTTP გადამისამართება უნდა გამორთოთ რესურსების მოძიების ფუნქციებისთვის და ნებისმიერი მოთხოვნა უნდა გაანალიზდეს მავნე კოდის აღმოსაჩენად.
SSRF-ის სისუსტეების რისკის სრულად აღმოფხვრა ყოველთვის შეუძლებელია, ამიტომ კომპანიებმა ყურადღებით უნდა გაითვალისწინონ გარე რესურსებთან ზარების გამოყენების რისკი.
რით შეუძლია OpenText-ს დახმარება?
OpenText დინამიური აპლიკაციის უსაფრთხოების ტესტირება DevSecOps გუნდებს საშუალებას აძლევს რეგულარულად შეამოწმონ სერვერის მხარეს მოთხოვნის გაყალბება. OpenText™ დინამიური აპლიკაციის უსაფრთხოების ტესტირება სკანირებს აპლიკაციის სერვერს კონფიგურირებულ გარემოში, რათა ყველა კომპონენტის - აპლიკაციის, სერვერის და ქსელის - ტესტირება შესაძლებელი იყოს, რაც დინამიური ანალიზის პლატფორმას ყოვლისმომცველ შესაძლებლობას აძლევს. view სერვერის მოთხოვნების გავლენის შესახებ.
OpenText SAST-ს შეუძლია SSRF-ის მრავალი შემთხვევის აღმოჩენა დაბინძურების ანალიზის გზით - მაგ.ampმაგალითად, თუ აპლიკაცია იყენებს მომხმარებლის დაუდასტურებელ შეყვანას აწყობისთვის URL რომელიც შემდეგ მოძიებული იქნება. ინსტრუმენტი მონიშნავს მომხმარებლის შეუზღუდავი შეყვანის გამოყენებას.

21 ინფორმაცია Capital One-ის კიბერინციდენტის შესახებ. Capitol One-ის საკონსულტაციო. Web გვერდი. განახლებულია 22 წლის 2022 აპრილს.
22 ნგ, ალფრედ. Amazon-ი სენატორებს ეუბნება, რომ Capital One-ის დარღვევაში ის არ არის დამნაშავე. CNET News. com. სიახლეების სტატია. 21 წლის 2019 ნოემბერი.
23 შიტრიტი, ლიდორ ბენ. როგორ აღმოაჩინა ორკამ სერვერის მხარის მოთხოვნის გაყალბების (SSRF) დაუცველობები ოთხ სხვადასხვა Azure სერვისში. Orca-ს უსაფრთხოების ბლოგი. Web გვერდი. 17 წლის 2023 იანვარი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

17/23

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

API8:2023–უსაფრთხოების არასწორი კონფიგურაცია
რა არის ეს?
დეველოპერები ხშირად არასწორად აკონფიგურირებენ თავიანთ აპლიკაციებს, ვერ ახერხებენ განვითარების აქტივების გამოყოფას წარმოების აქტივებისგან და ექსპორტს უწევენ მგრძნობიარე მონაცემებს. files–ასეთი კონფიგურაცია files–მათ საჯარო საცავებში და ნაგულისხმევი კონფიგურაციების შეუცვლელობა. უსაფრთხოების არასწორი კონფიგურაცია მოიცავს აპლიკაციების დაუცველი ნაგულისხმევი კონფიგურაციებით დაყენებას, მგრძნობიარე ფუნქციებსა და მონაცემებზე ზედმეტად ნებადართული წვდომის დაშვებას და აპლიკაციის ინფორმაციის საჯაროდ გამჟღავნებას დეტალური შეცდომის შეტყობინებების საშუალებით.
რა ხდის აპლიკაციას დაუცველს?
აპლიკაციის სტანდარტული კონფიგურაციები ხშირად ზედმეტად ნებადართულია, არ გააჩნიათ უსაფრთხოების გამკაცრება და ღრუბლოვანი საცავის ეგზემპლარებს საზოგადოებისთვის ღიას ტოვებენ. ხშირად, web ჩარჩოები, რომლებზეც აპლიკაციებია დაფუძნებული, მოიცავს აპლიკაციის უამრავ ფუნქციას, რომლებიც არ არის საჭირო და რომელთა ჩართვა ამცირებს უსაფრთხოებას.
ყოფილშიampOWASP-ის მიერ დეტალურად აღწერილი სოციალური ქსელი, რომელიც გთავაზობთ პირდაპირი შეტყობინებების ფუნქციას, უნდა იცავდეს მომხმარებლების კონფიდენციალურობას, მაგრამ ასევე გთავაზობთ API მოთხოვნას კონკრეტული საუბრის მისაღებად შემდეგი მაგალითის გამოყენებით:ampAPI მოთხოვნა:
მიიღეთ /dm/user _ updates.json?conversation _ id=1234567&cursor=GRlFp7LCUAAAA
API-ის საბოლოო წერტილი არ ზღუდავს ქეშში შენახულ მონაცემებს, რის შედეგადაც კერძო საუბრები ქეშში ინახება. web ბრაუზერი. თავდამსხმელებს შეეძლოთ ინფორმაციის ბრაუზერიდან ამოღება, რაც მსხვერპლის პირად შეტყობინებებს გამოაშკარავებდა.
თავდასხმა ყოფილიamples
2021 წლის მაისში, ღრუბლოვანი უსაფრთხოების ფირმამ Microsoft-ს აცნობა, რომ სულ მცირე 47 სხვადასხვა მომხმარებელმა ვერ შეცვალა Microsoft Power Apps-ის მათი ეგზემპლარების ნაგულისხმევი კონფიგურაცია. დაზარალებულ ორგანიზაციებს შორის იყვნენ ისეთი კომპანიები, როგორიცაა American Airlines და Microsoft, ასევე შტატების მთავრობები, როგორიცაა ინდიანას და მერილენდის შტატის მთავრობები, და Power Apps პორტალებზე პოტენციურად გატეხილი იქნა 38 მილიონი ჩანაწერი.24
2022 წელს, დაუცველობის მართვის ფირმამ აღმოაჩინა, რომ Amazon-ზე განთავსებული იყო 12,000 XNUMX ღრუბლოვანი ინსტანცია. Web სერვისები და Azure-ზე განთავსებული 10,500 პროტოკოლი კვლავ ავლენდა Telnet-ის, დისტანციური წვდომის პროტოკოლის, საფრთხეს, რომელიც 2022 წლის ანგარიშის თანახმად, „დღესდღეობით ინტერნეტზე დაფუძნებული ნებისმიერი გამოყენებისთვის შეუფერებლად“ ითვლება.25 არასაჭირო და დაუცველი ფუნქციების ჩართვა ძირს უთხრის API-ებისა და აპლიკაციების უსაფრთხოებას.

24 Upguard-ის კვლევა. დიზაინის მიხედვით: როგორ გამოავლინა Microsoft Power Apps-ის ნაგულისხმევმა ნებართვებმა მილიონობით ადამიანი. Upgard-ის კვლევის ბლოგი. Web გვერდი. 23 წლის 2021 აგვისტო.
25 ბირდსლი, ტოდი. 2022 წლის ღრუბლოვანი სისტემის არასწორი კონფიგურაციების ანგარიში. Rapid7. PDF ანგარიში. გვ. 12. 20 აპრილი, 2022.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

18/23

დოკუმენტაციის „ბრმა წერტილი“ არის ის, როდესაც API-ის დანიშნულების, ფუნქციონირებისა და ვერსიირების დეტალები ბუნდოვანია ამ მნიშვნელოვანი ატრიბუტების დეტალური დოკუმენტაციის ნაკლებობის გამო.

როგორ ავიცილოთ ეს თავიდან დეველოპერის მხრიდან?
DevSecOps გუნდებმა უნდა გაიგონ თავიანთი აპლიკაციებისთვის უსაფრთხო კონფიგურაციების შესაქმნელად საჭირო ნაბიჯები და გამოიყენონ ავტომატიზირებული განვითარების არხი კონფიგურაციის შესამოწმებლად. fileგანლაგებამდე, მათ შორის რეგულარული ერთეულის ტესტები და გაშვების შემოწმებები, რათა პროგრამული უზრუნველყოფა მუდმივად შემოწმდეს კონფიგურაციის შეცდომებზე ან უსაფრთხოების პრობლემებზე. უსაფრთხოება, როგორც კოდი, დაგეხმარებათ კონფიგურაციების განმეორებადობის გაზრდით და აპლიკაციის უსაფრთხოების გუნდებისთვის კონკრეტული აპლიკაციის კომპონენტებისთვის სტანდარტული კონფიგურაციის ნაკრებების დაყენების შესაძლებლობის მიცემით.
უსაფრთხო განვითარების სასიცოცხლო ციკლის ფარგლებში, დეველოპერებმა და ოპერაციების გუნდებმა უნდა:
· ისეთი გამკვრივების პროცესის შექმნა, რომელიც ამარტივებს უსაფრთხო აპლიკაციის გარემოს განმეორებით შექმნას და შენარჩუნებას,
· რეview და განაახლოთ API დასტის ყველა კონფიგურაცია ახალი სტანდარტის თანმიმდევრულად ინტეგრირებისთვის, და
· კონფიგურაციის პარამეტრების ეფექტურობის შეფასების ავტომატიზაცია ყველა გარემოში.
რით შეუძლია OpenText-ს დახმარება?
OpenText სტატიკური აპლიკაციის უსაფრთხოების ტესტირებას შეუძლია შეამოწმოს კონფიგურაციები შემუშავების პროცესში და აღმოაჩინოს მრავალი სახის სისუსტე. რადგან უსაფრთხოების არასწორი კონფიგურაციები ხდება როგორც აპლიკაციის კოდის, ასევე ინფრასტრუქტურის დონეზე, არასწორი კონფიგურაციების აღმოსაჩენად შეიძლება გამოყენებულ იქნას სხვადასხვა OpenText პროდუქტი.
OpenText სტატიკური აპლიკაციის უსაფრთხოების ტესტირების სკანირებას შეუძლია შეამოწმოს აპლიკაციის კოდი არასწორი კონფიგურაციის პრობლემების აღმოსაჩენად. სტატიკური ანალიზის შემოწმების დროს, OpenText SAST-ს შეუძლია შეაფასოს კონფიგურაცია. fileუსაფრთხოების შეცდომებისთვის, მათ შორის Docker-ის, Kubernetes-ის, Ansible-ის, Amazon-ის შეცდომებისთვის Web სერვისების, CloudFormation-ის, Terraform-ის და Azure Resource Manager-ის შაბლონები.
კონფიგურაციის შეცდომების აღმოჩენა ასევე შესაძლებელია გაშვების დროს. OpenText დინამიური აპლიკაციის უსაფრთხოების ტესტირება DevSecOps გუნდებს საშუალებას აძლევს რეგულარულად შეამოწმონ უსაფრთხოების საერთო არასწორი კონფიგურაციები. DAST სკანირების ერთ-ერთი უდიდესი ძლიერი მხარე ის არის, რომ ის მუშაობს აპლიკაციის სერვერზე კონფიგურირებულ გარემოში, რაც ნიშნავს, რომ მთელი გარემო - აპლიკაცია, სერვერი და ქსელი - ერთდროულად ტესტირდება, რაც დინამიური ანალიზის პლატფორმას ყოვლისმომცველ შესაძლებლობას აძლევს. view წარმოების გარემო კონფიგურირებულია.
API9:2023 – ინვენტარიზაციის არასწორი მართვა
რა არის ეს?
პროგრამული უზრუნველყოფის უმეტესი აქტივების მსგავსად, API-ებსაც აქვთ სასიცოცხლო ციკლი, რომლის დროსაც ძველი ვერსიები ჩანაცვლებულია უფრო უსაფრთხო და ეფექტური API-ებით ან, სულ უფრო ხშირად, გამოიყენება მესამე მხარის სერვისებთან დაკავშირებული API. DevSecOps გუნდები, რომლებიც არ ინარჩუნებენ თავიანთ API ვერსიებსა და დოკუმენტაციას, შეიძლება შექმნან დაუცველობები, როდესაც ძველი, არასრულყოფილი API ვერსიები კვლავ გამოიყენება - სისუსტე, რომელიც ცნობილია როგორც არასათანადო ინვენტარიზაციის მართვა. ინვენტარიზაციის მართვის საუკეთესო პრაქტიკა მოითხოვს თვალყურის დევნებას.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

19/23

API ვერსიები, ინტეგრირებული სერვისების რეგულარული შეფასება და ინვენტარიზაცია, ასევე მემკვიდრეობით მიღებული ვერსიების რეგულარული მოძველება უსაფრთხოების დაუცველობების გავრცელების თავიდან ასაცილებლად.
რა ხდის აპლიკაციას დაუცველს?
API-ებზე დამოკიდებული პროგრამული უზრუნველყოფის არქიტექტურები, განსაკუთრებით მიკროსერვისის არქიტექტურის გამოყენებით შექმნილი არქიტექტურები, ტრადიციულ არქიტექტურებთან შედარებით, უფრო მეტ საბოლოო წერტილს ავლენს. web აპლიკაციები. API საბოლოო წერტილების სიმრავლე, API-ის მრავალი ვერსიის ერთდროულად არსებობის ალბათობასთან ერთად, მოითხოვს API პროვაიდერის მხრიდან დამატებით მართვის რესურსებს, რათა თავიდან იქნას აცილებული შეტევის ზედაპირის გაფართოება. OWASP განსაზღვრავს ორ მთავარ ბრმა წერტილს, რომელიც DevSecOps გუნდებს შეიძლება ჰქონდეთ თავიანთი API ინფრასტრუქტურის მიმართ.
პირველ რიგში, დოკუმენტაციის „ბრმა წერტილი“ არის ის, როდესაც API-ის დანიშნულების, ფუნქციონირებისა და ვერსიირების დეტალები ბუნდოვანია ამ მნიშვნელოვანი ატრიბუტების დეტალური დოკუმენტაციის ნაკლებობის გამო.
მეორეც, მონაცემთა ნაკადის ბრმა წერტილი მაშინ ჩნდება, როდესაც API-ები გამოიყენება არასაკმარისი სიცხადით, რაც იწვევს ისეთ შესაძლებლობებს, რომლებიც არ უნდა იყოს დაშვებული ძლიერი ბიზნეს გამართლების გარეშე. მგრძნობიარე მონაცემების მესამე მხარესთან გაზიარება უსაფრთხოების გარანტიების გარეშე, მონაცემთა ნაკადის საბოლოო შედეგის ხილვადობის ნაკლებობა და ყველა მონაცემთა ნაკადის ჯაჭვურ API-ებში რუკის შეუსრულებლობა - ეს ყველაფერი ბრმა წერტილებია.
როგორც ყოფილიampმაგალითად, OWASP-ის ანგარიშში მოყვანილია გამოგონილი სოციალური ქსელი, რომელიც მესამე მხარის დამოუკიდებელ აპლიკაციებთან ინტეგრაციის საშუალებას იძლევა. მიუხედავად იმისა, რომ საბოლოო მომხმარებლის თანხმობაა საჭირო, სოციალური ქსელი არ ინარჩუნებს მონაცემთა ნაკადის საკმარის ხილვადობას, რათა ხელი შეუშალოს ქვედა რგოლებს მონაცემებზე წვდომაში, მაგალითად, არა მხოლოდ მომხმარებლის, არამედ მისი მეგობრების აქტივობის მონიტორინგში.
თავდასხმა ყოფილიamples
2013 და 2014 წლებში, Facebook-ის პლატფორმაზე 300,000 87-მდე ადამიანმა გაიარა ონლაინ ფსიქოლოგიური ვიქტორინა. ვიქტორინის შემქმნელმა კომპანიამ, Cambridge Analytica-მ, არა მხოლოდ ამ მომხმარებლების, არამედ მათი დაკავშირებული მეგობრების შესახებ ინფორმაციაც შეაგროვა - მოსახლეობა, რომელიც სულ XNUMX მილიონ ადამიანს შეადგენდა, რომელთა აბსოლუტურმა უმრავლესობამ არ მისცა ნებართვა მათი ინფორმაციის შეგროვების შესახებ. შემდეგ კომპანიამ ეს ინფორმაცია გამოიყენა კლიენტების სახელით ამ ადამიანებისთვის რეკლამებისა და შეტყობინებების მოსარგებად, მათ შორის ტრამპის მხარდამჭერი პოლიტიკური რეკლამების გასაგზავნად.amp2016 წლის არჩევნებში მონაწილეობა.26 Facebook-ის მიერ იმის შესახებ ხილვადობის ნაკლებობა, თუ როგორ იყენებდნენ მესამე მხარეები მისი პლატფორმიდან შეგროვებულ ინფორმაციას, ყოფილიampინვენტარის არასათანადო მართვის ფაქტი.
როგორ ავიცილოთ ეს თავიდან, როგორც დეველოპერმა?
DevSecOps გუნდებმა უნდა აწარმოონ ყველა API ჰოსტის დოკუმენტირება და ყურადღება გაამახვილონ API-ებსა და მესამე მხარის სერვისებს შორის მონაცემთა ნაკადების ხილვადობის შენარჩუნებაზე. ინვენტარიზაციის არასწორი მართვის თავიდან აცილების ძირითადი გზაა ყველა API სერვისისა და ჰოსტის კრიტიკული ასპექტების დეტალური დოკუმენტირება, მათ შორის ინფორმაცია იმის შესახებ, თუ რა მონაცემებს ამუშავებენ ისინი, ვის აქვს წვდომა ჰოსტებსა და მონაცემებზე.
26 როზენბერგი, მეთიუ და დენსი, გაბრიელი. „თქვენ ხართ პროდუქტი“: კემბრიჯ ანალიტიკას სამიზნე Facebook-ზე. The New York Times. სტატია სიახლეებში. 8 წლის 2018 აპრილი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

20/23

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

და თითოეული ჰოსტის კონკრეტული API ვერსიები. ტექნიკური დეტალები, რომლებიც უნდა იყოს დოკუმენტირებული, მოიცავს ავთენტიფიკაციის იმპლემენტაციას, შეცდომების დამუშავებას, სიჩქარის შეზღუდვისგან დაცვას, ჯვარედინი წარმოშობის რესურსების გაზიარების (CORS) პოლიტიკას და თითოეული საბოლოო წერტილის დეტალებს.
დოკუმენტაციის მნიშვნელოვანი მოცულობის ხელით მართვა რთულია, ამიტომ რეკომენდებულია დოკუმენტაციის გენერირება უწყვეტი ინტეგრაციის პროცესის მეშვეობით და ღია სტანდარტების გამოყენებით. API დოკუმენტაციაზე წვდომა ასევე უნდა შეიზღუდოს იმ დეველოპერებისთვის, რომლებსაც აქვთ API-ს გამოყენების უფლებამოსილება.
აპლიკაციის შექმნისა და ტესტირების ფაზების დროს, დეველოპერებმა თავი უნდა აარიდონ წარმოების მონაცემების გამოყენებას შემუშავების ან ტესტირების ფაზებზე.tagაპლიკაციის რედაქტირებული ვერსიები მონაცემთა გაჟონვის თავიდან ასაცილებლად. როდესაც API-ების ახალი ვერსიები გამოვა, DevSecOps გუნდმა უნდა ჩაატაროს რისკების ანალიზი, რათა განსაზღვროს აპლიკაციების განახლების საუკეთესო მიდგომა უპირატესობების მისაღებად.tagგაზრდილი უსაფრთხოების ე.
რით შეუძლია OpenText-ს დახმარება?
ორგანიზაციებს შეუძლიათ მართონ, აკონტროლონ, დაიცვან და დოკუმენტირება გაუკეთონ API-ს გამოყენებას OpenText™ Secure API Manager-ის გამოყენებით, რომელიც საშუალებას აძლევს აპლიკაციების უსაფრთხოების გუნდებს შეინარჩუნონ API აქტივების განახლებული ინვენტარი. OpenText Secure API Manager უზრუნველყოფს ავტორიტეტულ საცავს, სადაც თქვენს DevSecOps გუნდს შეუძლია შეინახოს და მართოს ორგანიზაციის მიერ გამოყენებული ყველა API, რაც უზრუნველყოფს მარტივად სამართავ სასიცოცხლო ციკლს API-ის შემუშავებიდან გაუქმებამდე. პროგრამული უზრუნველყოფა ხელს უწყობს რეგულაციებთან და ლიცენზირებასთან შესაბამისობის გაუმჯობესებას დეტალური ანალიტიკის ჩატარების შესაძლებლობის საშუალებით.
API10:2023 – API-ების არაუსაფრთხო მოხმარება
რა არის ეს?
აპლიკაციების შესაქმნელად მშობლიური ღრუბლოვანი ინფრასტრუქტურის მზარდი გამოყენების გამო, API-ები აპლიკაციის კომპონენტებს შორის ინტეგრაციის წერტილად იქცა. თუმცა, API-ების მეშვეობით წვდომის მქონე მესამე მხარის სერვისების უსაფრთხოების მდგომარეობა იშვიათად არის ნათელი, რაც თავდამსხმელებს საშუალებას აძლევს განსაზღვრონ, რომელ სერვისებს ეყრდნობა აპლიკაცია და აქვს თუ არა ამ სერვისებიდან რომელიმეს უსაფრთხოების სისუსტეები. დეველოპერები, როგორც წესი, ენდობიან იმ საბოლოო წერტილებს, რომლებთანაც მათი აპლიკაცია ურთიერთქმედებს გარე ან მესამე მხარის API-ების შემოწმების გარეშე. API-ების ეს არასაიმედო მოხმარება ხშირად იწვევს აპლიკაციის დამოკიდებულებას იმ სერვისებზე, რომლებსაც აქვთ უფრო სუსტი უსაფრთხოების მოთხოვნები ან არ გააჩნიათ ფუნდამენტური უსაფრთხოების გამკაცრება, როგორიცაა შეყვანის ვალიდაცია.
რა ხდის აპლიკაციას დაუცველს?
დეველოპერები, როგორც წესი, მესამე მხარის API-ებიდან მიღებულ მონაცემებს უფრო მეტად ენდობიან, ვიდრე მომხმარებლის მიერ შეყვანილ მონაცემებს, თუმცა მოტივირებული თავდამსხმელისთვის ეს ორი წყარო არსებითად ექვივალენტურია. ამ არასწორი ნდობის გამო, დეველოპერები, არსებითად, უფრო სუსტ უსაფრთხოების სტანდარტებს ეყრდნობიან შეყვანილი მონაცემების ვალიდაციისა და სანიტიზაციის ნაკლებობის გამო.
API-ების სახიფათო მოხმარება შეიძლება მოხდეს, თუ აპლიკაცია:
· იყენებს ან მოიხმარს სხვა API-ებს დაუშიფრავი კომუნიკაციების გამოყენებით,
· ვერ ახერხებს სხვა API-ებიდან ან სერვისებიდან მონაცემების დადასტურებას და დეზინფექციას,
· გადამისამართების საშუალებას იძლევა უსაფრთხოების შემოწმების გარეშე, ან

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

21/23

თუ დეველოპერი თავის აპლიკაციაში არ შეიტანს უსაფრთხოების შემოწმებებს API-ის საბოლოო წერტილის მიერ დაბრუნებული ნებისმიერი მონაცემის დასადასტურებლად, მისი აპლიკაცია მიჰყვება გადამისამართებას და თავდამსხმელს გაუგზავნის მგრძნობიარე სამედიცინო ინფორმაციას.
OWASP API-ის უსაფრთხოების ტოპ-10 სია გადამწყვეტი მნიშვნელობისაა ღრუბლოვანი დეველოპერებისთვის, რომლებიც API-ებს ქმნიან. თუმცა, პრიორიტეტი უნდა მიენიჭოს ისეთი გავრცელებული აპლიკაციების დაუცველობების მოგვარებას, როგორიცაა SQL ინექცია, მონაცემთა ექსპოზიცია და უსაფრთხოების არასწორი კონფიგურაცია, რადგან მათ ხშირად იყენებენ კიბერ საფრთხეები. API-ის უსაფრთხოების ტოპ-10 სია უსაფრთხო პროგრამული უზრუნველყოფის შემუშავების აუცილებელი ნაწილია, მაგრამ ის მეორეხარისხოვანი უნდა იყოს ზოგადი აპლიკაციების დაუცველობების მოგვარებასთან შედარებით.

· ვერ ახერხებს რესურსების მოხმარების შეზღუდვას ზღურბლებისა და ტაიმ-აუტების გამოყენებით.
ყოფილშიampOWASP ანგარიშიდან გამომდინარე, API-მ, რომელიც ინტეგრირდება მესამე მხარის სერვისის პროვაიდერთან მომხმარებლის მგრძნობიარე სამედიცინო ინფორმაციის შესანახად, შესაძლოა პირადი მონაცემები გაგზავნოს API-ის საბოლოო წერტილის მეშვეობით. თავდამსხმელებს შეუძლიათ მესამე მხარის API ჰოსტის კომპრომეტირება, რათა მათ მომავალ მოთხოვნებზე რეაგირება მოახდინონ 308 მუდმივი გადამისამართება: HTTP/1.1 308 მუდმივი გადამისამართება
მდებარეობა: https://attacker.com/
თუ დეველოპერი თავის აპლიკაციაში არ შეიტანს უსაფრთხოების შემოწმებებს API-ის საბოლოო წერტილის მიერ დაბრუნებული ნებისმიერი მონაცემის დასადასტურებლად, მისი აპლიკაცია მიჰყვება გადამისამართებას და თავდამსხმელს გაუგზავნის მგრძნობიარე სამედიცინო ინფორმაციას.
თავდასხმა ყოფილიamples
2021 წლის დეკემბერში, ღია კოდის პროგრამული უზრუნველყოფის კომპონენტში, Log4J-ში, დაუცველობების ერთობლიობამ თავდამსხმელს საშუალება მისცა, მიეწოდებინა არასანიტარიზებული შეყვანა, როგორიცაა კოდირებული სკრიპტი, და გამოეყენებინა Log4J-ის დაუცველი ვერსიები სერვერზე სკრიპტის შესასრულებლად. Log4J დაუცველობის პრობლემა წარმოიშვა შეყვანის ვალიდაციის არარსებობით, კერძოდ, მომხმარებლის მიერ მოწოდებული დესერიალიზებული მონაცემების უსაფრთხოების შემოწმების ჩაუტარებლობით. სერიალიზებული მავნე კოდის გაგზავნით, თავდამსხმელებს შეეძლოთ დაუცველობის გამოყენება და დაუცველობის მქონე სერვერზე შეტევა. დეველოპერებმა უნდა შეამოწმონ მესამე მხარის API-ების და სხვა გარე წყაროების მიერ მოწოდებული ყველა შეყვანა.27
როგორ ავიცილოთ ეს თავიდან დეველოპერის მხრიდან?
დეველოპერებმა უნდა გამოიჩინონ სათანადო გულმოდგინება სერვისის პროვაიდერების შეფასების, მათი API უსაფრთხოების მდგომარეობის შეფასებისა და მკაცრი უსაფრთხოების კონტროლის განხორციელებისას. გარდა ამისა, დეველოპერებმა უნდა დაადასტურონ, რომ მესამე მხარის API-ებთან და მესამე მხარეებიდან ორგანიზაციის API-ებთან ყველა კომუნიკაცია იყენებს უსაფრთხო საკომუნიკაციო არხს, რათა თავიდან აიცილონ თვალთვალი და განმეორებითი შეტევები.
გარე მომხმარებლებისა და მანქანებისგან მონაცემების მიღებისას, შეყვანის მონაცემები ყოველთვის უნდა იყოს გასუფთავებული, რათა თავიდან იქნას აცილებული კოდის შემთხვევითი შესრულება. და ბოლოს, API-ების მეშვეობით ინტეგრირებული ღრუბლოვანი სერვისებისთვის, ინტეგრირებული გადაწყვეტის მისამართის დასაბლოკად უნდა იქნას გამოყენებული დაშვების სიები და არა ნებისმიერი IP მისამართისთვის აპლიკაციის API-ს გამოძახების ბრმად დაშვება.
რით შეუძლია OpenText-ს დახმარება?
OpenText Static Application Security Testing-ის სტატიკური კოდისა და API ანალიზის ფუნქციების OpenText Dynamic Application Security Testing (DAST) პაკეტის გაშვების შემოწმებებთან გაერთიანებით, DevSecOps გუნდებს შეუძლიათ შეამოწმონ თავიანთი აპლიკაციების მიერ მესამე მხარის API-ების გამოყენება და გამოსცადონ შეტევის გავრცელებული ტიპები. სახიფათო API-ების მოსაძებნად, OpenText Secure API Manager-ს შეუძლია შექმნას სისტემის მიერ გამოძახებული ყველა API-ს საცავი, ასევე ის გარე აპლიკაციები, რომლებსაც შეუძლიათ თქვენი აპლიკაციის API-ების გამოყენება.
27 Microsoft-ის საფრთხის შესახებ ინტელექტი. Log4j 2 დაუცველობის პრევენციის, გამოვლენისა და ექსპლუატაციის ძიების სახელმძღვანელო. Microsoft. Web გვერდი. განახლებულია: 10 წლის 2022 იანვარი.

დეველოპერის სახელმძღვანელო 2023 წლის OWASP-ის API უსაფრთხოების ტოპ 10-ისთვის

22/23

სად წავიდეთ შემდეგ
აქ მოცემულია ამ დოკუმენტში ნახსენები პროდუქტები: OpenText აპლიკაციის უსაფრთხოება >
OpenText სტატიკური აპლიკაციის უსაფრთხოების ტესტირება >
OpenText დინამიური აპლიკაციის უსაფრთხოების ტესტირება >
OpenText-ის უსაფრთხო API მენეჯერი >
დამატებითი რესურსები OWASP API-ს უსაფრთხოების ტოპ 10 რისკი - 2023 >
Gartner-ის მაგიური კვადრანტი აპლიკაციების უსაფრთხოების ტესტირებისთვის >
OpenText აპლიკაციის უსაფრთხოება Webინარის სერია >

API უსაფრთხოების ტოპ-10 საკმარისი არ არის!
ღრუბლოვანი დეველოპერებისთვის, რომლებიც კონკრეტულად ორიენტირებულნი არიან API-ების შექმნაზე, რათა შესთავაზონ მომსახურება აპლიკაციის სხვა ნაწილებს, შიდა მომხმარებლებს ან გლობალური მოხმარებისთვის, OWASP API Security Top 10 სია მნიშვნელოვანი დოკუმენტია წასაკითხად და გასაგებად.
თუმცა, OWASP API-ის უსაფრთხოების ტოპ 10 არ არის დამოუკიდებელი დოკუმენტი. დეველოპერებმა ასევე უნდა დარწმუნდნენ, რომ იყენებენ საუკეთესო პრაქტიკის სხვა წყაროებს, როგორიცაა OWASP ტოპ 10, რომლებიც შეესაბამება მათ მიმდინარე აპლიკაციას და არქიტექტურას. აპლიკაციის საერთო დაუცველობები - SQL ინექცია, მონაცემთა ექსპოზიცია და უსაფრთხოების არასწორი კონფიგურაცია - კვლავაც გავრცელებული გზებია, რომლითაც კიბერსაფრთხის ჯგუფებს შეუძლიათ კორპორატიული ინფრასტრუქტურის საფრთხე შეუქმნან და სწრაფად უნდა გამოსწორდნენ. გარდა ამისა, ზოგიერთ API-ზე დაფუძნებულ აპლიკაციას, როგორიცაა მობილური აპლიკაციები, სჭირდება აპლიკაციის უსაფრთხოების გამყარების განსხვავებული ნაბიჯები, ვიდრე დამოუკიდებელ აპლიკაციას. web-app და განსხვავდება იმისგან, რაც შეიძლება საჭირო გახდეს Connect და IoT მოწყობილობებისთვის. საერთო ჯამში, API Security Top 10 სია მნიშვნელოვანია, მაგრამ ის მხოლოდ უსაფრთხო პროგრამული უზრუნველყოფის შემუშავების სასიცოცხლო ციკლის ერთ ასპექტად რჩება. სია და OWASP Top 10 სია უნდა იქნას გამოყენებული ანალიზის ქვეშ მყოფი გადაწყვეტისთვის საჭირო სხვა შესაბამის სტანდარტთან და საუკეთესო პრაქტიკასთან ერთად.
დასკვნა
რადგან აპლიკაციები სულ უფრო მეტად არის დამოკიდებული ღრუბლოვან ინფრასტრუქტურაზე, web აპლიკაციების პროგრამირების ინტერფეისები (API) ინტერნეტის საფუძვლად იქცა. კომპანიებს, როგორც წესი, თავიანთ გარემოში ასობით, თუ არა ათასობით, API საბოლოო წერტილი აქვთ, რაც მკვეთრად ზრდის მათი შეტევის ზედაპირს და აპლიკაციებს სხვადასხვა სისუსტეების წინაშე აყენებს.
2023 წლის OWASP API უსაფრთხოების ტოპ 10 სიის გამოქვეყნება კარგი საწყისი წერტილია კომპანიებისა და დეველოპერებისთვის, რათა გაერკვნენ API-ზე დაფუძნებული ინფრასტრუქტურის რისკებში და შეაფასონ საკუთარი აპლიკაციები. უფრო ცნობილ აპლიკაციების უსაფრთხოების ტოპ 10 სიასთან ერთად, ორი რეიტინგი შეიძლება დაეხმაროს DevSecOps გუნდებს თავიანთი აპლიკაციების საერთო უსაფრთხოებისადმი ჰოლისტური მიდგომის შემუშავებაში.
DevSecOps გუნდებმა უნდა იცოდნენ API-ების უსაფრთხოების შედეგების შესახებ, თუ როგორ შეამცირონ იმპლემენტაციის დაუცველობა და უსაფრთხოების სისუსტეები და როგორ გააძლიერონ თავიანთი შემუშავების პროცესი და შედეგად მიღებული API სერვერი, რათა თავდამსხმელებს გაუადვილდეთ აპლიკაციის კომპრომეტირება მისი API-ების მეშვეობით.

Copyright © 2025 ღია ტექსტი · 04.25 | 262-000177-001

დოკუმენტები / რესურსები

OpenText 262-000177-001 OWASP API უსაფრთხოების ტოპ 10 [pdf] მომხმარებლის სახელმძღვანელო 262-000177-001, 262-000177-001 OWASP ტოპ 10 API უსაფრთხოებისთვის, 262-000177-001, OWASP ტოპ 10 API უსაფრთხოებისთვის, API უსაფრთხოებისთვის, API უსაფრთხოება, უსაფრთხოება

ცნობები

• მომხმარებლის სახელმძღვანელო