heise online Logo
Anmelden
Menü
  • c't – Magazin für Computertechnik
  • iX – Magazin für professionelle Informationstechnik
  • MIT Technology Review – Das Magazin für Innovation von Heise
  • c't Fotografie - Das Magazin rund ums digitale Bild
  • Mac & i – Nachrichten, Tests, Tipps und Meinungen rund um Apple
  • Make – Kreativ mit Technik
  • Alle Magazine im Browser lesen
IT News
  • Newsticker
  • heise Developer
  • heise Netze
  • heise Open Source
  • heise Security
Online-Magazine
  • heise+
  • Telepolis
  • heise Autos
  • TechStage
  • tipps+tricks
Services
  • Stellenmarkt heise Jobs
  • Weiterbildung
  • heise Download
  • Preisvergleich
  • Whitepaper/Webcasts
  • DSL-Vergleich
  • Netzwerk-Tools
  • Spielen bei Heise
  • Loseblattwerke
  • iMonitor
  • IT-Markt
Heise Medien
  • heise Shop
  • Abo
  • Veranstaltungen
  • Arbeiten bei Heise
  • Mediadaten
  • Presse
Anzeige Go! Schule morgen
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten
heise Security Logo
  • News
    • Archiv
    • 7-Tage-News
  • Hintergrund
  • heise Security Pro
    • FAQs zu heise Security Pro
  • Events
  • Kontakt
  1. Security
  2. Hintergrund
  3. Sicherheit von Webanwendungen

Sicherheit von Webanwendungen

Hintergrund 25.01.2007 12:33 Uhr Christiane Rütten, Tobias Glemser
Inhaltsverzeichnis
  1. Sicherheit von Webanwendungen
  2. Remote Code Execution
  3. Weiße Weste
  4. Das PHP-Dilemma
  5. Die wichtigsten Sicherheitsoptionen in der php.ini
  6. Auf einer Seite lesen

Besonders anfällig für Angriffe auf Webserver sind mit PHP oder anderen Skriptsprachen geschriebene Webanwendungen. Wer jedoch die gängigen Sicherheitslücken und Angriffstechniken kennt, kann den Attacken die Stirn bieten.

Unterthema: Das PHP-Dilemma
Unterthema: Die wichtigsten Sicherheitsoptionen in der php.ini

Die Sicherheit von Webanwendungen geht keineswegs nur die Betreiber von Online-Shops und Banking-Portalen an. Vielmehr sind zunehmend auch kleinere oder privat betriebene Websites das Ziel böswilliger Angreifer aus dem Internet. Nicht unbedingt, weil es da Geld oder geheime Daten zu holen gäbe, sondern um den gekaperten Server für eigene Zwecke zu missbrauchen. Dort kann man dann raubkopierte Software archivieren und tauschen, verteilte Denial-of-Service-Angriffe vorbereiten oder Spam-Mails verschicken. Oder der Angreifer manipuliert die Webseiten, um Besucher mit Dialern oder Spyware zu infizieren.

Wer seinen Server selbst administriert, also beispielsweise einen "Root-Server" betreibt, muss sich natürlich darum kümmern, diesen aktuell zu halten und auftretende Sicherheitslücken zu schließen. Doch auch wer nur ein bisschen Webspace angemietet hat, um seinen Freunden die selbst geschossenen Fotos zu zeigen, ist möglicherweise angreifbar. Ob Bildgalerie, Blog oder Gästebuch – jegliche Art von dynamischem Inhalt, sei er in PHP, Perl, Ruby oder sonst einer Sprache programmiert, ist ein potenzielles Einfallstor.

Cross Site Scripting

Die verbreitetste Angriffsform ist das sogenannte Cross Site Scripting (XSS). Dabei versucht ein Angreifer, die Webanwendung so zu manipulieren, dass sie schädlichen Skriptcode in die beim Besucher angezeigte Seite einbettet. Der Browser verarbeitet dann den eingeschmuggelten Code, als wäre es ein legitimer Inhalt der Webseite – mit den entsprechenden Sicherheitsfreigaben. Mit dem eingebetteten Schadcode kann ein Angreifer dann beispielsweise falsche Informationen als Inhalte der angegriffenen Webseite verkaufen, um Passwörter oder Kontodaten zu erbeuten (Phishing).

Die fehlerhafte Webapplikation bettet den Schadcode aus der URL in ihre Ausgabe ein und "reflektiert" ihn zum Anwender zurück.

Man unterscheidet drei Haupttypen von XSS, und zwar je nachdem, auf welchem Weg der Schadcode in die im Browser angezeigte Webseite gelangt. Am häufigsten ist das sogenannte reflektierte XSS anzutreffen. Hierzu muss der Angreifer das Opfer dazu bringen, eine präparierte URL anzuklicken. In Variablenparametern dieser URL versteckt er dabei Code, den die fehlerhafte Anwendung auf Serverseite übernimmt und als vermeintlichen Usernamen, E-Mail-Adresse oder Suchausdruck in die Webseite einbettet. Fast alle von der Hacker-Gruppe Electrical Ordered Freedom auf der Website Phishmarkt gezeigten Beispiele bei Webpräsenzen von Banken und Institutionen sind aktuell und von diesem Typ [4].

Ebenfalls weit verbreitet ist das persistente oder beständige XSS. Ähnlich dem reflektierten XSS spielt der Server den Schadcode aus der URL als Webinhalt an den Browser zurück, doch diesmal mit einem Zwischenstopp in der Serverdatenbank. Dadurch liefert der Server den Schadcode unter Umständen auch an Anwender aus, die nicht auf einen manipulierten Link geklickt haben – man denke etwa an Forenbeiträge mit eingebettetem JavaScript-Code. Bei diesem Typ ist es in der Regel der Angreifer, der einmalig auf einen manipulierten Link klickt, um den Schadcode auf dem Server abzuladen.

Landet der Schadcode zunächst einmal in der Serverdatenbank, müssen Opfer gar nicht erst auf einen manipulierten Link klicken.

Bei reflektiertem und persistentem XSS läuft der fehlerhafte Programmcode, der den Schadcode letztlich einbettet, auf dem Server. Wenn sich im Gegensatz dazu der gesamte Angriff vom Klicken einer manipulierten URL bis zum Einbetten des Schadcodes in die Webseite auf dem Rechner des Anwenders abspielt, spricht man von lokalem XSS. Dieser dritte Haupttyp tritt insbesondere bei Web-2.0-Anwendungen auf, die einen erheblichen Teil der Applikationsfunktionen als Java- oder JavaScript-Code in den Browser des Anwenders verlagern.

Besonders bei Web-2.0-Anwendungen kann sich der gesamte Angriff auf dem Nutzerrechner abspielen. Der Server liefert nur das fehlerhafte Skript an den Browser, aber nicht den Schadcode.

Das baumartige Document Object Model (DOM), das im Webbrowser die komplette Webseite repräsentiert, spielt dabei eine besondere Rolle, daher auch die Bezeichnung "DOM-basiertes XSS". Über Zugriffe auf den DOM-Baum kann eine Applikation unter anderem dynamische Änderungen an der dargestellten Webseite vornehmen, etwa für interaktive Webanwendungen. Bei DOM-basiertem XSS kopiert ein fehlerhaftes browserseitiges Anwendungsskript den Schadcode direkt aus der URL per DOM-Zugriff in die angezeigte Webseite. Im Prinzip entfällt dabei der Umweg über den Server, der lediglich HTML und den fehlerhaften Applikationscode übermittelt.

Vorherige 1 2 3 4 5 Nächste

Forum bei heise online: Serversicherheit

Teile diesen Beitrag
https://heise.de/-270870 Drucken
Dienste
  • Security Consulter
  • Netzwerkcheck
  • Anti-Virus
  • Emailcheck
  • Krypto-Kampagne
Alerts! alle Alert-Meldungen

Jenkins-Plug-ins

IBM Spectrum Protect

Atlassian Jira

Zimbra / unrar

Anzeige
  • File Sharing im Job ohne Sicherheitsrisiko
  • Wie IT zu nachhaltigem Wirtschaften beitragen kann
  • Kundenservice mit künstlicher Intelligenz
  • Join the fundrace. Support open source!
Artikel

Utimaco, der Krypto-Miner und ein Disclosure-Desaster​

Auch Anbieter von Hochsicherheitslösungen sind vor Securityproblemen nicht gefeit. Man sollte sich vorbereiten, bevor man davon erfährt, sagt Jürgen Schmidt.

12 Kommentare
Aufmacher: Kommentar Welt-Passwort-Gedenktag

Kommentar: "Willkommen zum Welt-Passwort-Gedenktag"

Welt-Passwort-Tag: Jürgen Schmidt, Senior Fellow Security bei Heise, hat einen Kommentar aus einer Zukunft ohne Passwörter geschickt.

230 Kommentare
  • Passwortsicherheit – Alles, was Sie wissen müssen
  • Welt-Passwort-Tag: Zugangssicherheit im Fokus

Der Patch-Alptraum: Wenn schnell nicht schnell genug ist

Neben den überbewerteten Zero-Day-Lücken gibt es eine weniger bekannte Bedrohung durch "Beinahe-Zero-Days". Die sind weitverbreitet und brandgefährlich.

95 Kommentare

Neueste Forenbeiträge

  1. Re: Desinfect Download - wo ?
    Hallo, ich finde auf die schnelle nicht mehr den betreffenden Beitrag zu der aktuellen bzw. Version des Vorjahres. Es wurde eine Auswahl…

    Forum:  Desinfect

    maal1 hat keinen Avatar
    von maal1; vor 7 Stunden
  2. Permanentes Einloggen bei Vivaldi
    Hallo, irgendwie scheint der Passwortmanager nicht zu reagieren: schalte ich Vivaldi ein und aus muss ich dort wo ich mich unmittelbar zuvor…

    Forum:  Google wappnet Chrome gegen Spectre und 52 weitere Sicherheitslücken

    heidernein hat keinen Avatar
    von heidernein; vor 18 Stunden
  3. ESET-Lizenz "verloren"
    Moin, nach einiger Zeit habe ich meinen Stick mal wieder gestartet. Update von -p2 auf -p3 wurde installiert. WLAN-Passwort verloren, neu…

    Forum:  Desinfect

    GuinnessTrinker hat keinen Avatar
    von GuinnessTrinker; vor 22 Stunden
News und Artikel
  • News
  • 7-Tage-News
  • News-Archiv
  • Hintergrund-Artikel
  • Alert-Meldungen
Service
  • Newsletter
  • Tools
  • Foren
  • RSS
  • mobil
Dienste
  • Security Consulter
  • Netzwerkcheck
  • Anti-Virus
  • Emailcheck
  • Krypto-Kampagne
  • Datenschutz
  • Cookies & Tracking
  • Impressum
  • Kontakt
  • Barriere melden
  • Mediadaten
  • Verträge kündigen
  • 245470
  • Content Management by InterRed
  • Hosted by Plus.line
  • Copyright © 2022 Heise Medien