Como liberar totalmente redirecionamentos em cache do Safari?

Eu tenho um dispositivo com um painel de controle baseado na Web e o defino acidentalmente para redirecionar todas as httppáginas https, mesmo que algumas não funcionem https. Embora eu tenha corrigido isso, o Safari parece ter memorizado o redirecionamento e está se recusando a esquecê-lo, tentando constantemente me redirecionar para o httpsendereço inválido .

Eu já fechei o Safari, limpei ~/Library/Caches/com.apple.Safari/e ~/Library/Cookies/HSTS.plistainda parece lembrar o redirecionamento quando o abro.

Onde mais o Safari poderia armazenar essas informações? Posso acessar a página correta via Firefox ou Chrome, portanto, pode não ser um serviço para todo o sistema ou, se não for o que os outros navegadores usam.

Infelizmente, como o painel da web é fornecido por um dispositivo, não acredito que possa ajustar os cabeçalhos ou configurar um redirecionamento de volta para o URL correto, que parecem ser opções oferecidas em outras perguntas semelhantes, então preciso descobrir onde isso os dados estão sendo armazenados para que eu possa destruí-los com fogo.

Com base na resposta de quanta :

Não pude usar launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plistporque tenho o System Integrity Protection ativado:

$ 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

No entanto, fui capaz de contornar isso, fazendo o seguinte:

• killall nsurlstoraged(interrompe o processo nsurlstoraged do usuário; na verdade sudo killall nsurlstoraged, eu executei , mas desconfio que não seja necessário interromper o nsurlstoraged do sistema também, pois o cache está na pasta Biblioteca do usuário)
• rm -f ~/Library/Cookies/HSTS.plist (exclui o cache do HSTS)
• launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (reinicia nsurlstoraged)

Se você ativar o menu Desenvolver nas preferências do Safari, poderá limpar o cache a partir daí (CMD + ALT + E).

Você pode confirmar se a abertura do painel de controle do dispositivo na janela Privada do Safari (ou em outro navegador da web) funciona corretamente?

Com base na resposta de @ Haravikk: /apple//a/267783/62907

Alguém tem alguma idéia de qual processo é responsável pelo arquivo ~ / Library / Cookies / HSTS.plist?

fs_usage pode ajudar:

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

Então nós podemos:

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

então:

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

e tente novamente.

Você terá bons resultados se usar a linha de comando curldo dispositivo para garantir que ele não esteja fazendo o redirecionamento. O Safari realmente não tem um mecanismo para reescrever endereços - especialmente se você fizer uma navegação privada para remover histórico, cookies, etc.

Se você não tiver certeza de que limpou o seu safari o suficiente, também pode testar abrindo as preferências do sistema e criando uma conta de usuário nova / limpa no Mac e testando o site em uma versão totalmente limpa do Safari depois de sair do seu usuário normal .

Portanto, encontrei uma solução alternativa para o problema, embora essa não seja uma resposta definitiva para a pergunta real, portanto não a marcarei como tal até encontrar mais informações.

Acontece que o arquivo ~/Library/Cookies/HSTS.plistera realmente a fonte do problema, como eu suspeitava, mas excluí-lo da conta de usuário afetada não funciona, mesmo com o Safari fechado, pois é recriado após um período desconhecido, completo com a ofensa entrada que estava forçando o redirecionamento inválido.

Então, minha solução foi a seguinte:

1. Verifique se você possui pelo menos uma outra conta de usuário no seu Mac (caso contrário, crie uma).
2. Logout da conta de usuário afetada.
3. Faça login em uma conta de usuário diferente (uma conta de convidado pode não ser suficiente, dependendo das restrições).
4. Descubra o nome abreviado da sua conta de usuário afetada; se você não souber, a melhor maneira de verificar é procurar em Preferências do Sistema -> Usuários. Normalmente, se for o nome completo, com letras minúsculas e sem espaços, por isso, se o nome completo for "John Smith", o nome abreviado poderá ser "johnsmith".
5. Abra uma janela no Terminal, digite su shortnamesubstituindo "shortname" pelo nome abreviado da conta de usuário afetada. Pressione Enter e, quando solicitado, digite a senha da conta afetada.
6. Agora digite o próximo comando rm ~/Library/Cookies/HSTS.pliste pressione Enter, isso excluirá o arquivo de armazenamento HSTS.
7. Por fim exit, digite Enter e feche o Terminal.

Nesse ponto, agora você pode fazer login novamente na conta de usuário afetada e o redirecionamento HSTS ofensivo deve ter desaparecido definitivamente.

Agora, embora isso ofereça uma solução utilizável, eu realmente gostaria de saber por que a exclusão do arquivo HSTS.plist da minha conta afetada não funcionou; o fato de ser recriado significa que algum processo em segundo plano é responsável por isso, o que significa que deve ser possível excluir o arquivo da conta de usuário afetada simplesmente parando esse processo, excluindo o arquivo e reiniciando o processo.

Alguém tem alguma idéia de qual processo é responsável pelo ~/Library/Cookies/HSTS.plistarquivo? Uma vez que sabemos que deve ser possível dar uma correção mais simples ao problema.

Aqui está uma ideia!

Você diz que não pode desfazer o redirecionamento configurando o servidor para redirecionar solicitações https novamente para http (pois você não tem acesso de administrador para fazer isso).

Mas e se você enganar o safari para conectar-se a um servidor diferente que ofereça esse redirecionamento reverso?

Você pode configurá-lo no /etc/hostsarquivo da sua máquina local .

Por exemplo, digamos que o redirecionamento em cache atual seja de http://example.compara https://example.com.

Agora configure ou identifique um URL que você pode solicitar em qualquer servidor no mundo que redirecione de https para http. Digamos que o servidor tenha o endereço de https://redirecting.example.com.

Em seguida, procure o endereço IP de redirecting.example.com. No Terminal, você pode fazer assim:

host redirecting.example.com

Você obtém um resultado mais ou menos assim:

redirecting.example.com has address 69.69.69.69

Agora abra seu arquivo / etc / hosts e adicione uma nova linha que aponte solicitações para example.com para o endereço IP de redirecionamento.exemplo.com, da seguinte maneira:

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

Salve as alterações e limpe o cache do DNS no terminal da seguinte maneira:

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

Em seguida, no Safari, faça um pedido para que https://example.coma resposta seja redirecionada de volta para http://example.com, momento em que (o dedo cruzado), seu redirecionamento do Safari de 6 meses atrás será substituído.

Quando terminar, remova a linha que você adicionou ao seu arquivo / etc / hosts e limpe seu cache DNS novamente.

Depois de tentar todas essas soluções, o que funcionou para mim foi:

• Remova todas as instâncias do domínio do histórico do Safari
• Sair do Safari
• Excluir ~/Library/Cookies/HSTS.plist
• Reiniciar

Meus dois centavos para o novo macOS Mojave 10.14 Beta (18A365a)

a) Você não pode parar definitivamente nsurlstoraged, ele é reiniciado em 2 segundos, mesmo que o sudo

b) você não pode excluir "HSTS.plist": se você digitar:

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

você recebe: Operação não permitida

c) mesmo se você tentar:

ls -la ~/Library/Cookies/

você recebe: Operação não permitida

o mesmo para

nano ~/Library/Cookies/HSTS.plist 

(Arquivo vazio..)

Então você não pode acessá- lo definitivamente . (talvez SIP?)

d) estranhamente você pode excluir se do Finder:

CMD Shift G "~ / Biblioteca / Cookies /"

e você pode excluir com o mouse:

e) mais estranho: você pode ir para a área de trabalho usando o mouse, editar e recolocá-lo !

(um verdadeiro absurdo, a GUI é mais poderosa que o sudo ..)

No Safari, Firefox e Chrome também, tudo o que você precisa fazer é abrir a barra lateral do desenvolvedor , selecionar a guia rede e desativar o cache .

No Safari, é uma coisa de tubo riscado, o azul ao lado do logotipo da lixeira. Ative isso e o redirecionamento permanente antigo deve ser ignorado.

O maior benefício é que você não precisa mexer nos arquivos, não excluirá todas as entradas HTST e perderá os benefícios de segurança. Também funciona em navegadores.

Primeiro, verifique se o servidor não está enviando o cabeçalho Strict-Transport-Security
Você pode fazer isso com curl -I( -Iapenas obtém os cabeçalhos)

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

Se o servidor estiver enviando o cabeçalho Strict-Transport-Security, removê-lo do navegador não terá efeito, pois na próxima vez que você acessar o site, ele será definido novamente.

Remova seu site do banco de dados Http Secure Transport Security do Safari

1. Fechar o Safari
2. Editar ~/Library/Cookies/HSTS.plist
   Pesquise a entrada do site que você deseja acessar via http, remova-a e salve o arquivo.
   • Prefiro editar em vez de remover, pois não há necessidade de remover entradas válidas.
   • Eu edito arquivos plist usando o Xcode, mas se não estiver instalado, você pode simplesmente usar um editor de texto.
3. Reinicie o seu computador.
   • Em vez de reiniciar o computador, você pode reiniciar, nsurlstoragedmas isso pode estar envolvido devido ao SIP, portanto, a reinicialização do computador pode ser mais simples. Veja a resposta de Grant e resposta da Quanta sobre reinícionsurlstoraged

Eu escrevi um roteiro com a resposta de 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

Ele finaliza normalmente o safari, para nsurlstoraged, remove o HSTS.plist e inicia o nsurlstoraged novamente. Isso funcionou bem para mim aqui no macOS 10.13.5

Estou usando o Mojave (10.14). Eu tentei os métodos fornecidos até agora para remover o HSTS.plist. Além disso, eu precisava adicionar o Terminal à lista Preferências do sistema> Segurança e privacidade> Acesso total ao disco para curar o sintoma "Operação não permitida" ao listar o conteúdo de ~ / Library / Cookies /.

Porém, remover o arquivo e reiniciar o daemon não funcionou. Então, tentei abrir o Safari novamente, fui para Preferências, Privacidade, Gerenciar dados do site. Em seguida, removi todos os "cookies de cache, armazenamento local" do nome de domínio incorreto. Isso resolveu meu problema.

Não posso dizer agora se a remoção do HSTS foi necessária ou não.

Tente isso, vá para a Etapa 1: Vá para a pasta ~ / Library, Etapa 2: Exclua a pasta Safari de ~ / Library / Application Support, Etapa 3: Exclua as pastas abaixo de ~ / Library / Caches, Etapa 4: depois exclua ~ / Pasta Library / Safari PS: mantenha o safari fechado durante as operações acima