OATH API-ის ყველაზე დაუცველობა
OATH API ყველაზე დაუცველები: შესავალი
რაც შეეხება ექსპლოიტებს, API არის საუკეთესო ადგილი დასაწყებად. API წვდომა ჩვეულებრივ შედგება სამი ნაწილისგან. კლიენტებს ეძლევათ ტოკენები ავტორიზაციის სერვერის მიერ, რომელიც მუშაობს API-ებთან ერთად. API იღებს წვდომის ტოკენებს კლიენტისგან და მათზე დაყრდნობით იყენებს დომენის სპეციფიკურ ავტორიზაციის წესებს.
თანამედროვე პროგრამული აპლიკაციები დაუცველია სხვადასხვა საფრთხის მიმართ. შეინარჩუნეთ სისწრაფე უახლესი ექსპლოიტებისა და უსაფრთხოების ხარვეზების შესახებ; ამ მოწყვლადობის კრიტერიუმების ქონა აუცილებელია აპლიკაციის უსაფრთხოების უზრუნველსაყოფად თავდასხმის დაწყებამდე. მესამე მხარის აპლიკაციები სულ უფრო მეტად ეყრდნობა OAuth პროტოკოლს. მომხმარებლებს ექნებათ უკეთესი საერთო მომხმარებლის გამოცდილება, ასევე უფრო სწრაფი შესვლა და ავტორიზაცია, ამ ტექნოლოგიის წყალობით. ეს შეიძლება იყოს უფრო უსაფრთხო, ვიდრე ჩვეულებრივი ავტორიზაცია, რადგან მომხმარებლებს არ სჭირდებათ გაამჟღავნონ თავიანთი რწმუნებათა სიგელები მესამე მხარის აპლიკაციაში მოცემულ რესურსზე წვდომისთვის. მიუხედავად იმისა, რომ პროტოკოლი თავისთავად უსაფრთხო და უსაფრთხოა, მისი განხორციელების გზამ შეიძლება დაგტოვოთ თავდასხმისთვის.
API-ების დიზაინისა და ჰოსტინგის დროს, ეს სტატია ყურადღებას ამახვილებს OAuth-ის ტიპურ დაუცველობაზე, ისევე როგორც უსაფრთხოების სხვადასხვა შერბილებაზე.
გატეხილი ობიექტის დონის ავტორიზაცია
ავტორიზაციის დარღვევის შემთხვევაში თავდასხმის უზარმაზარი ზედაპირია, რადგან API უზრუნველყოფს წვდომას ობიექტებზე. ვინაიდან API-ზე ხელმისაწვდომი ელემენტები უნდა იყოს დამოწმებული, ეს აუცილებელია. განახორციელეთ ობიექტის დონის ავტორიზაციის შემოწმებები API კარიბჭის გამოყენებით. მხოლოდ მათ, ვისაც აქვს შესაბამისი ნებართვის სერთიფიკატი, უნდა ჰქონდეს წვდომა.
გატეხილი მომხმარებლის ავთენტიფიკაცია
არაავტორიზებული ჟეტონები თავდამსხმელებისთვის API-ებზე წვდომის კიდევ ერთი ხშირი გზაა. ავტორიზაციის სისტემები შეიძლება გატეხილი იყოს, ან API გასაღები შეიძლება შეცდომით გამოაშკარავდეს. ავთენტიფიკაციის ნიშნები შეიძლება იყოს გამოიყენება ჰაკერების მიერ წვდომის მისაღებად. დაადასტურეთ ადამიანები მხოლოდ იმ შემთხვევაში, თუ მათი ნდობაა შესაძლებელი და გამოიყენეთ ძლიერი პაროლები. OAuth-ით შეგიძლიათ გასცდეთ უბრალო API კლავიშებს და მიიღოთ წვდომა თქვენს მონაცემებზე. თქვენ ყოველთვის უნდა იფიქროთ იმაზე, თუ როგორ შეხვალთ და გამოხვალთ ადგილიდან. OAuth MTLS Sender Constrained Tokens შეიძლება გამოყენებულ იქნას Mutual TLS-თან ერთად, რათა გარანტირებული იყოს, რომ კლიენტები არ მოიქცევიან არასწორად და არ გადასცემენ ტოკენებს არასწორ მხარეს სხვა აპარატებზე წვდომისას.
API პრომოცია:
მონაცემთა გადაჭარბებული ექსპოზიცია
არ არსებობს შეზღუდვები ბოლო წერტილების რაოდენობაზე, რომლებიც შეიძლება გამოქვეყნდეს. უმეტეს შემთხვევაში, ყველა ფუნქცია არ არის ხელმისაწვდომი ყველა მომხმარებლისთვის. მეტი მონაცემების გამოვლენით, ვიდრე აბსოლუტურად აუცილებელია, თქვენ თავს და სხვებს საფრთხეში აყენებთ. მოერიდეთ მგრძნობიარეების გამჟღავნებას ინფორმაცია მანამ, სანამ ეს აბსოლუტურად აუცილებელი იქნება. დეველოპერებს შეუძლიათ განსაზღვრონ, თუ ვის რაზე აქვს წვდომა OAuth Scopes და Claims-ის გამოყენებით. პრეტენზიებში შეიძლება განისაზღვროს, თუ რომელ მონაკვეთებზე აქვს წვდომა მომხმარებელს. წვდომის კონტროლი შეიძლება გამარტივდეს და მართვადი იყოს ყველა API-ში სტანდარტული სტრუქტურის გამოყენებით.
რესურსების ნაკლებობა და ფასების შეზღუდვა
შავი ქუდები ხშირად იყენებენ სერვისზე უარის თქმის (DoS) თავდასხმებს, როგორც უხეში ძალის ხერხს სერვერის გადატვირთვისა და მისი მუშაობის დროის ნულამდე შემცირების მიზნით. რესურსების შეზღუდვის გარეშე, რომლებიც შეიძლება გამოიძახოს, API დაუცველია დამღუპველი თავდასხმის მიმართ. API კარიბჭის ან მართვის ხელსაწყოს გამოყენებით, შეგიძლიათ დააყენოთ განაკვეთის შეზღუდვები API-ებისთვის. გაფილტვრა და პაგინაცია უნდა იყოს გათვალისწინებული, ასევე პასუხები შეზღუდული იყოს.
უსაფრთხოების სისტემის არასწორი კონფიგურაცია
უსაფრთხოების კონფიგურაციის სხვადასხვა სახელმძღვანელო პრინციპები საკმაოდ ყოვლისმომცველია, უსაფრთხოების არასწორი კონფიგურაციის მნიშვნელოვანი ალბათობის გამო. არაერთმა წვრილმანმა შეიძლება საფრთხე შეუქმნას თქვენი პლატფორმის უსაფრთხოებას. შესაძლებელია, რომ ფარული მიზნების მქონე შავმა ქუდებმა შეიძლება აღმოაჩინონ მგრძნობიარე ინფორმაცია, რომელიც გაგზავნილია არასწორი შეკითხვებზე, მაგალითად.
მასობრივი დავალება
მხოლოდ იმიტომ, რომ საბოლოო წერტილი არ არის საჯაროდ განსაზღვრული, არ ნიშნავს რომ მასზე წვდომა არ შეიძლება დეველოპერებისთვის. ჰაკერების მიერ საიდუმლო API შეიძლება ადვილად ჩაითვალოს და შეცვალოს. შეხედეთ ამ ძირითად მაგალითს, რომელიც იყენებს ღია Bearer Token-ს „პირად“ API-ში. მეორეს მხრივ, საჯარო დოკუმენტაცია შეიძლება არსებობდეს ისეთ რამეზე, რაც ექსკლუზიურად არის განკუთვნილი პირადი სარგებლობისთვის. გამოვლენილი ინფორმაცია შეიძლება გამოყენებულ იქნას შავი ქუდების მიერ არა მხოლოდ წასაკითხად, არამედ ობიექტის მახასიათებლების მანიპულირებისთვის. ჩათვალეთ თავი ჰაკერად, როდესაც ეძებთ პოტენციურ სუსტ წერტილებს თქვენს თავდაცვაში. დაბრუნებულზე წვდომა მიეცით მხოლოდ მათ, ვისაც აქვს შესაბამისი უფლებები. დაუცველობის შესამცირებლად, შეზღუდეთ API პასუხის პაკეტი. რესპონდენტებმა არ უნდა დაამატონ ბმულები, რომლებიც აბსოლუტურად არ არის საჭირო.
დაწინაურებული API:
აქტივების არასწორი მართვა
გარდა დეველოპერის პროდუქტიულობის გაზრდისა, მიმდინარე ვერსიები და დოკუმენტაცია აუცილებელია თქვენი საკუთარი უსაფრთხოებისთვის. წინასწარ მოემზადეთ ახალი ვერსიების დანერგვისა და ძველი API-ების გაუქმებისთვის. გამოიყენეთ უფრო ახალი API-ები იმის ნაცვლად, რომ ძველებს დარჩეთ გამოყენებაში. API სპეციფიკაცია შეიძლება გამოყენებულ იქნას, როგორც ჭეშმარიტების პირველადი წყარო დოკუმენტაციისთვის.
ინჟექტორი
API დაუცველია ინექციისთვის, მაგრამ ასევე არის მესამე მხარის დეველოპერის აპლიკაციები. მავნე კოდი შეიძლება გამოყენებულ იქნას მონაცემების წასაშლელად ან კონფიდენციალური ინფორმაციის მოსაპარად, როგორიცაა პაროლები და საკრედიტო ბარათის ნომრები. ყველაზე მნიშვნელოვანი გაკვეთილი, რომელიც ამისგან უნდა წაიღოთ, არის არ იყოთ დამოკიდებული ნაგულისხმევ პარამეტრებზე. თქვენს მენეჯმენტს ან კარიბჭის მიმწოდებელს უნდა შეეძლოს თქვენი უნიკალური განაცხადის საჭიროებების დაკმაყოფილება. შეცდომის შეტყობინებები არ უნდა შეიცავდეს სენსიტიურ ინფორმაციას. პირადობის მონაცემების სისტემის გარეთ გაჟონვის თავიდან ასაცილებლად, წყვილთა ფსევდონიმები უნდა იყოს გამოყენებული ტოკენებში. ეს უზრუნველყოფს, რომ არცერთ კლიენტს არ შეუძლია ერთად იმუშაოს მომხმარებლის იდენტიფიცირებისთვის.
არასაკმარისი აღრიცხვა და მონიტორინგი
როდესაც შეტევა ხდება, გუნდებს სჭირდებათ კარგად გააზრებული რეაქციის სტრატეგია. დეველოპერები გააგრძელებენ მოწყვლადობის გამოყენებას დაჭერის გარეშე, თუ არ არსებობს სანდო ხე-ტყის და მონიტორინგის სისტემა, რაც გაზრდის ზარალს და ზიანს აყენებს საზოგადოების აღქმას კომპანიის შესახებ. მიიღეთ მკაცრი API მონიტორინგისა და წარმოების საბოლოო წერტილის ტესტირების სტრატეგია. თეთრი ქუდის ტესტერები, რომლებიც ადრევე აღმოაჩენენ დაუცველობას, უნდა დაჯილდოვდნენ ბონუტი სქემით. ჟურნალის ბილიკი შეიძლება გაუმჯობესდეს მომხმარებლის იდენტურობის API ტრანზაქციებში ჩართვით. დარწმუნდით, რომ თქვენი API არქიტექტურის ყველა ფენა შემოწმებულია Access Token მონაცემების გამოყენებით.
დასკვნა
პლატფორმის არქიტექტორებს შეუძლიათ თავიანთი სისტემები აღჭურონ იმისთვის, რომ თავდამსხმელებზე ერთი ნაბიჯით წინ დაიცვან დაუცველობის დადგენილი კრიტერიუმების დაცვით. იმის გამო, რომ API-ებმა შეიძლება უზრუნველყონ პერსონალური იდენტიფიცირებადი ინფორმაციის (PII) ხელმისაწვდომობა, ასეთი სერვისების უსაფრთხოების დაცვა გადამწყვეტია როგორც კომპანიის სტაბილურობისთვის, ასევე ისეთი კანონმდებლობისთვის, როგორიცაა GDPR. არასოდეს გაგზავნოთ OAuth ჟეტონები პირდაპირ API-ზე API Gateway-ისა და Phantom Token Approach-ის გამოყენების გარეშე.
დაწინაურებული API:
