Как полностью очистить кэшированные перенаправления из Safari?

У меня есть устройство с веб-панелью управления, и я случайно настроил его на перенаправление всех httpстраниц https, даже если некоторые не работают https. Хотя с тех пор я исправил это, Safari, похоже, запомнил перенаправление и отказывается забыть его, вместо этого постоянно пытаясь перенаправить меня на неверный httpsадрес.

Я уже закрыл Safari, очищается ~/Library/Caches/com.apple.Safari/и , ~/Library/Cookies/HSTS.plistно она по- прежнему кажется, вспоминая редирект , когда я вновь открыть его.

Где еще Safari может хранить эту информацию? Я могу получить доступ к нужной странице через Firefox или Chrome, так что это может быть не общесистемная служба или не та, которую используют другие браузеры.

К сожалению, поскольку веб-панель предоставляется устройством, я не верю, что могу настроить заголовки или настроить перенаправление на правильный URL-адрес, что, по-видимому, является опциями, предлагаемыми в других подобных вопросах, поэтому мне действительно нужно выяснить, где это данные хранятся, поэтому я могу уничтожить их огнем.

Основываясь на ответе кванты :

Я не смог использовать, launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistпотому что у меня включена защита целостности системы :

$ launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist
/System/Library/LaunchAgents/com.apple.nsurlstoraged.plist: Operation not permitted while System Integrity Protection is engaged

Однако я смог обойти это, сделав следующее:

• killall nsurlstoraged(останавливает процесс nsurlstoraged вашего пользователя; я действительно запустился sudo killall nsurlstoraged, но я подозреваю, что нет необходимости останавливать также nsurlstoraged системы, поскольку кэш находится в папке Library пользователя)
• rm -f ~/Library/Cookies/HSTS.plist (удаляет кеш HSTS)
• launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (перезапускает nsurlstoraged)

Если вы включите меню «Разработка» в настройках Safari, вы можете очистить кэш оттуда (CMD + ALT + E).

Можете ли вы подтвердить, что открытие панели управления устройства в приватном окне Safari (или в другом веб-браузере) работает правильно?

Основано на ответе @ Haravikk: /apple//a/267783/62907

У кого-нибудь есть идеи, какой процесс отвечает за файл ~ / Library / Cookies / HSTS.plist?

fs_usage может помочь:

❯❯❯❯ sudo fs_usage | grep HSTS
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000238   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000009   nsurlstorage
16:11:03  open              /Users/quanta/Library/Cookies/HSTS.plist                                         0.016268   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000008   nsurlstorage
16:11:03    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000003   nsurlstorage
16:11:03  access            /Users/quanta/Library/Cookies/HSTS.plist                                         0.000011   dbfseventsd
16:11:04  lstat64           /Users/quanta/Library/Cookies/HSTS.plist                                         0.000008   fseventsd
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000006   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000002   nsurlstorage
16:11:08  open              /Users/quanta/Library/Cookies/HSTS.plist                                         0.000144   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000002   nsurlstorage
16:11:08    HFS_update      /Users/quanta/Library/Cookies/HSTS.plist                                         0.000003   nsurlstorage
16:11:08  access            /Users/quanta/Library/Cookies/HSTS.plist                                         0.000021   dbfseventsd
16:11:09  lstat64           /Users/quanta/Library/Cookies/HSTS.plist                                         0.000042   fseventsd

Значит мы можем:

launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist

тогда:

rm -f ~/Library/Cookies/HSTS.plist

и попробуй еще раз.

Вы получите хорошие результаты, если будете использовать командную строку для curlустройства, чтобы убедиться, что оно не выполняет перенаправление. Safari на самом деле не имеет движка для переписывания адресов - особенно если вы заходите в приватный просмотр, чтобы удалить историю, куки и т. Д.

Если вы не уверены, что достаточно очистили свое сафари, вы также можете выполнить тестирование, открыв системные настройки и создав чистую / новую учетную запись пользователя на Mac и протестировав сайт в полностью чистой версии Safari после выхода из системы обычного пользователя. ,

Итак, я нашел обходной путь к проблеме, хотя это не является окончательным ответом на реальный вопрос, поэтому я не буду отмечать его как таковой, пока не смогу найти больше информации.

Оказывается, что файл ~/Library/Cookies/HSTS.plistдействительно был источником проблемы, как я подозревал, однако удаление его из уязвимой учетной записи пользователя не работает, даже с закрытой Safari, так как он воссоздается через неизвестное время, вместе с нарушителем запись, которая форсирует недопустимое перенаправление.

Поэтому мое решение было следующим:

1. Убедитесь, что у вас есть хотя бы одна учетная запись пользователя на вашем Mac (если нет, создайте ее).
2. Выход из уязвимой учетной записи пользователя.
3. Войдите в другую учетную запись пользователя (гостевой учетной записи может быть недостаточно, в зависимости от ограничений).
4. Узнайте краткое имя вашей уязвимой учетной записи пользователя; если вы не знаете, то лучший способ проверить это - заглянуть в Системные настройки -> Пользователи. Обычно, если будет полное имя, в нижнем регистре и без пробелов, поэтому, если ваше полное имя «Джон Смит», тогда короткое имя может быть «johnsmith».
5. Откройте окно в Терминале, введите su shortnameзамену «shortname» коротким именем затронутой учетной записи пользователя. Нажмите ввод и при появлении запроса введите пароль для соответствующей учетной записи.
6. Теперь введите следующую команду rm ~/Library/Cookies/HSTS.plistи нажмите Enter, это удалит файл хранилища HSTS.
7. Наконец exit, нажмите Enter и закройте терминал.

В этот момент вы можете снова войти в уязвимую учетную запись пользователя, и перенаправляющий HSTS-нарушитель должен исчезнуть навсегда.

Теперь, несмотря на то, что это предоставляет полезный обходной путь, я действительно хотел бы знать, почему удаление файла HSTS.plist из моей затронутой учетной записи не сработало; тот факт, что он воссоздан, означает, что за него отвечает какой-то фоновый процесс, что означает, что должна быть возможность удалить файл из уязвимой учетной записи пользователя, просто остановив этот процесс, удалив файл, а затем перезапустив процесс.

У кого-нибудь есть идеи, какой процесс отвечает за ~/Library/Cookies/HSTS.plistфайл? Как только мы узнаем, что должно быть возможно дать более простое решение проблемы.

Вот идея!

Вы говорите, что не можете отменить перенаправление, настроив сервер перенаправлять запросы https обратно на http (так как у вас нет прав администратора).

Но что, если вы обманываете сафари при подключении к другому серверу, который предлагает это обратное перенаправление?

Вы можете установить это в /etc/hostsфайле вашего локального компьютера .

Например, допустим, что текущее кэшированное перенаправление - с http://example.comна https://example.com.

Теперь настройте или определите URL, который вы можете запросить на любом сервере в мире, который перенаправляет с https обратно на http. Допустим, этот сервер имеет адрес https://redirecting.example.com.

Затем найдите IP-адрес redirecting.example.com. В терминале вы можете сделать так:

host redirecting.example.com

Вы получите результат примерно так:

redirecting.example.com has address 69.69.69.69

Теперь откройте файл / etc / hosts и добавьте новую строку, которая направляет запросы для example.com по IP-адресу redirecting.example.com, например так:

### point host example.com at the ip address of redirecting.example.com
69.69.69.69 example.com

Сохраните изменения и очистите кэш DNS в терминале следующим образом:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; say DNS cache flushed

Затем в Safari сделать запрос на https://example.comответ должен быть редирект обратно http://example.com, в этот момент (скрестив пальцы) ваш редирект Safari от 6 месяцев назад будет перезаписан.

Когда закончите, удалите строку, которую вы добавили в файл / etc / hosts, и снова очистите кэш DNS.

После всех этих решений у меня сработало следующее:

• Удалить все экземпляры домена из истории Safari
• Выйти из сафари
• удалять ~/Library/Cookies/HSTS.plist
• Начать сначала

Мои два цента за новую macOS Mojave 10.14 Beta (18A365a)

а) Вы не можете остановиться окончательно nsurlstoraged, он запускается через 2 секунды, даже если sudo

б) вы не можете удалить "HSTS.plist": если вы набираете:

sudo rm -f ~/Library/Cookies/HSTS.plist

Вы получаете: Операция не разрешена

в) даже если вы попробуете:

ls -la ~/Library/Cookies/

Вы получаете: Операция не разрешена

то же самое для

nano ~/Library/Cookies/HSTS.plist 

(пустой файл ..)

Таким образом, вы не можете определенно получить к нему доступ . (может SIP?)

г) как ни странно, вы можете удалить, если из Finder:

CMD Shift G "~ / Library / Печенье /"

и вы можете удалить с помощью мыши:

д) более странно: вы можете перейти на рабочий стол с помощью мыши, отредактировать и поместить его обратно !

(настоящая ерунда, GUI более мощный, чем sudo ..)

В Safari, Firefox и Chrome все, что вам нужно сделать, это открыть боковую панель разработчика , выбрать вкладку сети и отключить кэширование .

В Safari это зачеркнутая труба, синяя рядом с логотипом мусорного ведра. Активируйте это, и старый постоянный редирект должен быть проигнорирован.

Самым большим преимуществом является то, что вам не нужно связываться с файлами, вы не удалите все записи HTST и не потеряете преимущества безопасности. Также это работает через браузеры.

Сначала убедитесь, что сервер не отправляет заголовок Strict-Transport-Security.
Вы можете сделать это с помощью curl -I( -Iпросто получите заголовки).

curl -I http://my-http-domain.com

Если сервер отправляет заголовок Strict-Transport-Security, удаление его из браузера не будет иметь никакого эффекта, так как при следующем входе на сайт он будет установлен снова.

Удалите свой сайт из базы данных Safari Http Secure Transport Security.

1. Закрыть Safari
2. Изменить ~/Library/Cookies/HSTS.plist
   Поиск записи для сайта, к которому вы хотите получить доступ через http, удалить его и сохранить файл.
   • Я предпочитаю редактировать, а не удалять, так как нет необходимости удалять действительные записи.
   • Я редактирую файлы plist, используя Xcode, но если он не установлен, вы можете просто использовать текстовый редактор.
3. Перезагрузите компьютер.
   • Вместо перезагрузки компьютера вы можете перезагрузить компьютер, nsurlstoragedно это может быть связано с SIP, поэтому перезагрузка компьютера может быть проще. Знакомства ответ Гранта и ответ Quanta в о перезапускеnsurlstoraged

Я сделал сценарий из ответа Grand Heaslip:

#!/bin/sh

osascript -e 'quit app "Safari"'
sleep 2
killall nsurlstoraged
sleep 2
rm -f ~/Library/Cookies/HSTS.plist
launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist

Он корректно завершает сафари, останавливает nsurlstoraged, удаляет HSTS.plist и снова запускает nsurlstoraged. У меня это работало нормально на macOS 10.13.5

Я использую Мохаве (10.14). Я попробовал методы, приведенные до сих пор, чтобы удалить HSTS.plist. Кроме того, мне нужно было добавить терминал в список «Системные настройки»> «Безопасность и конфиденциальность»> «Полный доступ к диску», чтобы устранить симптом «Операция не разрешена» при отображении содержимого ~ / Library / Cookies /.

Но удаление файла и перезапуск демона не сработали. Поэтому я снова попытался открыть Safari, зашел в «Настройки», «Конфиденциальность», «Управление данными сайта». Затем я удалил все «файлы cookie кэша, локальное хранилище» для доменного имени, нарушившего правила. Это решило мою проблему.

Я не могу сейчас сказать, требовалось ли удаление HSTS или нет.

Затем попробуйте выполнить это действие, перейдите к шагу 1: перейдите в папку ~ / Library, шаг 2: удалите папку Safari из ~ / Library / Application Support, шаг 3: удалите указанные ниже папки из ~ / Library / Caches, шаг 4: затем удалите ~ / Папка Library / Safari PS: во время вышеуказанных операций держите сафари закрытым