Seguridad
For information on how to properly disclose an Electron vulnerability, see SECURITY.md.
Para las vulnerabilidades de Chromium: Electron se mantiene al día con versiones alternativas de Chromium. Para más información, consulte el documento de Calendario de Lanzamiento de Electron.
Prólogo
Como desarrolladores web, solemos disfrutar de la sólida red de seguridad del navegador — los riesgos asociados con el código que escribimos son relativamente pequeños. A nuestras páginas web se les concede poderes limitados en un sandbox, y confiamos en que nuestros usuarios disfrutan un buscador construido por un gran equipo de ingenieros que es capaz de responder rápidamente a recientes amenazas de seguridad descubiertas.
Cuando se trabaje con Electron, es importante entender que Electron no es un navegador web. Te permite construir aplicaciones de escritorio llenas de utilidades con tecnologías web familiares, pero tu código tiene mucho más poder. JavaScript puede acceder a los archivos del sistema, actividades del usuario y más. Esto permite que construyas aplicaciones nativas de alta calidad, pero los riesgos inherentes de seguridad escalan con el poder adicional concedido a tu código.
Con eso en mente, ten en cuenta que mostrar contenido arbitrario proveniente de fuentes poco confiables viene con un riesgo severo que Electron no está diseñado para manejar. De hecho, las aplicaciones Electron más populares (Atom, Slack, Visual Studio Code, etc) muestran principalmente contenido local (o confiable, contenido remoto seguro sin integración de Node) — si tu aplicación ejecuta código desde una fuente en línea, es tu responsabilidad el asegurarte de que el código no es malicioso.
Pautas generales
La seguridad es responsabilidad de todos
Es importante recordar que la seguridad de tu aplicación de Electron es el resultado de la seguridad general de los cimientos del framework (Chromium, Node.js), de Electron en sí mismo, todas las dependencias de NPM y tu propio código. Por tanto, es tu responsabilidad seguir algunas importantes mejores prácticas:
-
Mantenga su aplicación actualizada con la última versión liberada de Electron. Cuando libere su producto, también está compartiendo un conjunto compuesto de Electron, librerías compartidas de Chromium y Node.js. Vulnerabilidades afectando a estos componentes pueden impactar en la seguridad de su aplicación. Al actualizar Electron a la última versión, te aseguras de que las vulnerabilidades críticas (como los bypasses de nodeIntegration) ya estén corregidas y no puedan ser explotadas en tu aplicación. Para más informacón, vea "Use a current version of Electron".
-
**Evalue sus dependencias.**Mientras NPM provee más de medio millón de paquetes reusables, es su responsabilidad la elección de librerías confiables de terceros. Si utiliza librerías desactualizadas afectadas por vulnerabilidades conocidas o basado en código escasamente mantenido, la seguridad de su aplicación puede estar en peligro.
-
Adopte prácticas de programación segura. La primera línea de defensa de su aplicación es su propio código. Vulnerabilidades usuales, tales como Cross-Site Scripting (XSS), tienen un alto impacto en la seguridad en las aplicaciones Electron así es altamente recomendable adoptar políticas confiables de buenas prácticas en el desarrollo de software y realizar pruebas de seguridad.
Aislamiento para contenido no confiable
Un problema de seguridad existe siempre que recibes código de un lugar no confiable (e.g. un servidor remoto) y lo ejecutas localmente. Si un atacante de algún modo se las arregla para cambiar dicho contenido (bien sea atacando la fuente directamente, o interviniendo entre su aplicación y el destino real), será capaz de ejecutar códigos nativos en la máquina del usuario.
Bajo ninguna circunstancia deberías cargar y ejecutar código remoto con la integración de Node.js activada. En su lugar, use solo archivos locales (empaquetados junto con su aplicación) para ejecutar código Node.js. Para mostrar contenido remoto, use la etiqueta <webview> o un WebContentsView y asegúrese de desactivar el nodeIntegration y activar contextIsolation.
Las advertencias y recomendaciones de seguridad se imprimen en la consola de desarrollador. Solo se muestran cuando el nombre del binario es Electron, lo que indica que un programador está mirando actualmente a la consola.
Usted puede activar o desactivar estas advertencias forzosamente configurando ELECTRON_ENABLE_SECURITY_WARNINGS o ELECTRON_DISABLE_SECURITY_WARNINGS ya sea en process.env o en el objeto window.
Lista de comprobación: Recomendaciones de seguridad
Al menos debes seguir los siguientes pasos para mejorar la seguridad de su aplicación:
- Solo carga contenido seguro
- No habilitar la intergración de Node.js para contenido remoto
- Activar el aislamiento de contexto en todos los renderizadores
- Activar el aislamiento del proceso
- Usar
ses.setPermissionRequestHandler()en todas las sesiones que cargan contenido remoto - No desactives
webSecurity - Define un
Content-Security-Policyy usa reglas estrictas (i.e.script-src 'self') - No active
allowRunningInsecureContent - No active ajustes experimentales
- No use
enableBlinkFeatures <webview>: No useallowpopups<webview>: Verificar opciones y parámetros- Deshabilitar o limitar navegación
- Deshabilitar o limitar la generación de nuevas ventanas
- No utilice
shell.openExternalcon contenido no confiable - Usar una versión actual de Electron
- Validar el
senderde todos los mensajes IPC - Evite el uso del protocolo
file://y prefiera el uso de protocolos personalizados - Compruebe qué fusibles puede cambiar
- No exponer las API de Electron para contenido web no confiable
1. Solo carga contenido seguro
Cualquier recurso no incluido con tu aplicación debería ser cargado usando un protocolo de seguridad como HTTPS. En otras palabras, no uses protocolos inseguros como HTTP. De manera similar, recomendamos el uso de WSS antes de WS, FTPS antes de FTP, y así.
¿Por què?
HTTPS tiene dos beneficios principales:
- Asegura la integridad de los datos, afirmando que los datos no fueron modificados durante la transmisión entre tu aplicación y el host.
- Encripta el tráfico entre tu usuario y el host destino, haciendo más difícil escuchar a escondidas la información enviada entre tu aplicación y el host.
¿Còmo?
// Bad
browserWindow.loadURL('http://example.com')
// Good
browserWindow.loadURL('https://example.com')
<!-- Bad -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">
<!-- Good -->
<script crossorigin src="https://example.com/react.js"></script>
<link rel="stylesheet" href="https://example.com/style.css">
2. No habilitar la intergración de Node.js para contenido remoto
Esta recomendación es el comportamiento por defecto desde Electron 5.0.0.
Es primordial que no active la integración Node.js en ningún renderizador (BrowserWindow, WebContentsView, o <webview>) que carga contenido remoto. La meta es limitar los poderes que concedes al contenido remoto, aunque lo hace dramáticamente más difícil para un atacante lastimar a tus usuarios, ellos deberían ganar la habilidad de ejecutar JavaScript en tu página web.
Luego de esto, puedes conceder permisos adicionales para anfitriones específicos. Por ejemplo, si estás abriendo un BrowserWindows apuntado a https://example.com/, puedes dar a ese sitio web exactamente las capacidades que necesita, pero no más.
¿Por què?
Un ataque cross-site-scripting (XSS) es más peligroso si un atacante puede altar fuera del proceso de renderizado y ejecutar el código en la computadora del usuario. Ataques cross-site-scripting son muy comunes - y durante un problema, su poder es usualmente limitado a molestar a la página en dónde los están ejecutando. Desactivar la integración Node.js ayuda a prevenir un XSS de ser escalado en un llamado ataque de "Ejecución de Código Remoto".
¿Còmo?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
contextIsolation: false,
nodeIntegration: true,
nodeIntegrationInWorker: true
}
})
mainWindow.loadURL('https://example.com')
// Good
const mainWindow = new BrowserWindow({
webPreferences: {
preload: path.join(app.getAppPath(), 'preload.js')
}
})
mainWindow.loadURL('https://example.com')
<!-- Incorrecto -->
<webview nodeIntegration src="page.html"></webview>
<!-- Correcto -->
<webview src="page.html"></webview>
Cuando desactivas la integración Node.js, todavía puedes exponer APIs a tu página web que consume módulos Node.js o características. Los scripts de precarga continúan teniendo acceso a require y otras características de Node.js, permitiendo a los desarrolladores exponer una API personalizada al contenido remotamente cargado a través de contextBridge API.
3. Habilitar el aislamiento de contexto
Aislamiento de contexto es el comportamiento por defecto en Electron desde 12.0.0.
Context isolation es un ajuste de Electron que permite a los desarrolladores ejecutar códigos en guiones de pre carga y en APIs de Electron en un contexto dedicado de JavaScript. En práctica, eso significa que los objetos globales como Array.prototype.push o JSON.parse no puede ser modificado por guiones por guiones ejecutándose en el proceso de renderizado.
Electron usa la misma tecnología que los Content Scripts de Chromium para activar este comportamiento.
Incluso cuando nodeIntegration: false es usado, para verdaderamente implementar un fuerte aislamiento y evitar el uso de primitivas de Node tambien se debe usar contextIsolation.
Tenga en cuenta que al inhabilitar el aislamiento de contexto para un proceso de renderizado mediante la configuración de nodeIntegration: true, también se inhabilita el proceso arenero para ese proceso. Consulte la sección a continuación.
Para más información sobre que es contextIsolation y como habilitarlo, consulte nuestra documentación dedicada en Context Isolation.
4. Activar el aislamiento del proceso
Esta recomendación es el comportamiento por defecto desde Electron 20.0.0.
Además, se puede implementar el arenero de procesos para todos los procesos de renderizado en toda la aplicación: Habilitar arenero globalmente
Inhabilita el aislamiento de contexto (consulte arriba) _también inhabilita el proceso arenero _, independientemente de lo predeterminado, sandbox: false o globalmente habilitado para el arenero!
Sandboxing es una característica de Chromium que usa el sistema operativo para limitar significativamente a lo que que el proceso de renderizado tiene acceso. Deberías activar el sandbox en todos los procesos de renderizado. No se recomienda la carga, lectura o el procesado de cualquier contenido que no sea de confianza en un proceso no protegido, incluido el proceso principal.
Para mas información acerca del Process Sandboxing y como habilitarlo por favor vea el siguiente documento Process Sandboxing.
5. Administrar solicitudes de permiso de sesión desde contenido remoto
Puede que hayas visto solicitudes de permiso mientras usas Chrome: aparecen cada vez que el sitio web intenta usar una característica que el usuario tiene que aprobar manualmente (como las notificaciones).
La API está basada en los Chromium permissions API e implementa el mismo tipo de permisos.
¿Por què?
Por defecto, Electron aprobará automáticamente todos los pedidos de permiso a menos que el desarrollador haya configurado manualmente un comerciante personalizado. Aunque es un sólido ajuste automático, los desarrolladores conscientes de la seguridad pueden querer asumir lo contrario.
¿Còmo?
code
Note: session.defaultSession is only available after app.whenReady is called.
6. No desactives webSecurity
Esta recomendación es la predeterminada de Electron.
Usted ya pudo haber adivinado que al desactivar la propiedad webSecurity en un procesador de renderizado (BrowserWindow, WebContentsView, o <webview>) deshabilita funciones de seguridad elementales.
No deshabilite webSecurity en aplicaciones de producción.
¿Por què?
Desactivar webSecurity deshabilitará la política de mismo-origen y establecer la propiedad allowRunningInsecureContent a true. En otras palabras, permite la ejecución de código inseguro desde diferentes dominios.
¿Còmo?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
webSecurity: false
}
})
// Good
const mainWindow = new BrowserWindow()
<!-- Bad -->
<webview disablewebsecurity src="page.html"></webview>
<!-- Good -->
<webview src="page.html"></webview>
7. Define un contenido de política de seguridad
Un Contenido de Política de Seguridad (CSP) es una capa adicional de protección contra los ataques cross-site-scripting attacks y ataques de inyecciones de data. Recomendamos que ellos estén activados por cualquier página web cargada dentro de Electron.
¿Por què?
CSP permite que el servidor dando contenido pueda restringir y controlar los recursos que Electron puede cargar para esa página web dada. https://example.com debería estar permitido para guiones de pre carga de los orígenes que definiste mientras que los guiones de https://evil.attacker.com no debería tener permitido ejecutarse. Definir un CSP es una manera fácil de mejorar la seguridad de tus aplicaciones.
¿Còmo?
El siguiente CSP permitirá que Electron ejecute guiones desde la página web actual y desde apis.example.com.
// Bad
Content-Security-Policy: '*'
// Good
Content-Security-Policy: script-src 'self' https://apis.example.com
Cabeceras CSP HTTP
Electron respeta la cabecera HTTP de Content-Security-Policy la cual puede ser fijada utilizando el manipulador webRequest.onHeadersReceived de Electron:
const { session } = require('electron')
session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
callback({
responseHeaders: {
...details.responseHeaders,
'Content-Security-Policy': ['default-src \'none\'']
}
})
})
Note: session.defaultSession is only available after app.whenReady is called.
Etiqueta meta CSP
El mecanismo de entrega preferido de CSP es en una cabecera HTTP. Sin embargo, no es posible usar este método al cargar un recurso usando el protocolo file://. Esto puede ser útil en algunos casos para establecer una política directamente en una página en el marcador usando la etiqueta <meta>:
<meta http-equiv="Content-Security-Policy" content="default-src 'none'">
8. No active allowRunningInsecureContent
Esta recomendación es la predeterminada de Electron.
Por defecto, Electron no permitirá sitios webs cargados sobre HTTPS para cargar y ejecutar scripts, CSS, o plugins desde orígenes inseguros (HTTP). Establecer la propiedad allowRunningInsecureContent a true deshabilita esa protección.
Descargar la inicial HTML de un sitio web mediante HTTPS e intentar descargar recursos subsecuentes mediante HTTP es también conocido como "contenido mixto".
¿Por què?
Cargando contenido sobre HTTPS se asegura la autenticidad y la integridad de los recursos cargados mientras se cifra el trafico en si mismo. Ver la sección en only displaying secure content para más detalles.
¿Còmo?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
allowRunningInsecureContent: true
}
})
// Good
const mainWindow = new BrowserWindow({})
9. No active ajustes experimentales
Esta recomendación es la predeterminada de Electron.
Usuarios avanzados de Electron pueden habilitar las características experimentales de Chromium usando la propiedad experimentalFeatures.
¿Por què?
Las características experimentales son, como el nombre lo indica experimentales y no han sido activadas para todos los usuarios de Chromium. Además, es probable que no se haya probado su impacto en Electron como un conjunto.
Casos de uso legítimo existen, pero excepto que usted sepa lo que está haciendo, usted no debería habilitar esta propiedad.
¿Còmo?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
experimentalFeatures: true
}
})
// Good
const mainWindow = new BrowserWindow({})
10. No use enableBlinkFeatures
Esta recomendación es la predeterminada de Electron.
Blink es el nombre del motor de renderizado detrás de Chromium. Como con la propiedad experimentalFeatures, la propiedad enableBlinkFeatures permite a los desarrolladores habilitar características que han sido deshabilitada por defecto.
¿Por què?
En general, probablemente hay buenas razones si una función no fue habilitada por defecto. Casos de uso legítimo para habilitar funciones especificas existen. Como un desarrollador, usted debería saber exactamente por qué usted necesita habilitar una función, cuales son las ramificaciones, y como impacta las seguridad de su aplicación. Usted no debería habilitar funciones de forma especulativa bajo ninguna circunstancia.
¿Còmo?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
enableBlinkFeatures: 'ExecCommandInJavaScript'
}
})
// Good
const mainWindow = new BrowserWindow()
11. No usar allowpopups para WebViews
Esta recomendación es la predeterminada de Electron.
Si usted está usando <webview>, tal vez necesite las páginas y guiones cargados en su etiqueta <webview> para abrir nuevas ventanas. El atributo allowpopups los habilita para crear BrowserWindows nuevo utilizado el método window.open(). tags <webview> de otra manera no se permite crear nuevas ventanas.
¿Por què?
Si usted no necesita ventanas emergentes, le conviene no permitir la creación de nuevos BrowserWindows por defecto. Esto sigue el principio de acceso de mínimamente requerido: No permita que un sitio web cree nuevas ventanas excepto usted sepa que se necesita esa función.
¿Còmo?
<!-- Bad -->
<webview allowpopups src="page.html"></webview>
<!-- Good -->
<webview src="page.html"></webview>
12. Verificar las opciones de WebView antes de la creación
Un WebView creado en un proceso de renderizado que no contenga integración habilitada de Node.js no será capaz de habilitar integración por sí mismo. Sin embargo, a WebView siempre creará un proco de renderizado independiente con su propio webPreferences.
Es una buena idea controlar la creación de nuevas etiquetas <webview> desde el proceso principal y verificar que su webPreferences no desactiven características de seguridad.