license: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
La siguiente guía incluye algunas mejores prácticas de seguridad que debe considerar al desarrollar una aplicación de Córdoba. Por favor, tenga en cuenta que la seguridad es un tema muy complicado y por lo tanto, esta guía no es exhaustiva. Si usted cree que puede contribuir a esta guía, sienta por favor libre de presentar un número de localizador de fallas de Cordova bajo “Documentación”. Esta guía está diseñada para ser aplicable al desarrollo general Cordova (todas las plataformas), pero tendrá en cuenta consideraciones específicas de la plataforma.
Lea y entienda al manual lista blanca
De forma predeterminada, la lista blanca en una aplicación recién creada permitirá acceder a todos los dominios a través de la <access> etiqueta: <access origin="*"> si quieres peticiones de red debe ser evaluado contra la lista blanca, entonces es importante cambiar esto y permitir que sólo los dominios a los que tienes acceso. Esto puede hacerse editando el archivo de configuración de nivel de aplicación ubicado en: {project}/config.xml (últimos proyectos) o {project}/www/config.xml (proyectos mayores)
Android está lista blanca en Cordova 2.9.x se considera seguro, sin embargo, se descubrió que si foo.com está incluido en la lista blanca, foo.com.evil.com sería capaz de aprobar el examen de la lista blanca. Esto fue fijada en Cordova 3.x.
Dominio whitelisting no funciona en Android API 10 y a continuación y WP8 para iframes y XMLHttpRequest. Esto significa que un atacante puede cargar cualquier tipo de dominio en un iframe y cualquier script en esa página dentro del iframe puede acceder directamente a objetos Cordova JavaScript y los objetos de Java nativos correspondientes. Debe tomar esto en consideración cuando la creación de aplicaciones para estas plataformas. En la práctica esto significa asegurándose de que se meta una API Android superior a 10, y que si es posible no utilice un iframe para cargar contenido externo - utilizan el plugin inAppBrowser u otros plugins de terceros.
En Android, a partir de Cordova 3.6.0, ahora es necesario URLs blanca fuera de su aplicación, si su aplicación genera enlaces a las direcciones URL. Si tu aplicación genera tel: , geo: , sms: , intent: o URLs similares, o proporciona enlaces a contenido externo que tiene previsto abrir en el navegador del usuario, entonces tendrá que actualizar su lista blanca. Consulte a la guía de la lista blanca para más detalles.
Si el contenido se sirve en un iframe desde un dominio en lista blanca, ese dominio tendrá acceso al puente Cordova nativo. Esto significa que si usted blanca una red de publicidad de terceros y servir los anuncios a través de un iframe, es posible que un anuncio malicioso será capaz de romper el iframe y llevar a cabo acciones maliciosas. Debido a esto, generalmente no debe usar iframes a menos que usted controla el servidor que aloja el contenido del iframe. También tenga en cuenta que existen plugins de terceros disponibles para apoyar las redes de publicidad. Tenga en cuenta que esta declaración no es verdadera para iOS, que intercepta todo, incluyendo las conexiones iframe.
Córdova no admite certificado verdadera fijación. La barrera principal para esto es una falta de API nativas en Android para interceptar conexiones SSL para realizar la comprobación del certificado del servidor. (Aunque es posible certificado de fijación en Android en Java utilizando JSSE, el webview en Android está escrito en C++, y las conexiones del servidor son manejadas para usted por el webview, así que no cabe usar Java y JSSE allí.) Desde Apache Cordova pretende ofrecer APIs consistentes en múltiples plataformas, no tener una capacidad en una importante plataforma rompe esa consistencia.
Hay formas para aproximar certificado fijación, tales como comprobación de que clave pública del servidor (huella digital) es el valor esperado cuando se inicia la aplicación o en otras varias veces durante la vida útil de su aplicación. Hay plugins de terceros disponibles para Córdoba que pueda hacer eso. Sin embargo, esto no es lo mismo como verdadero certificado de fijación que verifica automáticamente el valor esperado de cada conexión con el servidor.
No es recomendable utilizar certificados autofirmados en su servidor. Si usted desea SSL, entonces se recomienda que el servidor dispone de un certificado que ha sido debidamente firmado por un conocido CA (autoridad certificadora). La incapacidad de cierto anclaje certificado hace importante.
La razón es que aceptando certificados autofirmados omite la validación de la cadena de certificado, que permite cualquier certificado de servidor ser considerado válido por el dispositivo. Esto abre la comunicación a los ataques man-in-the-middle. Resulta muy fácil para un hacker no solo interceptar y leer toda la comunicación entre el dispositivo y el servidor, sino también modificar la comunicación. El aparato nunca sabrá que esto sucede porque no Verifique que el certificado del servidor está firmado por una CA de confianza. El dispositivo no dispone de ninguna prueba de que el servidor es lo que se espera. Debido a la facilidad de hacer un ataque man-in-the-middle, aceptar los certificados autofirmados sólo es ligeramente mejor que correr sólo http en lugar de https en una red sin confianza. Sí, podría cifrarse el tráfico, pero podría ser cifrado con la clave de un man-in-the-middle, para que el man-in-the-middle pueda acceder a todo, para que el cifrado es inútil salvo para observadores pasivos. Usuarios de confían SSL para estar seguro, y esto estaría deliberadamente haciendo lo inseguro, así que el uso SSL se convierte engañoso. Si esto se utilizará en una red de confianza (es decir, usted es enteramente dentro de una empresa controlada), y luego certificados autofirmados todavía no se recomiendan. Las dos recomendaciones en una red de confianza son utilizar http porque la propia red es de confianza, o para obtener un certificado firmado por una CA de confianza (no auto firmado). La red es de confianza o no.
Los principios aquí descritos no son específicos de Apache Cordova, se aplican a todas las comunicaciones cliente-servidor.
Cuando se ejecuta Cordova en Android, usando android:debuggable="true" en la aplicación de manifiesto permitirá errores de SSL como certificado de errores de validación de la cadena de certificados autofirmados. Así que usted puede utilizar certificados autofirmados en esta configuración, pero esto no es una configuración que se debe utilizar cuando la aplicación está en producción. Es para ser utilizado sólo durante el desarrollo de aplicaciones.
(TBD)