Production Hardening
webforJ's server-driven model und integrierte Schutzmaßnahmen gegen häufige Bedrohungen decken viel ab, aber eine sichere Bereitstellung hängt immer noch davon ab, wie Sie die App betreiben. Die folgenden Schritte runden das Bild ab.
Jede Verbindung verschlüsseln
Führen Sie den Produktionsverkehr nur über HTTPS aus. Beenden Sie TLS am Container, Proxy oder Lastenausgleich vor der App und leiten Sie jede Anfrage über ungesichertes HTTP an ihre sichere Entsprechung weiter, damit Anmeldeinformationen und Sitzungsidentifikatoren niemals unverschlüsselt übertragen werden.
Nichts vom Browser vertrauen
Ein manipuliertes Client kann alles senden. Überprüfen Sie jeden Wert, den Ihr Code erhält, erneut, selbst Werte, die Ihre Schnittstelle bereits eingeschränkt hat, bevor Sie sie speichern oder damit arbeiten. Der Artikel Client/Server-Interaktion erklärt, warum der Server der einzige Ort ist, an dem eine Regel wirklich gelten kann.
webforJ's Datenbindung und Validierung hilft hier: Da die Bindung in Java auf dem Server ausgeführt wird, werden die Einschränkungen, die Sie an ein Modell anhängen, einschließlich Jakarta-Validierung, serverseitig durchgesetzt und nicht nur im Browser. Betrachten Sie das als Ihre Integritätsschicht, nicht als Schutz gegen Injektions- oder Markup-Angriffe, die noch die im Artikel Häufige Bedrohungen beschriebenen Handlungen erfordern.
Deaktiviert und verborgen sind keine Sicherheit
setEnabled(false) und setVisible(false) sind Schnittstellenhinweise, keine Zugriffskontrollen. webforJ spiegelt den deaktivierten Zustand einer Steuerung an den Client, verhindert jedoch nicht, dass ein manipuliertes Client diese Steuerung wieder aktiviert und ihre Aktion auslöst. Verlassen Sie sich niemals auf eine deaktivierte oder verborgene Steuerung, um etwas zu verhindern.
Setzen Sie stattdessen die echte Regel im serverseitigen Handler ein: Bestätigen Sie, dass der Benutzer berechtigt ist und die Vorbedingungen erfüllt sind, bevor Sie die Aktion ausführen, genau so, wie Sie es tun würden, wenn die Steuerung die ganze Zeit über aktiviert gewesen wäre. Der deaktivierte Zustand leitet ehrliche Benutzer; die serverseitige Regel stoppt unehrliche.
Schützen Sie Ihre Ansichten
Sichern Sie Ansichten mit Routen-Sicherheit, sodass jede die richtige Authentifizierung und Rollen erfordert. Geben Sie den Personen den engsten Zugriff, der es ihnen ermöglicht zu arbeiten, und bevorzugen Sie eine sicherheitsorientierte Grundeinstellung, bei der eine unmarkierte Route dennoch eine Anmeldung erfordert.
Geheimnisse extern halten
Anmeldeinformationen, Schlüssel und Tokens gehören nicht in den Code oder Ihr Repository. Ziehen Sie sie stattdessen aus der Umgebung oder einer externen Quelle, wie im Abschnitt Verwalten von Geheimnissen gezeigt.
Aktuell bei Abhängigkeiten bleiben
Die Bibliotheken, die Sie verwenden, sind eine größere Quelle des Risikos als Ihr eigener Code. Verfolgen Sie Hinweise, aktualisieren Sie regelmäßig webforJ und Ihre anderen Abhängigkeiten, und wenn eine gepatchte Version einer transitiven Bibliothek vor der Bibliothek erscheint, die sie einzieht, fixieren Sie die korrigierte Version in Ihrer pom.xml.
Leise fehlgeschlagen
Lassen Sie keine Stack-Traces, Dateipfade oder interne Identifikatoren die Endbenutzer erreichen. Protokollieren Sie die Details in Ihren Serverprotokollen und präsentieren Sie eine einfache, allgemeine Nachricht in der Schnittstelle. Registrieren Sie einen benutzerdefinierten Handler über die Fehlerbehandlung von webforJ, damit nicht erfasste Ausnahmen eine kontrollierte Seite anstelle von Rohdiagnosen anzeigen.
Verantwortungsbewusst offenlegen
Haben Sie einen möglichen Fehler in webforJ selbst gefunden? Melden Sie ihn privat über GitHubs private Vulnerability Reporting, anstatt ein öffentliches Problem oder eine Pull-Anfrage zu eröffnen, damit eine Lösung bereitgestellt werden kann, bevor die Details bekannt werden.