Aus Anwendersicht gibt es eine einfache, aber nicht unbedingt zweckmäßige Schutzmaßnahme: Wenn man Javascript und Skriptsprachen/Flash im Browser deaktiviert, ist klassisches XSS via Script natürlich nicht mehr möglich. Allerdings schränkt man damit erheblich das Surfvergnügen und die Nutzbarkeit vieler Webseiten ein, so dass das Abschalten von Javascript nicht generell empfohlen werden kann.
Tipp: Sie können Skripte unter Firefox bequem mit dem kostenlosen Addon Noscript steuern. Damit können Sie für jede besuchte Website exakt festlegen, welche Skripte gestartet und welche blockiert werden sollen.
In Mailclients kann man zudem die HTML-Funktion deaktivieren, wenn man mehr Sicherheit wünscht.
Was machen Administratoren und Webseitenbesitzer?
Aus dem oben Gesagten wird klar: Der Schutz gegen XSS ist in erster Linie die Aufgabe der Webseiten-Besitzer. Das A und O zum Schutz gegen XSS ist zudem schnell formuliert: Alle Eingaben müssen auf ihre Plausibilität geprüft werden: Stimmt die Länge der Eingaben, ist es der richtige Datentyp (wenn beispielsweise nur die Eingabe einer Zahl erwartet wird, sollte keine Zeichenkette in der Variable stehen) und – besonders wichtig - enthält die Eingabe Sonderzeichen beziehungsweise HTML- oder Scriptcode?
In der weit verbreiteten Skriptsprache PHP können HTML-Tags beispielsweise mit dem Befehl strip_tags() ausgefiltert werden. Dabei lassen sich gegebenenfalls einzelne Tags, die sinnvoll erscheinen, explizit zulassen. Wer in einem Forum umfangreichere Formatierungsmöglichkeiten für Eingaben zulassen möchte, kann als Alternative zu HTML eine spezielle Auszeichnungssprache wie BBCode einsetzen. Bei BBCode kann ein Forumsteilnehmer seine Texte ähnliche wie bei HTML formatieren, also zum Beispiel fett hervorheben, URLs hinterlegen oder die Schriftgröße variieren. Nur erfolgt das eben nicht mit echtem HTML (das durch <> markiert wird), sondern mit BBCode-Zeichen, die zwischen [] stehen. Die Eingaben werden nach dem Absenden von eventuell eingefügten HTML bereinigt, danach werden die ungefährlichen BBCode-Elemente in HTML umgesetzt.
Sonderzeichen wie ' und “ werden maskiert, indem ihnen ein Backslash vorangestellt wird: \. Dafür stellen Sprachen wie PHP fertige Konfigurationsmöglichkeiten bereit: magic_quotes_gpc. Man kann das aber auch händisch mit Befehlen wie addshlashes() machen. Filtert man Eingaben mit Befehlen wie htmlspecialchars() oder htmlentities(), so werden radikal alle HTML-Sonderzeichen in den entsprechenden Entity-Code umgewandelt und können keinen Schaden mehr anrichten: aus einem ' wird dann '; und aus “ wird ". Bei dieser radikalen Lösung bekommt man zwar maximale Sicherheit, allerdings um den Preis, das keine Formatierungen mehr möglich sind.
Probieren Sie diesen Schutzmechanismus einfach mit unserem einfachen Formular aus. Ändern Sie die Zeile, in der $_eingabe = $_POST['eingabe']; steht in: $_eingabe = htmlentities($_POST['eingabe']);
Speichern Sie das Skript erneut und rufen Sie die Website dann erneut im Browser auf. Geben Sie erneut das obige kurze Javascript ein. Jetzt sollte kein Popup mehr erscheinen.
Alternative Schutzmechanismen sind Whitelist- und Blacklist-Überprüfungen. Bei ersteren wird festgelegt, welche Eingaben in einem Formular generell erlaubt sind: HTML Purifier ist eine solche Hilfsanwendung. Eingaben, die nicht explizit erlaubt sind, sind nicht möglich. Blacklists funktionieren genau umgekehrt: Hier wird festgelegt, was generell untersagt ist. Das setzt aber voraus, dass sich der Programmierer über alle potenziellen Angriffsmöglichkeiten und Sicherheitslücken bewusst ist und seine Blacklists immer umgehend an neue Bedrohungsszenarien anpasst. Somit sind Blacklists aufwändiger zu warten als Whitelists und letztendlich anfälliger für bis dato unbekannte Schwachstellen.
Für Programmiersprachen wie PHP gibt es Projekte, die versuchen, die Sprache insgesamt sicherer zu machen. Suhosin ist so ein Projekt, das PHP-Anwendungen und den PHP-Kern schützt und beispielsweise Mechanismen bereit stellt, um Session- und Cookie-Daten vor Diebstahl via XSS-Angriffen zu schützen.
Lesen Sie auf der nächsten Seite:
Vorherige Seite
Seite 5 von 6
Nächste Seite


14.03.11
Was ist denn das für ein Quatsch ?
Warum sollte ich in ein Formular jetzt irgendeinen Scriptcode ( der im übrigen auf Ihrer Webseite nicht mehr angezeigt wird - Geheimhaltung ? )
eingeben um ein Popup-Fenster zu erzeugen.
Soll das ein Beweis für mögliche Selbstschädigung sein ?
Zitat : "...Code, der von einem Angreifer untergeschoben wurde..."
Ich sehe in Ihrem Beitrag weder einen Angreifer noch wie er Code unterschieben könnte. Da müßten Sie schon etwas konkreter und verständlicher formulieren !
Antwort schreiben
13.11.11
Es wird andauern versucht mit Hilfe von Setzen von Parametern über die URL Werbung in das Forum einzufügen (was aber zum Glück nicht funktioniert).
Nun ist aber auf der Website eine Übersicht, die anzeigt wer auf welchen Seiten war. Es ist also ziemlich nervig, dass dort immer alles zugespammt wird...
Was kann man im einfachsten Fall dagegen tun ohne die Funktion der Page einzuschränken?
Ich habe mit utrace die IPs zurückverfolgt. Sie kommen alle aus Lettland.
Ein IP Bann bringt aber nichts, da die IPs wechseln.
Antwort schreiben
13.11.11
Wende dich an deinen Hoster. So er Ahnung von seinem Geschäft hat, sollte er ein IPS/IDS zwischen schalten können.
Antwort schreiben
13.11.11
Ich denke nicht, dass das von einem kostenlosen Hoster, wie bplaced in meinem fall, gewährleistet wird oder liege ich da falsch?
Auf jeden Fall schon einmal danke für den Vorschlag.
Antwort schreiben
14.11.11
...mei, woher sollen wir das wissen, wenn du das schon nicht weißt. Erzähle uns doch einfach mal, was du für Möglichkeiten und Rechte auf dem Server hast. Auf Ebene der Webanwendung lassen sich solche Angriffe eh nicht eindämmen - maximal die optischen Auswirkungen kaschieren (z.B. durch Verwerfen von DB-Einträgen mit ungültigen Parametern/Übergabewerten). Nur ist das nicht ganz clever, wenn man nicht permanent die Serverlogs auf merkwürdige Einträge kontrolliert.
Antwort schreiben
14.11.11
Antwort schreiben