Der Scheduler selbst enthält keine integrierten Funktionen zum Schutz von Anwendungen vor Bedrohungen wie SQL-Injektionen, XSS- oder CSRF-Angriffen. Die Sicherstellung der Anwendungssicherheit liegt in erster Linie in der Verantwortung der Entwickler, die die Anwendung erstellen. Das Backend sollte alle eingehenden Daten gründlich validieren, escapen oder bereinigen und die Benutzerzugriffsregeln entsprechend durchsetzen.
Beachten Sie, dass clientseitige Validierung leicht umgangen oder manipuliert werden kann und daher nicht für Sicherheitszwecke verwendet werden sollte. Ihre Hauptfunktion besteht darin, Benutzern sofortiges Feedback zu fehlerhaften Eingaben zu geben, ohne auf eine Serverantwort warten zu müssen. Die endgültige Validierung muss immer serverseitig erfolgen.
Im Folgenden werden einige gängige Angriffsarten beschrieben und Möglichkeiten zu deren Vermeidung vorgeschlagen. Im Allgemeinen reicht es aus, die Best Practices für Backend-CRUD-Operationen auf Ihrer Plattform zu befolgen.
XSS-Angriffe können durch unsichere Backend-CRUD-Implementierungen, Scheduler-Template-Funktionen und Benutzereingaben über die Benutzeroberfläche entstehen:
Bezüglich der Template-Funktionen und der Lightbox werden diese nur dann riskant, wenn auf Serverseite keine Datenbereinigung erfolgt. Die Absicherung des Backends reicht im Allgemeinen aus, um XSS-Angriffe zu verhindern, da clientseitige Schutzmechanismen ohne ein sicheres Backend nicht wirksam sind.
Templates sind so konzipiert, dass sie benutzerdefiniertes Markup – wie formatierten Text, Icons oder Buttons – in Scheduler-Elementen ermöglichen. Dies eröffnet jedoch auch die Möglichkeit für potenzielle Code-Injektionen. Sie können jedes Template neu definieren, um Ihren Sicherheitsanforderungen zu entsprechen.
Da der Scheduler vollständig clientseitig arbeitet, liegt die Verhinderung von SQL-Injektionen in der Verantwortung des Backends.
Zwei wichtige Punkte:
Ihr Backend muss daher Maßnahmen zur Verhinderung von SQL-Injektionen implementieren. Wenn Sie dhtmlxConnector verwenden und Ihre Tabellen wie in der Dokumentation beschrieben konfigurieren, werden alle Eingaben automatisch escaped. Andernfalls stellen Sie sicher, dass Ihre CRUD-Implementierung die besten Sicherheitspraktiken Ihrer gewählten Plattform befolgt (siehe hier).
Wenn Sie dhtmlxConnector im Backend verwenden, können Sie den CSRF-Schutz über die Konfiguration des Connectors aktivieren. Details finden Sie im entsprechenden Artikel zum Schutz vor CSRF- und XSRF-Angriffen.
Falls Sie dhtmlxConnector nicht verwenden, müssen Sie den CSRF-Schutz selbst umsetzen. Hinweise zum Hinzufügen eigener Tokens oder Header zu den vom Scheduler an Ihr Backend gesendeten Anfragen finden Sie in diesem Artikel.
Die Bibliothek bietet eine Konfigurationsoption, mit der Sie Ihre dhtmlxScheduler-Anwendung an den Content Security Policy (CSP)-Standard anpassen können. Dies erhöht den Schutz vor verschiedenen Code-Injektionsangriffen und stärkt die allgemeine Sicherheit Ihrer Anwendung.
Erfahren Sie mehr über die Anwendung von CSP in einer dhtmlxScheduler-Anwendung.
Nach oben