Sicherheitscheckliste für Apps #

Diese Checkliste richtet sich an App-Entwickler und an den Administrator der Installation, mit der die App spricht. Gehen Sie sie vor dem ersten Release durch und erneut, wann immer sich Zugangsdaten, Rollen oder Endpunkte ändern.

Inhalt #

1. Zugangsdaten
2. Konten und Rollen
3. Transport
4. In der App
5. Schreibzugriffe
6. Browser-Apps
7. Überwachung

Zugangsdaten #

• To do: Kein OAuth-Client-Secret, kein persönlicher API-Schlüssel und kein expservices-Token steht im Code, in den Ressourcen oder in der Konfiguration der App (Zugangsdaten auswählen).
• To do: Der OAuth-Codeaustausch und das Erneuern laufen in einem Backend, das das Client-Secret hält (Ein Backend für Ihre App).
• To do: Die App ordnet den OAuth-Rückruf selbst zu, da state nicht zurückgegeben wird (OAuth2-Autorisierungscode-Ablauf).
• To do: response_type=token wird nicht verwendet.
• To do: Schlüssel von Backends und Werkzeugen haben die kleinsten Geltungsbereiche und eine Laufzeit, und ein Termin für den Austausch steht im Kalender.
• To do: expk_ und expt_ stehen im Secret-Scanner jedes Repositorys.

Konten und Rollen #

• To do: Jede App hat ihren eigenen Integrationsbenutzer; keine verwendet den Administrator oder das Konto einer Person.
• To do: content/read ist auf die Bereiche oder Teilbäume beschränkt, die die App zeigt.
• To do: Schreibrichtlinien sind auf einen Ordner und die Klassen beschränkt, die die App anlegt.
• To do: Keine Richtlinien für setup, class oder user für App-Benutzer.
• To do: oauth/authorize nur für die Rollen der Personen, die die App benutzen (Berechtigungen für App-Benutzer).

Transport #

• To do: Jede Anfrage verwendet HTTPS; erwägen Sie rest.ini [Authentication] RequireHTTPS=enabled auf dem Server.
• To do: Der Header Authorization erreicht PHP auf jedem Server und durch jeden Proxy (Der Authorization-Header und Proxys).
• To do: Proxys und CDNs speichern Antworten auf Anfragen mit Authorization nicht zwischen.
• To do: Zugangsdaten werden nie in einer URL gesendet.

In der App #

• To do: Tokens liegen in Keychain oder Keystore, nicht in Einstellungen oder Dateien (Geheimnisse auf Geräten speichern).
• To do: Die HTTP-Protokollierung entfernt Authorization und X-Exp-Token, in jedem Build, der die Maschine des Entwicklers verlässt.
• To do: Das Abmelden löscht Tokens und widerruft expservices-Tokens.
• To do: Gerendertes HTML (renderedOutput) wird in einer Web View ohne Skripte angezeigt, die es nicht braucht, und externe Links öffnen sich im Systembrowser (Gerenderte XHTML-Ausgabe).

Schreibzugriffe #

• To do: Beim Entfernen bittet die App den Benutzer um Bestätigung (Inhalte anlegen und entfernen).
• To do: Wiederholte Anlegeversuche können keine Inhalte verdoppeln (Remote-IDs, 409).
• To do: Jeder Upload-Endpunkt, der für die App gebaut wird, prüft Größe, Typ anhand des Inhalts und Berechtigungen (Dateien und Uploads).

Browser-Apps #

• To do: CORS-Header, die im Webserver ergänzt werden, nennen ausdrückliche Origins und decken nur die API-Pfade ab (Web-Apps, CORS und CSP).
• To do: Die Content Security Policy erlaubt die Verbindungen der App und nichts darüber hinaus.

Überwachung #

• To do: Nach jedem Release liest jemand den Kanal access des Prüfprotokolls: access.apikey.use.failed, access.expservices.token.failed (App-Aktivität nachvollziehen).
• To do: Es gibt einen Plan für durchgesickerte Zugangsdaten: widerrufen, austauschen, Prüfprotokoll kontrollieren.

Verwandte Seiten #

• Sicherheit für Anwendungen
• Sicherheitshärtung
• Persönliche API-Schlüssel: Sicherheitshinweise
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.