გავლენა
თავდამსხმელს შეუძლია მოიპაროს მგრძნობიარე, ავთენტიფიცირებული მონაცემები დაუცველი აპლიკაციის მომხმარებლებისგან [S2]. თუ მომხმარებელი ეწვევა მავნე ვებსაიტს დაუცველ აპში შესვლისას, მავნე საიტს შეუძლია აპლიკაციის API-ს მიმართოს ჯვარედინი წარმოშობის მოთხოვნა და წაიკითხოს პასუხები [S1][S2]. ამან შეიძლება გამოიწვიოს პირადი ინფორმაციის მოპარვა, მათ შორის მომხმარებლის პროფილები, CSRF ნიშნები ან პირადი შეტყობინებები [S2].
ძირეული მიზეზი
CORS არის HTTP სათაურზე დაფუძნებული მექანიზმი, რომელიც საშუალებას აძლევს სერვერებს განსაზღვრონ, თუ რომელი საწყისის (დომენი, სქემა ან პორტი) არის ნებადართული რესურსების ჩატვირთვის [S1]. დაუცველობა, როგორც წესი, ჩნდება, როდესაც სერვერის CORS პოლიტიკა ძალიან მოქნილი ან ცუდად განხორციელებული [S2]ა:
- ასახული წარმოშობის სათაური: ზოგიერთი სერვერი კითხულობს
Originსათაურს კლიენტის მოთხოვნიდან და ეხმიანება მასAccess-Control-Allow-Origin(ACAO) პასუხის სათაურში [S2]. ეს ეფექტურად საშუალებას აძლევს ნებისმიერ ვებსაიტს წვდომა ჰქონდეს რესურსზე [S2]. - არასწორად კონფიგურირებული ველური ბარათები: მიუხედავად იმისა, რომ
*სიმბოლო საშუალებას აძლევს ნებისმიერ წარმოშობას წვდომა რესურსზე, ის არ შეიძლება გამოყენებულ იქნას მოთხოვნებისთვის, რომლებიც საჭიროებენ სერთიფიკატებს (როგორიცაა ქუქიები ან ავტორიზაციის სათაურები) [S3]. დეველოპერები ხშირად ცდილობენ ამის გვერდის ავლით ACAO სათაურის დინამიურად გენერირებით [S2] მოთხოვნის საფუძველზე. - Whitelisting 'null': ზოგიერთი აპლიკაცია თეთრ სიაში შედის
nullწარმოშობის, რომელიც შეიძლება გამოწვეული იყოს გადამისამართებული მოთხოვნებით ან ადგილობრივი ფაილებით, რაც საშუალებას აძლევს მავნე საიტებს გადაიტანონ როგორცnullწარმოშობის წვდომა. [S2][S3]. - გაანალიზების შეცდომები:
Originსათაურის ვალიდაციისას დაშვებულმა შეცდომებმა regex-ში ან სტრიქონების შესატყვისობაში შეიძლება დაუშვას თავდამსხმელებს გამოიყენონ ისეთი დომენები, როგორიცააtrusted-domain.com.attacker.com[S2].
მნიშვნელოვანია აღინიშნოს, რომ CORS არ არის დაცვა ადგილებზე მოთხოვნის გაყალბებისგან (CSRF) [S2].
ბეტონის შესწორებები
- გამოიყენეთ სტატიკური თეთრი სია: მოერიდეთ
Access-Control-Allow-Originსათაურის დინამიკურ გენერირებას მოთხოვნისOriginსათაურიდან [S2]. ამის ნაცვლად, შეადარეთ მოთხოვნის წარმოშობა სანდო დომენების მყარი კოდირებულ სიას [S3]. - მოერიდეთ "null" წარმოშობას: არასოდეს შეიტანოთ
nullთქვენს ნებადართული წარმოშობის თეთრ სიაში [S2]. - შეზღუდეთ სერთიფიკატები: დააყენეთ მხოლოდ
Access-Control-Allow-Credentials: true, თუ ეს აბსოლუტურად აუცილებელია კონკრეტული ჯვარედინი წარმოშობის ურთიერთქმედებისთვის [S3]. - გამოიყენეთ სათანადო ვალიდაცია: თუ თქვენ გჭირდებათ მრავალი საწყისის მხარდაჭერა, დარწმუნდით, რომ
Originსათაურის ვალიდაციის ლოგიკა ძლიერია და არ შეიძლება მისი გვერდის ავლით ქვედომეინებით ან მსგავსი მსგავსი დომენებით [S2].
როგორ ამოწმებს მას FixVibe
FixVibe ახლა მოიცავს ამას, როგორც დახურულ აქტიურ შემოწმებას. დომენის შემოწმების შემდეგ, active.cors აგზავნის იგივე წარმოშობის API მოთხოვნებს სინთეზური თავდამსხმელის წარმოშობით და განიხილავს CORS პასუხის სათაურებს. მასში ასახულია თვითნებური წარმომავლობა, ველური ბარათით დადასტურებული CORS და ფართოდ ღია CORS არასაჯარო API ბოლო წერტილებზე, ხოლო საჯარო აქტივების ხმაურის თავიდან აცილება.