Risiken durch JavaScript in Dynamics 365

JavaScript ist in Dynamics 365 der Bereich in dem sich Altlasten am schnellsten ansammeln. Ein Formular-Skript läuft jahrelang unauffällig weiter, auch wenn die verwendete Programmierschnittstelle längst abgelöst wurde. Erst ein Plattform-Update oder eine Migration macht daraus ein Problem.

Die abgelöste Programmierschnittstelle

Das häufigste Muster ist der Zugriff über "Xrm.Page". Dieses Objekt war jahrelang der Standardweg um im Formular auf Felder zuzugreifen. Seit Version 9 gilt es als abgelöst. Vorgesehen ist der neue Weg über den Ausführungskontext und "formContext".

"Xrm.Page" funktioniert weiterhin und genau das ist die Falle. Es gibt aktuell noch keinen Zeitpunkt an dem der Umbau erzwungen wird also passiert er nicht. Wer heute noch Skripte mit diesem Zugriff hat verschiebt eine Aufgabe welche irgendwann unter Zeitdruck erledigt werden muss.

Ähnlich verhält es sich mit dem alten Objektmodell aus der 2011er-Zeit und mit den damaligen Endpunkten für Datenzugriffe. Beides taucht in gewachsenen Lösungen regelmäßig auf.

Sicherheitsrelevante Muster

Einige Konstrukte sind unabhängig vom Alter problematisch.

• "eval" und funktionale Entsprechungen führen beliebigen Code aus. In einem Formular-Skript gibt es dafür praktisch nie einen guten Grund.
• Direkte Zuweisungen an "innerHTML" schreiben ohne Bereinigung ins Dokument. Wenn dabei Daten aus Datensätzen landen ist das ein Einfallstor.
• Unverschlüsselte Aufrufe auf "http://" statt "https://" übertragen Inhalte im Klartext.
• Absolute URLs auf die eigene Umgebung brechen sobald die Lösung in eine andere Umgebung wandert. Relative Pfade sind hier die richtige Wahl.

Die leiseren Probleme

Manches ist kein Sicherheitsthema kostet aber Zeit.

Vergessene "console.log"- oder "debugger"-Anweisungen deuten darauf hin, dass ein Skript im Debugging-Zustand ausgeliefert wurde. Manche Lösungen binden Fremdbibliotheken in alten Versionen ein, etwa eine betagte jQuery-Version. Die bringen bekannte Schwachstellen mit. Unkomprimierte Skripte in großer Zahl verlangsamen das Laden von Formularen.

Und dann gibt es die Skripte die niemand mehr zuordnen kann: Web-Ressourcen die in keinem Formular und in keinem Ribbon referenziert werden. Entweder sie sind tot und können weg oder sie werden von einer anderen Lösung verwendet die man hier nicht sieht. Aus dem Export allein lässt sich das nicht unterscheiden. Also wird sicherheitshalber nichts gelöscht und der Bestand wächst weiter.

Der Zusammenhang, den man selten sieht

Ein Skript wird über ein Ereignis an ein Formular gebunden: beim Laden, beim Speichern, beim Ändern eines Felds, beim Aufklappen eines Registers etc.. Diese Bindung steht in der Formulardefinition, nicht in der Skriptdatei.

Wer nur die Dateien betrachtet sieht deshalb nicht welche Funktion wo aufgerufen wird. Für eine Übernahme ist das aber die eine Information die zählt: Welches Formular ruft beim Laden welche Funktion auf?

Praktisches Vorgehen

Solche Bestände geht man am besten immer in derselben Reihenfolge durch: zuerst die sicherheitsrelevanten Muster, dann die abgelösten Schnittstellen, zuletzt die Aufräumthemen.

Die abgelösten Schnittstellen sollte man nicht auf einmal angehen. Sinnvoller ist sie mitzunehmen wenn das jeweilige Formular ohnehin das nächste Mal umgebaut wird. Wichtig ist nur den Bestand zu kennen, damit die Entscheidung bewusst fällt.