Как проверять смешанное содержимое без поспешных выводов об уязвимости.
Небезопасную ссылку нужно изучать в контексте. Браузеры обрабатывают типы ресурсов и политики по-разному: не называйте каждую ссылку эксплуатируемой уязвимостью.
Адаптируйте процесс под свою задачу.
Найдите URL небезопасных ресурсов, указанные на странице HTTPS, и классифицируйте тип и расположение. Отделите ссылку в исходных данных от реально замеченного сетевого запроса или блокировки браузером. Перед советом изменить URL проверьте, что замена по HTTPS существует.
- Что вы предоставляете
- URL ресурсов страницы HTTPS.
- Что вы получите
- Небезопасные ссылки на ресурсы, видимые в доступных данных страницы.
Посмотрите входные данные и результат.
Иллюстративные входные и выходные данные · учебный пример, а не реальный запуск WebAct
Полей ввода: Пример
HTTPS source page https://example.com/ contains <script src="http://assets.example.com/app.js"></script>. No network or console observations supplied.
Готовый пример
Resource: http://assets.example.com/app.js Type: script loaded into an HTTPS page. Finding: insecure script reference requiring mixed-content review. Observed browser outcome: not supplied. Next check: inspect the console/request and verify a supported HTTPS asset URL before changing the reference.
Добавьте эти данные в промпт и скопируйте его в WebAct, чтобы попробовать задачу. Ваш результат может отличаться от примера.
Решения и устранение проблем.
Каждая ссылка http на странице HTTPS является смешанным содержимым?
Обычная навигационная ссылка отличается от ресурса, загружаемого внутрь страницы. Классифицируйте ссылку по тому, как её использует браузер.
Почему замена http на https всё равно ломает файл?
Сервер может не отдавать этот ресурс по HTTPS. Проверьте доступный адрес и сертификат, не предполагая, что одной смены схемы достаточно.
Попробуйте на собственном источнике.
Замените пример своим материалом в промпте. Сохраните нужные требования и скопируйте задачу в WebAct.
Настроить и скопировать задачу ↑