¿Cómo descargo completamente los redireccionamientos en caché de Safari?

Basado en respuesta de quanta :

No pude usar launchctl unload /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist porque tengo Protección de integridad del sistema habilitada:

$ 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

Sin embargo, pude evitarlo haciendo lo siguiente:

• killall nsurlstoraged (detiene el proceso de almacenamiento nsurlaged de su usuario; en realidad ejecuté sudo killall nsurlstoraged , pero sospecho que no es necesario detener el sistema nsurlstoraged del sistema también, ya que el caché está en la carpeta de la biblioteca del usuario)
• rm -f ~/Library/Cookies/HSTS.plist (elimina el caché HSTS)
• launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist (reinicia nsurlstoraged)

Si habilita el menú Desarrollar en las preferencias de Safari, puede borrar la caché desde allí (CMD + ALT + E).

¿Puede confirmar que la apertura del panel de control del dispositivo en la ventana privada de Safari (o en otro navegador web) funciona correctamente?

Obtendrá buenos resultados si usa la línea de comando para curl el dispositivo para asegurarse de que no está haciendo la redirección. Safari no tiene realmente un motor para volver a escribir las direcciones, especialmente si entras en la navegación privada para eliminar cualquier historial, cookies, etc.

Si no está seguro de haber limpiado su safari lo suficiente, también puede realizar pruebas abriendo las preferencias del sistema y creando una cuenta de usuario nueva / limpia en la Mac, y probar el sitio en una versión totalmente limpia de Safari después de desconectarse de tu usuario normal.

Basado en la respuesta de @Haravikk: enlace

  

¿Alguien tiene alguna idea sobre qué proceso es responsable del archivo ~ / Library / Cookies / HSTS.plist?

fs_usage puede ayudar:

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

Entonces, podemos:

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

entonces:

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

y vuelve a intentarlo.

Así que encontré una solución al problema, aunque esta no es una respuesta definitiva a la pregunta real, por lo que no la marcaré como tal hasta que pueda encontrar más información.

Resulta que el archivo ~/Library/Cookies/HSTS.plist fue realmente la fuente del problema como sospechaba, sin embargo, eliminarlo de la cuenta de usuario afectada no funciona, incluso con Safari cerrado, ya que se recrea después de una cantidad desconocida de hora, complete con la entrada ofensiva que estaba forzando la redirección no válida.

Así que mi solución fue la siguiente:

1. Asegúrese de tener al menos otra cuenta de usuario en su Mac (de lo contrario, cree una).
2. Cerrar sesión de la cuenta de usuario afectada.
3. Inicie sesión en una cuenta de usuario diferente (una cuenta de invitado puede no ser suficiente, dependiendo de las restricciones).
4. Averigüe el nombre corto de su cuenta de usuario afectada; si no lo sabe, la mejor forma de comprobarlo es buscar en Preferencias del sistema - > Usuarios Por lo general, si será el nombre completo, en minúscula y sin espacios, por lo tanto, si su nombre completo es "John Smith", entonces el nombre corto puede ser "johnsmith".
5. Abra una ventana en la Terminal, escriba su shortname reemplazando "shortname" con el nombre corto de la cuenta de usuario afectada. Presione enter y, cuando se le solicite, ingrese la contraseña de la cuenta afectada.
6. Ahora escribe el siguiente comando rm ~/Library/Cookies/HSTS.plist y pulsa enter, esto eliminará el archivo de almacenamiento HSTS.
7. Finalmente, escribe exit , pulsa enter y cierra la Terminal.

En este punto, ahora puede volver a iniciar sesión en la cuenta de usuario afectada y el redireccionamiento HSTS ofensivo debería haberse ido definitivamente.

Ahora, mientras esto proporciona una solución útil, realmente me gustaría saber por qué no funcionó eliminar el archivo HSTS.plist de mi cuenta afectada; el hecho de que se vuelva a crear significa que es responsable de algún proceso en segundo plano, lo que significa que debería ser posible eliminar el archivo de la cuenta de usuario afectada simplemente deteniendo ese proceso, eliminando el archivo y luego reiniciando el proceso.

¿Alguien tiene alguna idea de qué proceso es responsable del archivo ~/Library/Cookies/HSTS.plist ? Una vez que sabemos que debería ser posible dar una solución más simple al problema.

Después de probar todas estas soluciones, lo que funcionó para mí fue:

• Eliminar todas las instancias del dominio de la historia de Safari
• Salir de Safari
• eliminar ~/Library/Cookies/HSTS.plist
• reiniciar

Hice un guión a partir de la respuesta 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

Finaliza con gracia el safari, detiene nsurlstoraged, elimina el HSTS.plist y vuelve a iniciar nsurlstoraged. Esto funcionó bien para mí aquí en macOS 10.13.5

mis dos centavos para el nuevo mojave 10.14 Beta (18A365a)

a) Usted no puede detenerse definitivamente nsurlstoraged, se reinicia en 2 segundos, incluso si sudo

b) no puedes eliminar "HSTS.plist": si escribes:

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

tienes: Operación no permitida

c) incluso si intentas hacerlo:

ls -la ~ / Library / Cookies /

Tienes: Operación no permitida

lo mismo para

nano ~ / Library / Cookies / HSTS.plist (archivo vacío ..)

por lo que no puede definitivamente acceder . (tal vez SIP?)

d) extrañamente, puede eliminar si se encuentra en el Finder:

CMD Sift G "~ / Library / Cookies /"

ypuedeeliminarconelmouse:

e) más extraño: Puedes moverte al escritorio con el mouse, editar y volver a colocar !

(una verdadera tontería, la GUI es más poderosa que sudo ...)

Estoy usando Mojave (10.14). He intentado los métodos dados hasta ahora para eliminar HSTS.plist. Además, necesitaba agregar Terminal a las Preferencias del sistema > Seguridad y amp; Privacidad > Lista de acceso completo al disco para curar el síntoma "Operación no permitida" cuando se enumeran los contenidos de ~ / Library / Cookies /.

Pero, eliminar el archivo y reiniciar el daemon no funcionó. Así que intenté abrir Safari nuevamente, fui a Preferencias, Privacidad, Administrar datos del sitio web. Luego eliminé todas las "cookies de caché, almacenamiento local" para el nombre de dominio ofensivo. Eso solucionó mi problema.

No puedo decir ahora si fue necesario eliminar HSTS o no.

¡Aquí hay una idea!

Dice que no puede deshacer la redirección configurando el servidor para redirigir las solicitudes https a http (ya que no tiene acceso de administrador para hacerlo).

Pero, ¿qué pasa si truco se safari para conectarse a un servidor diferente que ofrece esta redirección inversa?

Podría configurarlo en el archivo /etc/hosts de su máquina local.

Por ejemplo, digamos que la redirección actual en caché es de http://example.com a https://example.com .

Ahora configure o identifique una url que puede solicitar en cualquier servidor del mundo que redireccione de https a http. Digamos que el servidor tiene la dirección de https://redirecting.example.com .

Luego busque la dirección IP de redirecting.example.com . En Terminal se puede hacer así:

host redirecting.example.com

Obtienes un resultado como este:

redirecting.example.com has address 69.69.69.69

Ahora abra su archivo / etc / hosts y agregue una nueva línea que señale las solicitudes de example.com a la dirección IP de redirecting.example.com, como por ejemplo:

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

Guarde sus cambios y borre su caché de DNS en el terminal de esta manera:

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

Luego, en Safari realice una solicitud para https://example.com , la respuesta debería ser una redirección a http://example.com , en cuyo punto (se cruzarán los dedos) se sobrescribirá la redirección de Safari de hace 6 meses.

Cuando termine, elimine la línea que agregó a su archivo / etc / hosts y vacíe su caché de DNS nuevamente.

Primero asegúrese de que el servidor no envíe el Encabezado de seguridad de transporte estricto
Puedes hacer esto con curl -I ( -I solo obtiene los encabezados)

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

Si el servidor está enviando el encabezado Strict-Transport-Security, eliminarlo de su navegador no tendrá efecto, ya que la próxima vez que acceda al sitio, se configurará nuevamente.

Elimine su sitio de la base de datos Http Secure Transport Security de Safari

1. Cerrar Safari
2. Editar ~/Library/Cookies/HSTS.plist
   Busque la entrada del sitio al que desea acceder a través de http y elimínelo, y guarde el archivo.
   • Prefiero editar en lugar de eliminar ya que no hay necesidad de eliminar entradas válidas.
   • Edito archivos plist usando Xcode, pero si no está instalado, puedes usar un editor de texto.
3. Reinicia tu computadora.
   • En lugar de reiniciar su computadora, puede reiniciar nsurlstoraged pero eso puede estar involucrado debido a SIP por lo que un reinicio de la computadora puede ser más simple. Consulte respuesta de Grant y La respuesta de Quanta sobre reiniciar nsurlstoraged

Prueba esto entonces, ve a Paso 1: Ve a la carpeta ~ / Library, Paso 2: Eliminar la carpeta de Safari de ~ / Library / Application Support, Paso 3: Borre las siguientes carpetas de ~ / Library / Caches, Paso 4: luego elimina la carpeta ~ / Library / Safari P.S: mantener el safari cerrado durante las operaciones anteriores