ეს სტატია გაუმკლავდება ცნობილი oauth vulnerabilities. მკითხველი ასევე შეისწავლის, თუ როგორ უნდა განახორციელოს უსაფრთხო და უსაფრთხო ავტორიზაცია ვებ აპლიკაციაში.
OAuth არის საიმედო ოქმი, მაგრამ მისი უსაფრთხოების ხარისხი დიდწილად დამოკიდებულია ვებ დეველოპერების ცნობიერების ამაღლებაზე ავტორიზაციის განხორციელებისას. ეს ეს თემა ძალიან მნიშვნელოვანია ინფორმაციული უსაფრთხოების პროფესიონალებისთვის. მათ უნდა უზრუნველყონ თავიანთი მომხმარებლების ანგარიშების დაცვის მაღალი დონე. დროა გაეცნოს ეფექტურ პრაქტიკოსებს, რომლებიც ხელს შეუწყობენ OAUTH- ს ცუდი გაყიდვის საფრთხეს.
შესავალიOAuth 2.0 პროტოკოლი ამჟამად ფართოდ გამოიყენება სხვადასხვა პროგრამებში. მისი გამოყენება, მოსახერხებელი მომხმარებლის ინტერფეისი ხელმისაწვდომი გახდება, ადვილი ავთენტიფიკაცია და ავტორიზაცია შედარებით ტრადიციული მეთოდებით მომხმარებლის სახელი და პაროლი. სათანადო და გააზრებული განხორციელებით, OAUTH პროტოკოლი უფრო უსაფრთხოა, ვიდრე ტრადიციული ავტორიზაცია, რადგან მომხმარებელს არ უნდა ჰქონდეს მათი საბუღალტრო მონაცემების გაზიარება მესამე მხარის განცხადებით, კონკრეტული რესურსის წვდომისთვის. მომხმარებლებს ხშირად ურჩევნიათ შეხვიდეთ თავიანთი Google ანგარიშების, Facebook- ის ან LinkedIn- ის გამოყენებით, ახალი ანგარიშის შექმნის ნაცვლად, ყოველ ჯერზე საჭიროა დარეგისტრირდეთ ზოგიერთ საიტზე. ამდენად, OAuth პროტოკოლი მნიშვნელოვნად ამარტივებს ჩვენს ცხოვრებას.
ზოგადად, პოპულარულია OAUTH სერვის პროვაიდერები ძალიან საიმედო. შესვლა Google ან Facebook ანგარიშზე შთამბეჭდავი უსაფრთხოების გარკვეული გრძნობა, და ეს არის სწორი. ოქმი ყურადღებით ტესტირებულია ექსპერტების მიერ. ყველა არსებული მოწყვლადობა ყოველთვის სწრაფად გამოსწორდება დეველოპერის გუნდმა. თუმცა, აღსანიშნავია, რომ სრული უსაფრთხოების განცდა შეიძლება იყოს ყალბი.
OAuth Service Providers დატოვა განაცხადის დეველოპერები ბევრი მიზეზების გამოწვევის უსაფრთხოების მათი პროგრამების. სინამდვილეში, თავდაპირველად დაცული OAuth სერვისი, რომელიც არასწორად განხორციელდა მისი ინსტალაციის პროცესში, შეიძლება ადვილად იქცეს intruders. ასეთი პრეოკუპაცია გამოიწვევს მომხმარებელთა პირადი მონაცემების ქურდობას.
შემდეგი, თქვენ უნდა განიხილონ ყველაზე გავრცელებული ხარვეზები, რომლებიც შეექმნათ მესამე მხარის პროგრამებში, რომლებიც განახორციელებენ OAUTH პროტოკოლს მათი მომხმარებლებისთვის. უნდა აღინიშნოს, რომ პროტოკოლი თავად არის უსაფრთხო და საიმედო. მხოლოდ არასწორი განხორციელების შემდეგ, ის ხდება ჰაკერული თავდასხმებისადმი დაუცველი.
OAUTH TOCKEY THEFT REFERENY HEADER- ის გამოყენებითროდესაც განცხადება ითხოვს მომხმარებლის სახელით მომხმარებლის სახელით OAuth სერვერზე, პირი იღებს კოდს შესვლისა და სერვერზე დაბრუნების შემდეგ. თუ სამუშაოს დროს მომხმარებელი სხვა გვერდს გადააჭარბებს, კოდექსი იხილავს HTTP მოთხოვნის "მითითებულ" სათაურში. ამდენად, კოდი გარეგნულად დაეცემა გარე ვებ-გვერდზე, რომელიც საფრთხეს უქმნის OAUTH სერვერზე რეგისტრირებულ მომხმარებელთა მონაცემებს.
შენიშვნა: Reforer Header არის HTTP შეკითხვის სათაური, იგი გადასცემს URL მასპინძელი, საიდანაც მოთხოვნა იგზავნება.
ამ დაუცველობის შედეგების შევსება, დეველოპერი უნდა დარწმუნდეს, რომ მისი ვებ აპლიკაცია არ შეიცავს HTML ინექციას. თუ ინექციები აღმოჩენილია, თავდამსხმელმა ადვილად შეუძლია დააყენოს გამოსახულების ტეგი სერვერზე და იპოვოს მომხმარებლის გადამისამართება. ამდენად, ის მიიღებს შესაძლებლობას, მოიპოვოს კოდი HTTP მოთხოვნის "რეილერის" ჰედერისგან.
OAUTH TOCKEY THEFT გამოყენებით Redirect_uri პარამეტრიაპლიკაცია იწყებს ავტორიზაციის პროცესს OAUTH სერვერზე მოთხოვნის გაგზავნით:
https://www.example.com/signin/authorize?[In.[In.[In. გაოცებული.
შეკითხვა ყოველთვის შეიცავს "Redirect_uri" პარამეტრს OAUTH SERVER- ის მიერ გამოყენებული, რათა მომხმარებელს მისცეს თანხმობის შემდეგ. თუ ამ პარამეტრის ღირებულება არ არის კონტროლირებადი ან არ შემოწმებული, თავდამსხმელს ადვილად შეუძლია შეცვალოს იგი და გადამისამართება მისი ვებსაიტის მოთხოვნით, სადაც იგი იყენებს სპეციალურ პროგრამას, რათა შეიქმნას ნიშნად და შეზღუდული რესურსით წვდომა.
https://www.example.com/signin/authorize?[In.
ზოგჯერ მსგავსი მისამართები დაბლოკილია. თავდამსხმელს შეუძლია გადამისამართება მიღებული მონაცემების ღია URL- ზე, ასე რომ:
https://www.example.com/oauth20_authorize.srf?[3 :..
Ან ეს:
https://www.example.com/oauth2/Authorize? [...]% ireck_uri = https 3a% 2f% 2fapps.facebook.com% 2fattacker 2f.
OAUTH- ის განხორციელებისას, თქვენ ვერ შეძლებთ თეთრ სიაში მთელ დომებს. მხოლოდ რამდენიმე URL უნდა დაემატოს "redirect_uri" არ გადამისამართება თხოვნით გადამისამართება.
ჯვრის ხაზის გაყალბების გაყალბებაIntersight- ის მოთხოვნის გაყალბება შეიძლება მოხდეს, როდესაც თავდამსხმელი წარმატებას მიაღწევს დაზარალებულს, რომ დააკლიკეთ მის ბმულზე და, ამდენად, მოითხოვოს თხოვნა, რომ ის არ აპირებს გენერირებას. Cross-Line მოთხოვნის გაყალბება, როგორც წესი, შეარბილა CSRF ნიშნად, რომელიც დაკავშირებულია მომხმარებლის სხდომაზე. იგი ხელს უწყობს განაცხადის შემოწმებას იმ პირს, რომელმაც მოითხოვა თხოვნა. OAUTH პროტოკოლის "სახელმწიფო" პარამეტრი CSRF ნიშნად ემსახურება.
აღსანიშნავია, თუ როგორ ხორციელდება CSRF თავდასხმა OAUTH- ზე და როგორც "სახელმწიფო" პარამეტრი შეიძლება გამოყენებულ იქნას მოწყვლადობის შედეგების შესამცირებლად.
ჰაკერი ხსნის ვებ-პროგრამას და იწყებს ავტორიზაციის პროცესს მომსახურების მიმწოდებლისთვის OAUTH- ის გამოყენებით. აპლიკაცია მოითხოვს მომსახურების მიმწოდებელს, რომელიც უნდა უზრუნველყოფილი იყოს. Hacker იქნება გადამისამართება მომსახურების მიმწოდებლის ნახვა, სადაც თქვენ, როგორც წესი, უნდა შეიყვანოთ თქვენი სახელი და პაროლი ავტორიზაციის ხელმისაწვდომობის. ამის ნაცვლად, ჰაკერი იჭერს და ხელს უშლის ამ მოთხოვნას და გადაარჩენს თავის URL- ს. ჰაკერი რატომღაც იწვევს დაზარალებულს ამ URL- ს გახსნას. თუ დაზარალებულმა სერვისის პროვაიდერის სისტემა თავისი ანგარიშის გამოყენებით შეასრულა, მაშინ მისი რწმუნებათა სიგელები გამოყენებული იქნება ავტორიზაციის კოდით. ავტორიზაციის კოდი გაცვლიან ხელმისაწვდომობას წვდომისათვის. ახლა ჰაკერების ანგარიში განაცხადში უფლებამოსილია. მას შეუძლია მსხვერპლის ანგარიშზე წვდომა.
ასე რომ, როგორ შემიძლია თავიდან ავიცილოთ ეს სიტუაცია "სახელმწიფო" პარამეტრის გამოყენებით?
განაცხადმა უნდა შეიქმნას ღირებულება, რომელიც გარკვეულწილად არის დაფუძნებული წყარო ანგარიშზე (მაგალითად, გამოიყენეთ მომხმარებლის სესია Hash გასაღები). ეს არ არის ისეთი მნიშვნელოვანი ის, რაც მთავარია, მთავარია, რომ ღირებულება უნიკალურია და გენერირებული კერძო ინფორმაციის გამოყენებით ორიგინალური მომხმარებლის შესახებ. მას "სახელმწიფო" პარამეტრი ენიჭება.
ეს მნიშვნელობა გადაეცემა მომსახურების მიმწოდებელს, როდესაც გადამისამართება გადამისამართება. ახლა ჰაკერი იწვევს დაზარალებულს URL- ის გახსნას, რომელიც მან შეინარჩუნა.
ავტორიზაციის კოდექსი გაცემულია და კლიენტს სესიასთან "სახელმწიფო" პარამეტრთან ერთად გაგზავნა.
კლიენტი ქმნის პარამეტრი ღირებულებას სხდომის შესახებ ინფორმაციის საფუძველზე და ადარებს მას "სახელმწიფო" ღირებულებას, რომელიც გაგზავნილია ავტორიზაციის მოთხოვნით მომსახურების მიმწოდებლისთვის. ეს მნიშვნელობა არ შეესაბამება "სახელმწიფო" პარამეტრს შეკითხვას, რადგან იგი მხოლოდ მიმდინარე სესიის შესახებ ინფორმაციის საფუძველზეა გენერირებული. შედეგად, მიღებული ღირებულება არ მიიღება სისტემაში.
სხვა მოწყვლადობები გამოვლინდა OAUTH- ის განხორციელებისას "Redirect_uri" პარამეტრის გამოყენებით XSS (Cross-Site Scripting), OAUTH PRIVITY გასაღები პარამეტრი (გასაღები შეიძლება მიღებულ იქნას მობილური აპლიკაციის დეკომპილიზაციისას) და ავტორიზაციის კოდექსის წესი დარღვევა (როდესაც ავტორიზაციის კოდი შეიძლება გამოყენებულ იქნას ერთზე მეტს, ვიდრე მრავალჯერადი წვდომის სიმბოლო). ეს ხარვეზები ნაკლებად საერთოა, ვიდრე ზემოთ აღწერილი, მაგრამ ეს არ არის ნაკლებად საშიში. დეველოპერმა უნდა იცოდეს ყველა საჭირო პრაქტიკა, რათა უზრუნველყოს მისი ვებ აპლიკაციის საიმედო ოპერაცია.
თარგმნილი სტატიის ავტორი: სიმონ სალიბა.
Მნიშვნელოვანი! ინფორმაცია მხოლოდ აკადემიური მიზნებისათვის. გთხოვთ, შეესაბამებოდეს კანონმდებლობას და არ გამოიყენოთ ეს ინფორმაცია უკანონო მიზნებისათვის.
უფრო საინტერესო მასალა Cisoclub.ru- ზე. გამოწერა აშშ: Facebook | Vk | Twitter | Instagram | ტელეგრაფი | Zen | მესენჯერი | ICQ ახალი | YouTube | პულსი.