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
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
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.
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)