Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Sharepoint und der eigensinnige XSS - Filter (Bericht)

Ein Teil unse­rer Kernkompetenzen im Umgang mit Sharepoint, ist die Migration von Altsystemen zu Sharepoint. Ein aktu­el­les Projekt stellte uns vor die Herausforderung, Inhalte, Stylevorgaben und Meta-Daten mit­tels XML Import aus einem bestehen­den Content Management System 1:1 nach SharePoint zu über­neh­men. Besonders pro­ble­ma­tisch war dabei der Fakt, dass sich inner­halb der Daten Parameter für die Businesslogik ver­steck­ten. Diese Logik musste in SharePoint zum Teil nach­ge­baut und beim Import berück­sich­tigt wer­den.

Eine Teilaufgabe des Imports bestand in der Übernahme der eigent­li­chen Inhalte der Seiten. Diese lagen als bar­rie­re­freies HTML vor und muss­ten des­halb ori­gi­nal so in die SharePoint Seite impor­tiert wer­den.

Meine Aufgabe bestand nun darin, den ori­gi­na­len HTML Inhalt der zu migrie­ren­den Seite in eine Sharepoint Seite zu impor­tie­ren. Möglichst soll­ten die Optik  (Styles, Bilder, etc.) sowie der Inhalt (inkl. Links, Tabellen etc.) unan­ge­tas­tet blei­ben.

Sharepoint bie­tet dem geneig­ten Entwickler mit sei­ner API reich­lich Werkzeug um diese Aufgabe zu bewäl­ti­gen. So kann eine Seite ohne Probleme mit fol­gen­den Programmcode ange­legt wer­den:

PublishingWeb currPublishingWeb = PublishingWeb.GetPublishingWeb(webContext);
PublishingPageCollection pages = currPublishingWeb.GetPublishingPages();
PublishingPage currentPage = pages.Add(pageFileName, layout);

Auf diese Weise ist eine Publishing Page schnell erstellt. Soll diese jetzt auch noch mit Inhalt ver­se­hen wer­den, wird das SPField, das für den Inhalt einer PublishingPage zustän­dig ist, benö­tigt.

Das SPField für Inhalte ist das PublishingPageContent Field, das über die FieldId Klasse ver­wen­det wer­den kann.

SPListItem newFileItem = newFile.Item;
newFileItem[FieldId.PublishingPageContent] = htmlContent;
newFileItem.Update();

Bis hier wurde alles ord­nungs­ge­mäß von Sharepoint aus­ge­führt. Die Seite wurde ange­legt und der Inhalt wurde auch gesetzt. Beim nähe­ren Betrachten der neu Erstellten Seite wurde ich jedoch miss­trau­isch:

  • Aus ein­fa­chen Links wie zum Beispiel <a href="../../beispiel.htm">Beispiel</a> wurde <a>Beispiel</a>.
  • Kommentare wie <!– com­ment –> wur­den ein­fach gelöscht
  • Auch Attributen wie bei­spiels­weise Ids oder Klassen(class)  in Divs wur­den gelöscht
  • Anführungszeichen wur­den ent­fernt – <div style="test"/> wird zu <div style=test/>

Durch die­ses Verhalten wur­den die impor­tier­ten Seiten "wert­los" für mich. Alle dar­auf fol­gen­den Versuche den Inhalt in die Seite zu schrei­ben schlug fehl. Versucht habe ich fol­gende Wege:

  1. Den Inhalt zu enco­die­ren und anschlie­ßend wie­der zu deko­die­ren. Prinzipiell hätte diese Variante funk­tio­niert, jedoch hätte ich die Render Methoden des Sharepoint RichtTextEditors über­schrei­ben müs­sen. Das hätte wie­derum den Nachteil das die Editor Funktion nicht mehr ord­nungs­ge­mäß arbei­tet. Der aus­schla­ge­ge­bende Faktor diese Variante nicht zu ver­wen­den war jedoch die feh­lende Möglichkeit der Indexierung des Inhaltes, da bei die­ser Variante der Inhalt in Base 64 – codier­ter Form in der Sharepoint Datenbank gespei­chert wor­den wäre und so durch die Suche nicht mehr inde­xiert wer­den kann.
  2. In einem zwei­ten Versuch, lud ich mir den Stream der neu ange­leg­ten Seite (auf File – Ebene) und ersetzte den von Sharepoint beschä­dig­ten HTML Inhalt durch den ori­gi­na­len. Leider wurde die­ser Inhalt beim Speichern der Datei erneut beschä­digt.
  3. Einen drit­ten Versuch ersparte ich mir, da die­ser die Modifizierung der Sharepoint Datenbank vor­ge­se­hen hätte. Ich glaube der Erfolg hätte sich auch in Grenzen gehal­ten?!

Da ich das Problem gerne ohne "Dirty Hacks" lösen wollte, ent­schied ich mich eine Supportanfrage bei Microsoft zu stel­len. Dazu sei erwähnt, dass die Anfragen über den Microsoft Support sehr schnell und kom­pe­tent beant­wor­tet und abge­wi­ckelt wer­den.  Ich sollte meine Antwort von Microsoft bekom­men; Leider hieß diese "By design" oder kurz auf deutsch: abge­wie­sen.

Die Begründung: Mirosoft Sharepoint nutzt einen soge­nann­ten XSS (Cross side scrip­ting) Protection Mechanismus. Dieser sollte ver­hin­dern das schäd­li­cher Inhalte (Code) in Sharepoint ein­ge­pflegt wer­den kann.

Davon betrof­fen ist aller­dings auch das HTML Texteingabe Control. Beispielsweise würde die­ser Programm – Code wie folgt abge­än­dert:

original:       Das ist ein gutes <SCRIPT>void:alert("hello world")</SCRIPT> Script
verfälscht:     Das ist ein gutes Script

Auch "<" oder ">" Zeichen wür­den wie folgt abge­än­dert: &gt – &lt. Ich emp­finde die­ses Verhalten als voll­kom­men rich­tig und auch nach­voll­zieh­bar, wenn es dabei blei­ben würde. Es stellte sich her­raus dass die­ser XSS Filter auch für die Kürzung mei­ner HTML Inhalte zustän­dig war. Microsoft selbst kann sich nicht erklä­ren warum die­ser Filter solch dras­ti­sche Änderungen am HTML Quellcode vor­nimmt. Man riet mir von Seiten Microsoft ernst­haft  ent­we­der ein 3rd Party AddOn als Ersatz für den RichTextEditor ein­zu­set­zen oder aber die Daten nicht inner­halb Sharepoints zu hal­ten, son­dern extern. Keiner der bei­den ange­bo­te­te­nen Lösungen erschien mir für unser Projekt auch nur ansatz­weise logisch bezie­hungs­weise umsetz­bar.

Lösung:

Um die Inhalte den­noch wie gefor­dert 1:1 impor­tie­ren zu kön­nen, musste nun ein Workaround gefun­den wer­den. Dazu bot sich eine Codierung der beim Import bean­stan­de­ten HTML-Tags an. Nach der erfolg­rei­chen Integration der Methoden in unse­ren Import kön­nen nun alle Inhalte wie gefor­dert über­nom­men wer­den.

Related Posts

Gerade mei­nen Bericht über den #Sharepoint XSS Filter und #HTML Encoding fer­tig gestellt. Unter #Communardo #Techblog http://bit.ly/VSTfm
This com­ment was ori­gi­nally pos­ted on Twitter

Genau das glei­che Problem hier. Wie hast du es lösen kön­nen? Was meinst du mit "Codierung"? Danke und Gruss

Comments are closed.

Pin It on Pinterest