Los Service Workers son scripts que se ejecutan en segundo plano, separados de las páginas web, lo que permite funciones como la funcionalidad sin conexión y las notificaciones push. Aunque son potentes, requieren una cuidadosa consideración de la seguridad, ya que pueden interceptar y modificar las solicitudes de red. Deben servirse a través de HTTPS y seguir las restricciones del mismo origen.
Un service worker es un archivo JavaScript que el navegador registra para ejecutarse en segundo plano, desacoplado de cualquier página concreta e incluso cuando no hay ninguna pestaña abierta. Se sitúa como un proxy de red programable entre el sitio y la red: a través del evento fetch puede interceptar las peticiones salientes, responderlas desde una caché, reescribirlas o dejarlas pasar. Eso es lo que impulsa las experiencias sin conexión, la sincronización en segundo plano y las notificaciones push en las progressive web apps. Los service workers están orientados a eventos y no tienen acceso al DOM; se comunican con las páginas mediante mensajería. El registro está muy restringido: deben servirse por HTTPS, obedecer la política del mismo origen y su alcance se limita a la ruta desde la que se sirven.
Como un service worker puede interceptar y reescribir cada petición dentro de su alcance y persiste entre sesiones, es una posición inusualmente poderosa y duradera en el cliente. Si un atacante logra registrar un worker malicioso, por ejemplo a través de un endpoint de subida que sirve JavaScript controlado por el atacante en un alcance amplio, o explotando un fallo de inyección de scripts existente, obtiene un punto de apoyo persistente de man-in-the-browser que sobrevive a las recargas de página y puede manipular silenciosamente el tráfico, servir contenido falso o recolectar datos mucho después de que el punto de entrada original se haya cerrado. Los requisitos de HTTPS y del mismo origen existen precisamente porque esta capacidad sería catastrófica si un atacante de red o un origen ajeno pudiera plantar uno.
Restringe desde dónde se pueden servir scripts para que un atacante no pueda alojar un worker en un alcance útil: sanea y asigna el content-type a las subidas de los usuarios, evita servir JavaScript controlado por el usuario desde tu origen y limita el alcance del registro con la cabecera Service-Worker-Allowed. Una Content Security Policy con worker-src restringe qué scripts pueden convertirse en workers, y Subresource Integrity junto con la revisión de los pipelines de compilación protege el propio archivo legítimo del worker. cside complementa esto haciendo de proxy y analizando los scripts third-party que carga una página y bloqueando el comportamiento malicioso en tiempo real; el registro forense resultante del código ejecutado ayuda a los investigadores a reconstruir cómo un worker fraudulento o un script inyectado llegó al navegador.
Un service worker no tiene acceso directo al DOM y no puede tocar document.cookie, ya que se ejecuta fuera del hilo principal. Sin embargo, puede interceptar las peticiones de red dentro de su alcance e inspeccionar o modificar sus cabeceras y cuerpos, lo que le otorga una influencia considerable sobre los datos que fluyen hacia y desde la página.
Un service worker puede interceptar y reescribir todo el tráfico de red en su alcance, así que permitir que uno se instale por HTTP en texto plano dejaría que un man-in-the-middle de red plantara un proxy persistente en el navegador de la víctima. Exigir HTTPS garantiza que el script del worker esté autenticado y sin manipular antes de que el navegador le conceda ese poder.
We answer client-side security questions every day. Bring yours.