Уязвимость CORS: как любой сайт может получить доступ к вашему аккаунту | Тестирование веб-прилож...

Вы открываете случайный сайт — игру, страницу с купонами, что угодно. В фоновом режиме его JavaScript незаметно запрашивает у API вашего банка, используя ваши авторизованные cookie: «Предоставьте мне данные этой учетной записи». Обычно браузер пропускает этот запрос, но отказывается разрешить странице злоумышленника ПРОЧИТАТЬ ответ — это политика одного источника (Same-Origin Policy). Но сервер отвечает: «Независимо от источника, я ему доверяю, и вот учетные данные». Таким образом, браузер передает ваши личные данные учетной записи напрямую странице злоумышленника. Один неправильно настроенный заголовок — и любой веб-сайт может прочитать вашу учетную запись. Это ошибка конфигурации CORS, и в 38-м эпизоде ​​мы разберем это от начала до конца в авторизованной лаборатории. Вы узнаете о политике Same-Origin Policy (отправлять, но не читать), что такое CORS на самом деле и о двух заголовках, которые определяют всё — Access-Control-Allow-Origin и Access-Control-Allow-Credentials — почему блокируется star-plus-credentials, а также о классических ошибках конфигурации: отражение заголовка Origin, доверие к буквальному null и слабая проверка источника (подстрока / не привязанное регулярное выражение, например trusted.com.attacker.com). Затем полный эксплойт — получение данных с credentials:'include', прикрепленные cookie, сервер указывает источник атаки, скрипт считывает тело запроса — миф о предварительной проверке, цепочка CORS с захватом учетной записи, уязвимость внутренних/облачных API, практическое занятие по извлечению ключа API жертвы, последствия, набор инструментов, как искать уязвимость и работающие средства защиты. Главное правило безопасности: при тестировании создавайте прототип на основе данных ВАШЕГО СОБСТВЕННОГО аккаунта, полученных из другого источника — никогда не используйте данные посторонних. Найдите уязвимость, докажите её, сообщите о ней. Все демонстрации проводятся на специально уязвимых тестовых системах, которые принадлежат мне или на тестирование которых у меня есть разрешение. Это для этичных хакеров, охотников за уязвимостями и специалистов по защите. Найдите, поймите, сообщите — никогда не тестируйте системы, на тестирование которых у вас нет разрешения. ⏱️ РАЗДЕЛЫ 0:00 Любой сайт читает вашу учетную запись 0:34 Линия доверия внутри браузера 0:57 Политика одного источника: отправлять, не читать 1:19 Что такое CORS на самом деле 1:47 Два заголовка: ACAO и ACAC 2:16 Отражение источника 2:45 Доверие к null 3:12 Слабая проверка источника 3:41 Ловушки с подстановочными знаками и поддоменами 4:04 Эксплойт, от начала до конца 4:35 Предварительная проверка — не стена 5:02 Цепочка CORS → захват 5:28 Внутренние API: браузер как прокси 5:53 Лаборатория: извлечение ключа API 6:22 Влияние — на сессию жертвы 6:52 Инструментарий 7:20 Как его найти (проверка собственной учетной записи) 7:49 Защита 8:18 Почему это важно 8:48 Краткий обзор — Цикл CORS 9:18 Следующий эпизод и заключение 🔗 СМОТРЕТЬ ВЕСЬ СЕРИАЛ Веб-тестирование на проникновение: от нуля до героя — 100 эпизодов, от начинающего до продвинутого. ▶ Предыдущий: Эпизод 37 — Отравление веб-кэша ▶ Следующий: Эпизод 39 — Безопасность OAuth 2.0 🛡️ ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ Этот контент предназначен исключительно для образовательных целей и авторизованного тестирования безопасности. Все демонстрации проводятся на системах, которыми я владею или на тестирование которых у меня есть явное письменное разрешение. Несанкционированный доступ к компьютерным системам является незаконным. Учитесь защищаться — тестируйте ответственно. 👍 Если это помогло, подпишитесь, чтобы получать остальную часть дорожной карты. 💬 Какой самый нестрогий механизм контроля доступа (Access-Control-Allow-Origin) вы когда-либо видели в реальных условиях? Расскажите мне об этом ниже. #CORS #CORSMisconfiguration #SameOriginPolicy #AccessControlAllowOrigin #BugBounty #EthicalHacking #PenetrationTesting #BurpSuite #CyberSecurity #WebSecurity