Lizenz: eine oder mehrere Mitwirkende/r Lizenzverträge an die Apache Software Foundation (ASF) lizenziert. Finden Sie verteilte mit dieser Arbeit für weitere Informationen bezüglich Urheberrecht und Datenschutz-Datei. Die ASF-Lizenzen-diese Datei, um Sie unter der Apache License, Version 2.0 (die “Lizenz”); Sie können diese Datei nur in Übereinstimmung mit der Lizenz. Sie können eine Kopie der Lizenz zu erhalten.
http://www.Apache.org/licenses/LICENSE-2.0 sofern gesetzlich erforderlich oder schriftlich vereinbart, ist die Software unter der Lizenz verteilt auf einer "AS IS" BASIS, ohne Gewährleistungen oder Bedingungen irgendwelcher Art, weder ausdrücklich noch stillschweigend. Finden Sie die Lizenz für die jeweilige Sprache, EZB, Berechtigungen und Beschränkungen
Die folgende Anleitung beinhaltet einige bewährte Sicherheitsmethoden, die Sie, beim Entwickeln einer Anwendung von Cordova beachten sollten. Bitte beachten Sie, dass die Sicherheit ist ein sehr kompliziertes Thema und deshalb dieses Handbuch ist nicht erschöpfend. Wenn Sie, dass Sie zu diesem Leitfaden dazu beitragen können glauben, wenden Sie sich bitte ein Thema in Cordova's Bug-Tracker unter “Dokumentation”abzulegen. Dieser Leitfaden soll auf allgemeine Cordova Entwicklung (alle Plattformen) anwendbar, aber Plattform-spezifischen Besonderheiten zu beachten.
Lesen und verstehen der Whitelist-Guide
Standardmäßig wird die Whitelist auf einem neu erstellten app ermöglichen den Zugriff auf jede Domäne durch die <access> Tag: <access origin="*"> Wenn Netzwerkanforderungen, die anhand der weißen Liste ausgewertet werden soll, dann es wichtig ist, dies zu ändern und erlauben nur die Domänen, denen Sie Zugriff benötigen. Dies kann durch Bearbeiten der Anwendungsebene Config Datei unter: {project}/config.xml (Referenzen) oder {project}/www/config.xml (ältere Projekte)
Android ist Whitelist auf Cordova 2.9.x gilt als sicher, jedoch wurde es entdeckt, dass wenn foo.com in der weißen Liste enthalten ist, foo.com.evil.com die Whitelist-Prüfung zu bestehen könne. Dieses Problem wurde behoben in Cordova 3.x.
Domain-Whitelist funktioniert nicht auf Android API 10 und unten und WP8 für Iframes und XMLHttpRequest. Dies bedeutet ein Angreifer kann einer beliebigen Domäne in einem Iframe laden und jedes Skript auf dieser Seite in Iframe direkt auf Cordova JavaScript-Objekte und die entsprechenden native Java-Objekte zugreifen kann. Sie sollten dies in Betracht ziehen, beim Erstellen von Anwendungen für diese Plattformen. In der Praxis bedeutet dies, um sicherzustellen, dass Sie Ziel einer höher als 10 Android API und, wenn möglich nicht Iframe zu verwenden, um externe Inhalte - laden das InAppBrowser-Plugin oder andere Drittanbieter Plug-ins verwenden.
Auf Android ab Cordova 3.6.0 muss man jetzt Whitelist URLs außerhalb Ihrer Anwendung, wenn die Anwendung Links zu den URLs generiert. Wenn Sie Anwendung generiert tel: , geo: , sms: , intent: oder ähnlichen URLs oder Links zu externen Inhalten, die Sie erwarten, dass im Browser des Benutzers zu öffnen, dann müssen Sie Ihrer weißen Liste zu aktualisieren. Finden Sie im Whitelist für Details.
Wenn Inhalte in einem Iframe aus einer Whitelist-Domäne bereitgestellt werden, haben diese Domäne Zugriff auf die native Cordova-Brücke. Dies bedeutet, dass Sie ein Drittanbieter-Werbe-Netzwerk Whitelist und dienen diese anzeigen über ein Iframe, ist es möglich, dass eine böswillige Anzeige ist aus Iframe ausbrechen und bösartige Aktionen ausführen können. Aus diesem Grund sollten Sie in der Regel nicht Iframes verwenden, wenn Sie den Server steuern, der den Iframe-Inhalt hostet. Beachten Sie, dass es Drittanbieter Plug-ins zur Verfügung gibt, um Werbe-Netzwerke zu unterstützen. Beachten Sie, dass diese Aussage nicht für iOS, nämlich alles gilt, einschließlich der Iframe Verbindungen abfängt.
Cordova unterstützt keine wahre Zertifikat zu fixieren. Das größte Hindernis für das ist ein Mangel an systemeigenen APIs in Android zum Abfangen des SSL-Verbindungen um die Überprüfung des Zertifikats des Servers ausführen. (Obwohl es fixieren auf Android in Java mit JSSE Zertifikat kann, die Webview auf Android in C++ geschrieben ist und Server-Verbindungen für Sie, indem die Webview verarbeitet werden, ist also es nicht möglich, Java und JSSE es zu verwenden.) Da Apache Cordova über mehrere Plattformen hinweg konsistent APIs bieten soll, bricht nicht mit einer Funktion in eine größere Plattform die Konsistenz.
Es gibt Möglichkeiten zur Angleichung Zertifikat fixieren, z. B. Überprüfung, dass die öffentlichen Schlüssel des Servers (Fingerabdruck) der erwartete Wert ist, wenn die Anwendung gestartet wird oder zu anderen verschiedenen Zeiten während der Lebensdauer der Anwendung. Es gibt Drittanbieter Plug-ins zur Cordova, die das tun kann. Jedoch ist dies nicht dasselbe wie wahre Zertifikat fixieren, die automatisch den erwarteten Wert auf jede Verbindung zu dem Server überprüft.
Verwendung selbstsignierter Zertifikate auf dem Server wird nicht empfohlen. Wenn Sie SSL wünschen, ist dann es dringend empfohlen, dass Ihr Server über ein Zertifikat verfügen, die von einer bekannten Zertifizierungsstelle (Certificate Authority) richtig signiert wurde. Die Unfähigkeit auf true Zertifikat festhalten, ist dies wichtiger.
Der Grund ist, dass selbstsignierte Zertifikate zu akzeptieren umgeht die Überprüfung der Zertifikatkette, wodurch jedes Serverzertifikat vom Gerät als gültig betrachtet werden. Dies eröffnet die Kommunikation für Man-in-the-Middle-Angriffe. Es wird sehr leicht für einen Hacker nicht nur abfangen und lesen die gesamte Kommunikation zwischen dem Gerät und dem Server, sondern auch um die Mitteilung zu ändern. Das Gerät wird nie erfahren, dass dies geschieht, weil es nicht überprüfen, ob der Server-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert ist. Das Gerät hat keinen Beweis, dass der Server, der sie erwartet. Wegen der Leichtigkeit einen Man-in-the-Middle-Angriff zu tun ist es nur geringfügig besser als nur http anstelle von Https auf einem nicht vertrauenswürdigen Netzwerk ausgeführt, selbstsignierte Zertifikate zu akzeptieren. Ja, der Datenverkehr verschlüsselt werden würde, aber es könnte mit dem Schlüssel aus einem Man-in-the-Middle, verschlüsselt werden, so dass die Man-in-the-Middle alles, zugreifen kann, so dass Verschlüsselung nutzlos außer für passive Beobachter ist. Nutzer vertrauen SSL um sicher zu sein, und dies absichtlich verdiene es unsicher, so wird die SSL-Verwendung irreführend. Wenn dies auf einem vertrauenswürdigen Netzwerk verwendet wird (d. h., Sie sind völlig innerhalb eines kontrollierten Unternehmen), selbstsignierte Zertifikate noch nicht empfohlen werden. Die beiden Empfehlungen in einem vertrauenswürdigen Netzwerk sind nur http verwenden, da das Netzwerk selbst vertrauenswürdig ist oder ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (nicht selbstsigniert) unterzeichnet. Das Netzwerk vertrauenswürdig ist oder nicht.
Die hier beschriebenen Prinzipien beziehen sich nicht auf Apache Cordova, sie gelten für alle Client-Server-Kommunikation.
Beim Ausführen von Cordova auf Android verwenden android:debuggable="true" in der Anwendung Manifest erlauben SSL-Fehler, z. B. Zertifikat Kette Validierungsfehler auf selbstsignierte Zertifikate. So Sie selbstsignierte Zertifikate in dieser Konfiguration können, aber dies keine Konfiguration, die verwendet werden soll ist, wenn die Anwendung in der Produktion ist. Es soll nur während der Anwendungsentwicklung verwendet werden.
(TBD)