რატომ ვერ იგებენ დეველოპერები CORS-ს — გაკვეთილი Zoom-ის localhost-ის ხარვეზიდან

პროგრამული უზრუნველყოფის კონსულტანტ კრის ფოსტერის 2019 წელს დაწერილი და დეველოპერებში დღემდე მოძრავი ესე ამტკიცებს, რომ ძალიან ბევრ ვებ-დეველოპერს არ ესმის, როგორ მუშაობს Cross-Origin Resource Sharing (CORS), და რომ ამ გაუგებრობას რეალური უსაფრთხოების შედეგები აქვს. მთავარი მაგალითი Zoom-ის დესკტოპ-კლიენტის localhost-ის ხარვეზია, რომელიც უსაფრთხოების მკვლევარმა ჯონათან ლაიჩუხმა 2019 წლის ივლისში გაასაჯაროა.

Zoom-ის localhost-ის ხაფანგი

Zoom-ის კლიენტი კომპიუტერზე აყენებდა ვებ-სერვერს, რომელიც http://localhost:19421 მისამართზე ისმენდა. როცა მომხმარებელი Zoom-ის ბმულს ხსნიდა, საიტი zoom.us ამ ლოკალურ სერვერს მოთხოვნას უგზავნიდა და ნატიური აპლიკაციის გახსნას ავალებდა. ჩვეულებრივი AJAX-მოთხოვნის ნაცვლად გვერდი ლოკალური ვებ-სერვერიდან სურათს იტვირთავდა, სურათის ზომები კი სერვერის სტატუსის ან შეცდომის კოდს კოდირებდა. თავის პუბლიკაციაში ლაიჩუხმა ვარაუდი გამოთქვა, რომ ეს CORS-ის გვერდის ავლისთვის კეთდებოდა, რადგან, მისი სიტყვებით, ბრაუზერები სრულად უგულებელყოფენ CORS-ის პოლიტიკას localhost-ზე მომუშავე სერვერებისთვის.

ფოსტერი აღნიშნავს, რომ ეს მტკიცება მცდარია: Chrome CORS-ის ჰედერებს ლოკალური ვებ-სერვერებისთვისაც პატივს სცემს, ხოლო localhost-ის მიმართულ ჯვარედინ მოთხოვნებს ყველა ბრაუზერი უჭერს მხარს. მისი აზრით, სურათის ხრიკი ნიშნავს, რომ Zoom-ს ან CORS არ ესმოდა, ან განზრახ ავლიდა გვერდს; ფასი მაღალი აღმოჩნდა: ნატიურ კლიენტში ოპერაციების გაშვება და პასუხის წაკითხვა არა მხოლოდ zoom.us-ს, არამედ ინტერნეტის ყველა სხვა საიტსაც შეეძლო.

როგორ უნდა გამოიყურებოდეს უსაფრთხო რეალიზაცია

ლოკალურ ვებ-სერვერს REST API უნდა შეეთავაზებინა და Access-Control-Allow-Origin ჰედერი https://zoom.us მნიშვნელობით გაეგზავნა, რომ მასთან მხოლოდ zoom.us დომენზე მომუშავე JavaScript-ს შეეძლოს საუბარი. გარდა ამისა, zoom.us-ს Content Security Policy ჰედერი უნდა გაეგზავნა, რომელიც iframe-ში გამოსახვას კრძალავს, რათა გვერდებმა ფონზე შეხვედრები ჩუმად ვერ გახსნან. მაინც რჩება ის ფაქტი, რომ ნებისმიერ გვერდს შეუძლია ბრაუზერი zoom.us-ის ბმულზე გადაამისამართოს — მოულოდნელი შეხვედრისკენ. ფოსტერი ამას მომხმარებლის გამოცდილების გადაწყვეტილებად მიიჩნევს და არ ეთანხმება: პროგრამა წინასწარმეტყველებადი უნდა იყოს, ბმულზე დაწკაპუნებამ კი თქვენი კამერა და მიკროფონი უცხო ადამიანებისთვის ხელმისაწვდომი არ უნდა გახადოს. უკეთეს მაგალითად Google Meet-ის აპლიკაციის შიგნით გახსნილ ფანჯარას მოჰყავს.

რატომ გრძელდება დაბნეულობა

პრობლემა Zoom-ით არ შემოიფარგლება: სხვა კომპანიებიც დაიჭირეს ზუსტად იმავე ხარვეზზე, Stack Overflow კი CORS-ის შესახებ კითხვებითაა სავსე; მათ გვერდით ხშირად უსაფრთხო არასტანდარტულ პარამეტრებს ურჩევენ — მაგალითად, enable-cors.org-ზე გამოქვეყნებული Express-ის მაგალითი, რომელიც პირდაპირ კოპირების შემთხვევაში აპლიკაციას დაუცველს ხდის. ტექნიკური გამართლებებიც არ ძლებს: Firefox-მა შეიძლება დაბლოკოს ზოგიერთი მოთხოვნა უსაფრთხო წყაროდან არაუსაფრთხო წყაროსკენ, თუმცა localhost-ს მხარს უჭერს, ნატიურ აპლიკაციებს კი შეუძლიათ საკუთარი თვითხელმოწერილი სერტიფიკატი შექმნან ან ბრაუზერის გაფართოება მოიყოლონ. ერთი და იმავე წყაროს პოლიტიკის გვერდის ავლამ შეიძლება კოდი აამუშაოს, აჯამებს ავტორი, თუმცა მოგვიანებით პრობლემებს ქმნის; ჯერ კიდევ გაურკვეველია, CORS ზედმეტად რთული API-ა თუ უბრალოდ დეველოპერების განათლებაა არასაკმარისი.