Чому розробники й досі не розуміють CORS: урок уразливості Zoom на localhost

Нарис консультанта з повного циклу розробки Кріса Фостера, опублікований ще 2019 року й досі популярний серед інженерів, доводить: надто багато веброзробників не розуміють, як працює механізм Cross-Origin Resource Sharing (CORS), і це має реальні безпекові наслідки. Головний приклад — уразливість на localhost у десктопному клієнті Zoom, про яку дослідник безпеки Джонатан Лейтшух розповів у липні 2019 року.

Пастка localhost у Zoom

Клієнт Zoom встановлював на комп'ютері вебсервер, що слухав адресу http://localhost:19421. Коли користувач відкривав посилання Zoom, сайт zoom.us надсилав запит до цього локального сервера з командою запустити нативний застосунок. Замість звичайного AJAX-запиту сторінка завантажувала зображення з локального сервера, а розміри цього зображення кодували код стану чи помилки. У своєму описі Лейтшух припустив, що це зроблено для обходу CORS, адже, за його словами, браузери нібито повністю ігнорують політику CORS для серверів на localhost.

Фостер зазначає, що це твердження хибне: Chrome поважає заголовки CORS і для локальних вебсерверів, а міжсайтові запити до localhost підтримують усі браузери — розробники роблять це постійно, коли фронтенд на Create React App працює на одному порту, а API на іншому. Трюк із зображенням, на його думку, означає, що Zoom або не розумів CORS, або свідомо обійшов його. Ціна обходу виявилася високою: операції в нативному клієнті міг запускати й читати відповідь не лише zoom.us, а й будь-який інший сайт в інтернеті.

Як має виглядати безпечна реалізація

Локальний вебсервер повинен надавати REST API і надсилати заголовок Access-Control-Allow-Origin зі значенням https://zoom.us, щоб із ним міг спілкуватися лише JavaScript із домену zoom.us. Крім того, zoom.us має надсилати заголовок Content Security Policy, який забороняє відображення в iframe, аби сторінки не могли непомітно відкривати зустрічі у фоні. Залишається ще одна проблема: будь-яка сторінка може перенаправити браузер на посилання zoom.us із несподіваною зустріччю. Фостер відносить це радше до рішень про користувацький досвід, ніж до програмної вразливості, і не погоджується з ним: програмне забезпечення мусить бути передбачуваним, а клік на посилання не повинен робити вашу камеру й мікрофон доступними незнайомцям. Як кращий приклад він наводить спливне вікно в застосунку Google Meet.

Чому плутанина не зникає

Проблема не обмежується Zoom: інші компанії потрапляли на таку саму уразливість, а Stack Overflow переповнений питаннями про CORS, поруч із якими часто радять небезпечні налаштування за замовчуванням — наприклад, приклад для Express на enable-cors.org, який при буквальному копіюванні робить застосунок уразливим. Технічні виправдання теж не тримаються: Firefox справді може блокувати частину запитів із захищених джерел до незахищених, але localhost він підтримує, а нативні застосунки можуть згенерувати власний самопідписаний сертифікат або постачатися з розширенням для браузера. Обхід політики одного джерела може змусити код працювати, підсумовує автор, але згодом створює проблеми — і досі незрозуміло, чи CORS надто складний API, чи просто бракує освіти для розробників.