Jak w pełni opróżnić buforowane przekierowania z Safari?

Mam urządzenie z internetowym panelem sterowania i przypadkowo ustawiłem przekierowanie wszystkich httpstron https, nawet jeśli niektóre nie działają https. Chociaż od tego czasu poprawiłem to, wygląda na to, że Safari zapamiętało przekierowanie i nie chce o nim zapomnieć, zamiast tego ciągle próbuje przekierować mnie na nieprawidłowy httpsadres.

Ja już zamknięte Safari, wyczyszczone ~/Library/Caches/com.apple.Safari/i ~/Library/Cookies/HSTS.plistale wciąż wydaje się być pamiętając przekierowanie kiedy ponownie go otworzyć.

Gdzie jeszcze Safari może przechowywać te informacje? Mogę uzyskać dostęp do właściwej strony za pośrednictwem przeglądarki Firefox lub Chrome, więc może to nie być usługa ogólnosystemowa lub jeśli nie jest to usługa, z której korzystają inne przeglądarki.

Niestety, ponieważ panel internetowy jest dostarczany przez urządzenie, nie sądzę, żebym mógł dostosować nagłówki lub skonfigurować przekierowanie z powrotem do poprawnego adresu URL, które wydają się być opcjami oferowanymi w innych podobnych pytaniach, więc naprawdę muszę się dowiedzieć, gdzie to dane są przechowywane, więc mogę je zniszczyć ogniem.

Na podstawie odpowiedzi kwanty :

Nie mogłem używać, launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistponieważ mam włączoną ochronę integralności systemu :

$ 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

Byłem jednak w stanie obejść ten problem, wykonując następujące czynności:

• killall nsurlstoraged(zatrzymuje proces nsurlstoraged użytkownika; faktycznie uruchomiłem sudo killall nsurlstoraged, ale podejrzewam, że nie jest konieczne zatrzymywanie również nsurlstoraged systemu, ponieważ pamięć podręczna znajduje się w folderze biblioteki użytkownika)
• rm -f ~/Library/Cookies/HSTS.plist (usuwa pamięć podręczną HSTS)
• launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (restartuje nsurlstoraged)

Jeśli włączysz menu Develop w preferencjach Safari, możesz wyczyścić stamtąd pamięć podręczną (CMD + ALT + E).

Czy możesz potwierdzić, że otwarcie panelu sterowania urządzenia w prywatnym oknie Safari (lub innej przeglądarce) działa poprawnie?

Na podstawie odpowiedzi @ Haravikk: /apple//a/267783/62907

Czy ktoś ma jakieś pomysły, który proces jest odpowiedzialny za plik ~ / Library / Cookies / HSTS.plist?

fs_usage może pomóc:

❯❯❯❯ 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

Więc możemy:

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

następnie:

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

i spróbuj ponownie.

Będziesz mieć dobre wyniki, jeśli użyjesz wiersza poleceń do curlurządzenia, aby upewnić się, że nie wykonuje przekierowania. Safari tak naprawdę nie ma silnika do przepisywania adresów - szczególnie jeśli przejdziesz do przeglądania prywatnego, aby usunąć historię, pliki cookie itp.

Jeśli nie masz pewności, czy wystarczająco wyczyściłeś swoje safari, możesz również przetestować, otwierając preferencje systemowe i tworząc czyste / nowe konto użytkownika na komputerze Mac oraz przetestować witrynę w całkowicie czystej wersji Safari po wylogowaniu się z normalnego użytkownika .

Znalazłem więc obejście problemu, chociaż nie jest to ostateczna odpowiedź na rzeczywiste pytanie, więc nie oznaczę go jako takiego, dopóki nie znajdę więcej informacji.

Okazuje się, że plik ~/Library/Cookies/HSTS.plistrzeczywiście był źródłem problemu, jak podejrzewałem, jednak usunięcie go z konta użytkownika, którego dotyczy problem, nie działa, nawet przy zamkniętym Safari, ponieważ jest odtwarzane po nieznanym czasie, wraz z przestępstwem pozycja, która wymuszała nieprawidłowe przekierowanie.

Więc moje rozwiązanie było następujące:

1. Upewnij się, że masz przynajmniej jedno inne konto użytkownika na komputerze Mac (jeśli nie, utwórz je).
2. Wyloguj się z konta użytkownika, którego dotyczy problem.
3. Zaloguj się do innego konta użytkownika (konto gościa może nie być wystarczające, w zależności od ograniczeń).
4. Znajdź skróconą nazwę konta użytkownika, którego dotyczy problem; jeśli nie wiesz, najlepszym sposobem na sprawdzenie jest sprawdzenie w Preferencjach systemowych -> Użytkownicy. Zwykle jeśli będzie to pełna nazwa, małe litery i bez spacji, więc jeśli twoje pełne imię to „John Smith”, to skróconą nazwą może być „johnsmith”.
5. Otwórz okno w terminalu i wpisz su shortname„krótka nazwa” krótką nazwą konta użytkownika, którego dotyczy problem. Naciśnij Enter i po wyświetleniu monitu wprowadź hasło do konta, którego dotyczy problem.
6. Teraz wpisz następne polecenie rm ~/Library/Cookies/HSTS.plisti naciśnij klawisz Enter, spowoduje to usunięcie pliku pamięci HSTS.
7. Na koniec wpisz exit, naciśnij Enter i zamknij Terminal.

W tym momencie możesz teraz zalogować się ponownie na konto użytkownika, którego dotyczy problem, a szkodliwe przekierowanie HSTS powinno zniknąć na dobre.

Teraz, mimo że zapewnia to użyteczne obejście, naprawdę chciałbym wiedzieć, dlaczego usunięcie pliku HSTS.plist z mojego konta nie zadziałało; fakt jego odtworzenia oznacza, że ​​jest za to odpowiedzialny proces w tle, co oznacza, że ​​powinno być możliwe usunięcie pliku z konta użytkownika, którego dotyczy problem, poprzez zatrzymanie tego procesu, usunięcie pliku, a następnie ponowne uruchomienie procesu.

Czy ktoś ma jakieś pomysły, który proces jest odpowiedzialny za ~/Library/Cookies/HSTS.plistplik? Kiedy już wiemy, że powinno być możliwe prostsze rozwiązanie problemu.

Oto pomysł!

Mówisz, że nie możesz cofnąć przekierowania, ustawiając serwer tak, aby przekierowywał żądania https z powrotem na http (ponieważ nie masz do tego dostępu administratora).

Ale co jeśli oszukasz safari, aby połączyć się z innym serwerem, który oferuje to przekierowanie zwrotne?

Możesz to ustawić w /etc/hostspliku komputera lokalnego .

Załóżmy na przykład, że bieżące przekierowanie z pamięci podręcznej pochodzi z http://example.comdo https://example.com.

Teraz skonfiguruj lub zidentyfikuj adres URL, którego możesz zażądać na dowolnym serwerze na świecie, który przekierowuje z https z powrotem na http. Powiedzmy, że serwer ma adres https://redirecting.example.com.

Następnie wyszukaj adres IP redirecting.example.com. W Terminalu możesz to zrobić w następujący sposób:

host redirecting.example.com

Otrzymasz wynik mniej więcej taki:

redirecting.example.com has address 69.69.69.69

Teraz otwórz plik / etc / hosts i dodaj nowy wiersz, który kieruje żądania do example.com na adres IP przekierowania.example.com, w następujący sposób:

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

Zapisz zmiany i wyczyść pamięć podręczną DNS w terminalu w następujący sposób:

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

Następnie w przeglądarce Safari z prośbą o https://example.comodpowiedź powinno być przekierowanie z powrotem do http://example.com, w którym momencie (kciuki) przekierowanie Safari sprzed 6 miesięcy zostanie zastąpione.

Po zakończeniu usuń wiersz dodany do pliku / etc / hosts i ponownie opróżnij pamięć podręczną DNS.

Po wypróbowaniu wszystkich tych rozwiązań zadziałało dla mnie:

• Usuń wszystkie instancje domeny z historii Safari
• Zamknij Safari
• Kasować ~/Library/Cookies/HSTS.plist
• Uruchom ponownie

Moje dwa centy za nowy system macOS Mojave 10.14 Beta (18A365a)

a) Nie można definitywnie zatrzymać sięnsurlstoraged , uruchamia się ponownie w ciągu 2 sekund, nawet jeśli sudo

b) nie możesz usunąć „HSTS.plist”: jeśli wpiszesz:

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

otrzymujesz: Operacja niedozwolona

c) nawet jeśli spróbujesz:

ls -la ~/Library/Cookies/

otrzymujesz: Operacja niedozwolona

to samo dla

nano ~/Library/Cookies/HSTS.plist 

(pusty plik..)

Więc nie możesz definitywnie uzyskać do niego dostępu . (może SIP?)

d) o dziwo możesz usunąć, jeśli z Findera:

CMD Shift G „~ / Library / Cookies /”

i możesz usunąć myszą:

e) bardziej dziwne: możesz przenieść się na pulpit za pomocą myszy, edytować i umieścić go z powrotem !

(prawdziwy nonsens, GUI ma większą moc niż sudo ..)

W Safari, Firefox i Chrome wystarczy otworzyć pasek boczny programisty , wybrać kartę sieciową i wyłączyć cachin g.

W Safari jest to przekreślona tuba, niebieska obok logo kosza na śmieci. Aktywuj to, a stare stałe przekierowanie powinno zostać zignorowane.

Największą zaletą jest to, że nie musisz bawić się plikami, nie usuniesz wszystkich wpisów HTST i nie stracisz korzyści bezpieczeństwa. Działa również w różnych przeglądarkach.

Najpierw upewnij się, że serwer nie wysyła nagłówka Strict-Transport-Security.
Możesz to zrobić za pomocą curl -I( -Itylko pobiera nagłówki)

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

Jeśli serwer wysyła nagłówek Strict-Transport-Security, usunięcie go z przeglądarki nie przyniesie żadnego efektu, ponieważ przy następnym wejściu na stronę zostanie ono ustawione ponownie.

Usuń swoją witrynę z bazy danych Http Secure Transport Security Safari

1. Zamknij Safari
2. Edytuj ~/Library/Cookies/HSTS.plist
   Wyszukaj wpis witryny, do której chcesz uzyskać dostęp przez http, usuń go i zapisz plik.
   • Wolę edytować niż usuwać, ponieważ nie ma potrzeby usuwania prawidłowych wpisów.
   • Pliki plist edytuję za pomocą Xcode, ale jeśli nie jest zainstalowany, możesz po prostu użyć edytora tekstu.
3. Zrestartuj swój komputer.
   • Zamiast ponownego uruchamiania komputera można uruchomić ponownie, nsurlstoragedale może to być związane z SIP, więc ponowne uruchomienie komputera może być prostsze. Patrz odpowiedź Granta i odpowiedź Quanta jest o ponownym włączeniemnsurlstoraged

Stworzyłem skrypt z odpowiedzi 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

Z wdziękiem kończy safari, zatrzymuje nsurlstoraged, usuwa HSTS.plist i ponownie uruchamia nsurlstoraged. To działało dobrze dla mnie tutaj na macOS 10.13.5

Korzystam z Mojave (10.14). Próbowałem metod podanych do tej pory, aby usunąć HSTS.plist. Ponadto musiałem dodać terminal do listy Preferencje systemowe> Bezpieczeństwo i prywatność> Pełny dostęp do dysku, aby wyleczyć objaw „Operacja niedozwolona” przy wyświetlaniu zawartości ~ / Library / Cookies /.

Ale usunięcie pliku i ponowne uruchomienie demona nie działało. Więc spróbowałem ponownie otworzyć Safari, poszedłem do Preferencji, Prywatności, Zarządzaj danymi witryny. Następnie usunąłem wszystkie „pamięć podręczną plików cookie, pamięć lokalna” dla naruszającej nazwy domeny. To rozwiązało mój problem.

Nie mogę teraz powiedzieć, czy usunięcie HSTS było wymagane, czy nie.

Spróbuj tego, następnie przejdź do kroku 1: przejdź do folderu ~ / Library, krok 2: usuń folder Safari z ~ / Library / Application Support, krok 3: usuń poniższe foldery z ~ / Library / Caches, krok 4: następnie usuń ~ / Biblioteka / folder Safari PS: trzymaj safari zamknięte podczas powyższych operacji