30.2 XSS und AJAX 
Doch auch für reine JavaScript-Programmierer ist XSS eine ernst zu nehmende Gefahr. Erinnern Sie sich an Kapitel 18 und die dort vorgestellte AJAX-Problematik, dass Bookmarks nicht so ohne Weiteres möglich sind? Nun, ein möglicher Umweg besteht ja darin, spezielle URLs anzubieten, die als Textmarke oder Query-String Informationen erhalten, die den Seiteninhalt eindeutig beschrieben.
Leider müssen Sie dabei höllisch aufpassen, um nicht in das XSS-Loch zu fallen. Kehren wir zum Beispiel mit der Suche zurück. Stellen Sie sich vor, Sie haben eine AJAX-Suche geschrieben: Ohne dass Seiten neu geladen werden müssen, erscheinen die Suchergebnisse wie von Zauberhand. Allerdings bieten Sie auch noch Permalinks (permanente Links) an, damit für die Ergebnisseite ein Bookmark abgelegt werden kann:
<a href="http://site.xy/suche.php?begriff=XXX">Permalink</a>
Auf der Seite selbst befindet sich dann folgender JavaScript-Code:
<html>
<head>
<title>XSS</title>
<script type="text/javascript">
window.onload = function() {
if (location.search.length > 1) {
var p = document.getElementById("ausgabe");
p.innerHTML = "Sie suchten nach " +
unescape(location.search.substring(1));
}
};
</script>
</head>
<body>
<h1>XSS</h1>
<p id="ausgabe"></p>
</body>
</html>
Sie ahnen mittlerweile, woran dieser Code-Ansatz scheitert: Die URL http://site.xy/suche.html?<Markup...> führt JavaScript-Code aus, wie Abbildung 30.3 noch einmal verdeutlicht.
Hier klicken, um das Bild zu Vergrößern
Abbildung 30.3 Beachten Sie URL und Wirkung!
Besonders gefährlich ist die JavaScript-Funktion eval(), die bekanntlich einen String mit JavaScript-Code ausführt. Wenn dieser String von außen kommt, also beispielsweise aus der URL, haben Sie mit hoher Wahrscheinlichkeit eine schwere Sicherheitslücke im System. Seien Sie also bei externen Daten äußerst vorsichtig. Und versuchen Sie erst gar nicht, die zuvor gezeigten Angriffe herauszufiltern, also etwa nach <script zu suchen. Ein Angreifer könnte ja beispielsweise <style>body {back-ground: url(javascript:boeserCode();) }</style> eingeben2 oder <img src="" onerror="boeserCode();" /> oder ...
PHP-spezifische Hinweise zum Thema Web-Security erhalten Sie unter anderem beim PHP Security Consortium unter http://www.phpsec.org. Allgemeine, sprachunabhängige Informationen gibt es beim Open Web Application Security Project unter http://www.owasp.org/.
1 Aus der Debatte, ob man nicht doch lieber Cracker sagen sollte und ob jemand, der eine Sicherheitslücke findet, automatisch ein Cracker oder eben doch ein Hacker oder einfach nur jemand mit zu viel Zeit ist, möchte ich mich an dieser Stelle heraushalten.
... was mittlerweile immerhin schon von einigen Browsern nicht mehr interpretiert wird.
|
