მთავარი დასკვნა
აღწერეთ მონაცემთა ნაკადები და ნდობის საზღვრები, თითოეულ რისკს შემოწმებადი კონტროლი დაუკავშირეთ და გამოსწორების შემდეგ შემოწმება გაიმეორეთ.
საფრთხეები დიზაინის ეტაპიდანვე მოდელირეთ
აღრიცხეთ სისტემის კომპონენტები, მგრძნობიარე აქტივები, მონაცემთა ნაკადები და ნდობის საზღვრები. თითოეულ საზღვარსა და ოპერაციაზე გუნდს ჰკითხეთ, რა შეიძლება წარიმართოს არასწორად. STRIDE უბიძგებს გაყალბების, ცვლილების, ქმედების უარყოფის, გამჟღავნების, მომსახურების უარყოფისა და პრივილეგიების ამაღლების განხილვას; შეტევის ხე მიზნამდე გზებს იკვლევს, ბოროტად გამოყენების სცენარი კი კანონიერი სამუშაო პროცესის საზიანო გამოყენებას ამოწმებს. აირჩიეთ სისტემისთვის შესაფერისი მეთოდი, აღრიცხეთ ალბათობა და გავლენა, მიუჩინეთ მფლობელი და შემარბილებელი ზომა და მოდელს არქიტექტურის ან დამოკიდებულებების ცვლილებისას გადახედეთ.
გამოავლინეთ აქტივი და ნაკადი
მაგალითად, აღწერეთ ანგარიშის მონაცემების გზა ბრაუზერიდან API‑მდე და მონაცემთა ბაზამდე.
შეისწავლეთ საზღვარი
აღრიცხეთ იდენტობის, ავტორიზაციის, არასანდო შეყვანისა და კომპონენტის გატეხვის რისკები.
კონტროლი ტესტით გადაამოწმეთ
თითოეულ მაღალ რისკს მფლობელი, შემარბილებელი ზომა და განმეორებითი ტესტი მიუჩინეთ.
ინექციის, SQLi‑ისა და RCE‑ისგან დაცვის ძირითადი საშუალებები
ინექცია მაშინ ხდება, როცა არასანდო შეყვანა SQL‑ის, გარსის ან სხვა ინტერპრეტატორის კოდად აღიქმება. მაგალითად, შესვლის მოთხოვნაში მომხმარებლის სახელის ტექსტური მიერთება შეყვანას SQL სინტაქსად აქცევს; პარამეტრიზებული მოთხოვნა მას მნიშვნელობად ინარჩუნებს და არა კოდად. დამატებით შრედ დაამატეთ სერვერული დასაშვები სიები და ტიპების შემოწმება. სადაც შესაძლებელია, მოერიდეთ გარსის გამოძახებას; სხვაგვარად არგუმენტები ცალკე გადაეცით და პრივილეგიები შეზღუდეთ. დესერიალიზაციისას მიიღეთ მხოლოდ მოსალოდნელი ტიპები და მოერიდეთ თვითნებური ობიექტების შექმნას; გადახედეთ მეხსიერების უსაფრთხოებასა და საზღვრების შემოწმებას. RCE‑ს გატეხილ პროცესში კოდის შესრულება შეუძლია, ამიტომ განაახლეთ ღია სერვისები, შეზღუდეთ შესრულების უფლებები და გამავალი კავშირები და გამოსცადეთ გამოვლენა და აღდგენა.
შიდაარხული SQLi
აპლიკაცია შედეგებს იმავე არხით აბრუნებს; აქ შედის შეცდომებსა და UNION‑ზე დაფუძნებული შემთხვევები.
ბრმა SQLi
როცა შედეგები უშუალოდ არ ჩანს, თავდამსხმელმა ისინი შეიძლება ლოგიკური პასუხების სხვაობით ან დროით გამოიტანოს.
გარეარხული SQLi
მონაცემები შეიძლება მონაცემთა ბაზის სერვერიდან ცალკე DNS ან HTTP კავშირით გავიდეს; შეზღუდეთ გამავალი კავშირები და ბაზის პრივილეგიები.
სხვადასხვა ტესტი სხვადასხვა სისუსტეს პოულობს
SAST აპლიკაციის გაშვების გარეშე აღნიშნავს სარისკო კოდის ნიმუშებს; ცრუ დადებითი შედეგები და მიუწვდომელი გზები ხელით განიხილეთ. SCA დამოკიდებულებებს ცნობილ მოწყვლადობებთან ამოწმებს, SBOM კი აპლიკაციის კომპონენტებს აღრიცხავს. DAST გაშვებულ აპლიკაციას გარე მოთხოვნებს უგზავნის და ავთენტიფიკაციის, კონფიგურაციის, XSS‑ისა და ინექციის პრობლემებს ეძებს მხოლოდ ნაცადი მარშრუტებისა და როლების ფარგლებში. IAST‑ს შესრულებისას დაკვირვების კოდის კონტექსტთან გაერთიანება შეუძლია, თუმცა მხოლოდ ნაცად ნაკადებს ხედავს. OWASP Top 10 სასარგებლო საწყისი წერტილია; საკუთარ სისტემაში გამოსცადეთ წვდომის კონტროლის, ინექციის, კრიპტოგრაფიის, XSS‑ისა და არასწორი კონფიგურაციის რისკები. ერთეულის ტესტების გამეორება უფრო მარტივია, როცა გარე სერვისებისა და ბაზებისგან იზოლირებულია; ინტეგრაციის ტესტები მოდულების საზღვრებსა და აუდიტის ნაკადებს ამოწმებს. ფაზინგი მოულოდნელი შეყვანით ზღვრულ შემთხვევებს იკვლევს. ტესტერის წინასწარი ცოდნა განსაზღვრეთ როგორც შავი, თეთრი ან ნაცრისფერი ყუთი და ცალკე შეათანხმეთ სამიზნე სისტემები და დასაშვები მოქმედებები. სკანირებები და შეღწევადობის ტესტები ერთმანეთს ავსებს.
შესრულებისას კონტროლები აპლიკაციის კონტექსტში შეაფასეთ
RASP აპლიკაციის შიგნით შესრულების კონტექსტს აკვირდება და კონფიგურირებული წესებით მოთხოვნების ან ოპერაციების დაბლოკვა შეუძლია. WAF HTTP ტრაფიკს აპლიკაციამდე მიღწევამდე ამოწმებს. პილოტში გამოსცადეთ თქვენი ენისა და ფრეიმვორკის მხარდაჭერა, ბლოკირების რეჟიმი, დაყოვნება, ცრუ დადებითი შედეგები და განახლების პროცესი. გამოსცადეთ აპლიკაციის რეალური სამუშაო პროცესები და კონტროლირებადი შეტევის სიმულაციები, ტესტირებისას აღმოჩენილი კოდისა და კონფიგურაციის ხარვეზები კი აღმოფხვერით.
| კონტროლი | სად მოქმედებს | რა უნდა გადაამოწმოთ |
|---|---|---|
| SAST / SCA | კოდისა და დამოკიდებულებების ცვლილებებზე | დაფარვა, ცრუ დადებითი შედეგები, გამოსწორების მფლობელი |
| DAST / შეღწევადობის ტესტი | გაშვებულ სერვისსა და მის ინტერფეისებზე | როლებისა და მარშრუტების დაფარვა, ტესტის უსაფრთხო საზღვრები |
| WAF / RASP | ქსელის კიდეზე / აპლიკაციის შესრულების გარემოში | თავსებადობა, დაყოვნება, ბლოკირება და აუდიტი |
კონფიგურაცია და ღრუბლოვანი კონტროლები კოდით მართეთ
შეცვალეთ ნაგულისხმევი ავტორიზაციის მონაცემები, გამორთეთ გამოუყენებელი სერვისები და პორტები, შეამცირეთ წვდომა და IAM უფლებები, დაიცავით მონაცემები გადაცემისა და შენახვისას. დანერგვამდე დაასკანირეთ Infrastructure as Code ღრუბლოვანი საცავების, უსაფრთხოების ჯგუფების, API‑ებისა და იდენტობის წესების მხრივ; ცოცხალი პარამეტრები გამოცხადებულ კონფიგურაციას შეადარეთ გადახრების გამოსავლენად. მრავალი ღრუბლის გარემოში ანგარიშის მიტაცებას, ზედმეტ გაზიარებასა და ღია API‑ებს ფართო გავლენა შეიძლება ჰქონდეს. CNAPP მიდგომას შეუძლია CSPM‑ის, CWPP‑ისა და CIEM‑ის IaC სკანირებასთან გაერთიანება; WAAP‑ს — WAF‑ის, ბოტებისა და DDoS‑ის კონტროლების API‑ის სიხშირის შეზღუდვასთან დაკავშირება. ეს გადაწყვეტების კატეგორიებია, ამიტომ კონკრეტული პროდუქტის დაფარვა გადაამოწმეთ. სერვისის მოდელისთვის აღწერეთ, პლატფორმის რომელ შრეებს მართავს პროვაიდერი და სამუშაო დატვირთვის, იდენტობის, ქსელისა თუ მონაცემების რომელი კონტროლები რჩება თქვენს გუნდთან.
მიადევნეთ მიგნებებს გამოსწორებამდე და განმეორებით ტესტირებამდე
თითოეული მიგნებისთვის აღრიცხეთ დაზარალებული აქტივი, მტკიცებულება, რისკი, მფლობელი, უსაფრთხო დროებითი შემარბილებელი ზომა და მუდმივი გამოსწორება. პრიორიტეტი ექსპლუატაციის შესაძლებლობასა და პოტენციურ გავლენას დაუფუძნეთ და არა მხოლოდ ხელსაწყოს ქულას. გამოსწორების შემდეგ იგივე სცენარი ხელახლა გაუშვით, შესაბამისი შემოწმებები CI‑ში დაამატეთ და საჭიროებისამებრ საფრთხეების მოდელი განაახლეთ. კრიტიკული სისტემებისთვის ავთენტიფიკაცია, ავტორიზაცია და მონაცემთა ნაკადი ავტომატური ტესტებითაც განიხილეთ და დამოუკიდებელი შეფასებითაც.