Cross-Site-Scripting Grundlagen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(18 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 11: Zeile 11:
 
*Dort kommt es zur manipulieren serverseitige Skripte zur Benutzeranmeldung.
 
*Dort kommt es zur manipulieren serverseitige Skripte zur Benutzeranmeldung.
 
=Es gibt 3 Arten des Cross-Site-Scripting/XSS=
 
=Es gibt 3 Arten des Cross-Site-Scripting/XSS=
−
==Reflektiertes Cross-Site-Scripting/XSS==
+
*[[Reflektiertes Cross-Site-Scripting/XSS]]
−
*Schädliches Skript an den Webserver gesendet durch:
+
*[[Persistentes Cross-Site-Scripting/XSS]]
−
**Aufruf einer manipulierten URL
+
*[[DOM-basiertes Cross-Site-Scripting/XSS]]
−
**Absenden eines präparierten Formulars wird das
 
−
*Webserver gibt Datenohne Überprüfung an den Client zurück
 
−
*Schadcode wird nicht auf dem Server gespeichert
 
−
*Beliebte Angriffsziele sind dynamische Websites
 
  
−
Beispiel: Bei dieser XSS-Variante bringt der Angreifer sein Skript in einem präparierten Link unter. Im Anschluss versucht er den Link – bevorzugt über E-Mails – weiterzuleiten. Der enthaltene Schadcode wird nur ausgelöst, wenn der Benutzer den erhaltenen Link aufruft. Tut er dies, wird ihm beispielsweise ein imitierter Anmeldebildschirm seines Online-Bankings präsentiert. Anstatt die eingegebenen Daten an den Webserver der Bank zu senden, sorgt das Skript jedoch für eine Umleitung auf die Adresse, die der Angreifer zuvor bestimmt hat.
 
−
 
−
==Persistentes Cross-DockerSite-Scripting/XSS==
 
−
*Schädlichen Skripte auf dem Webserver gespeichert
 
−
*Bei jedem Aufruf durch einen Client ausgeliefert.
 
−
*Ziele sind Rechner die Benutzerdaten ohne Überprüfung serverseitig speichern
 
−
*anfällig für diese Scripting-Art sind Blogs und Foren.
 
−
==DOM-basiertes Cross-Site-Scripting/XSS==
 
−
*Angriffsart wird auch lokales XSS genannt.
 
−
*Schadcode wird durch eine Lücke in einem clientseitigen Skript ohne Überprüfung ausgeführt.
 
−
*Webserver nicht an dem Prozess beteiligt.
 
−
*Statische Websites, welche die jeweilige Skript-Sprache unterstützen, sind gefährdet.
 
 
=Schutzmaßnahmen für Internet-User=
 
=Schutzmaßnahmen für Internet-User=
−
Die einfachste Möglichkeit, clientseitiges Cross-Site-Scripting zu verhindern, ist das Ausschalten der JavaScript-Unterstützung im Browser. Ist dieses sogenannte Active Scripting deaktiviert, haben DOM-basierte XSS, die auf JavaScript abzielen, keine Wirkung, da die schädliche Anwendung erst gar nicht gestartet wird. Für einige Browser existieren außerdem Add-ons, die Sie vor XSS-Angriffen schützen können. So gibt es für Mozilla Firefox beispielsweise die Erweiterung NoScript. In den Standardeinstellungen sind alle aktiven Inhalte von Websites, wie z. B. JavaScript, Java-Applets, Adobe Flash oder Microsoft Silverlight, automatisch gesperrt. Auf Wunsch können Sie die Bloenschutzbeauftragter rlpenschutzbeauftragter rlpenschutzbeauftragter rlpckierung temporär aufheben oder die jeweilige Seite auf die Whitelist setzen, wenn Sie sich sicher sind, dass jene zu 100 Prozent vertrauenswürdig ist. Ein letzter Tipp, den Sie nicht nur in Zusammenhang mit den Gefahren des Cross-Site-Scriptings unbedingt beherzigen sollten: Fremddaten wie Links sollten Sie stets skeptisch gegenüber sein und vor der Verwendung gründlich unter die Lupe nehmen.
+
*Ausschalten der JavaScript-Unterstützung im Browser.  
−
 
+
*Es gibt Add-ons, die Sie vor XSS-Angriffen schützen können.  
−
Das können Sie als Website-Betreiber gegen XSS-Attacken unternehmen
+
*Beispiel Mozilla Firefox Erweiterung NoScript.  
−
Damit Ihre Webanwendungen keine Basis für XSS-Angriffe bieten, müssen Sie zunächst alle eingehenden Eingabewerte als unsicher betrachten. Bevor diese also vom Webserver in Empfang genommen werden, sollten sie entsprechend geprüft werden. Die sicherste Methode ist hier wieder – wie beim Browser-Add-on NoScript für Clients – das Anlegen einer Whitelist. Sofern es die Kapazitäten erlauben, die Eingaben auf Ihrer Website zu scannen und nur vertrauenswürdige Inhalte zuzulassen, erzeugen Sie auf diese Weise einen exzellenten Schutz gegen Cross-Site-Scripting.
+
*Man kann Whitelisten setzen wenn diese sicher sind
−
 
+
=Maßnahme der Website-Betreiber gegen XSS-Attacken=
−
Zusätzlich zu den Eingabedaten sollte allerdings auch die Datenausgabe abgesichert werden. Hierzu ist es notwendig, dass die problematischen HTML-Metazeichen durch entsprechende Zeichenreferenzen ersetzt werden; dadurch werden die Metazeichen als normale Zeichen gewertet und potenziell eingeschleuste Skripte können nicht gestartet werden. Die meisten Programmier- und Skriptsprachen wie Perl, JavaScript oder PHP besitzen zu diesem Zweck bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung, die Sie bedenkenlos verwenden können.
+
*Alle eingehenden Eingabewerte als unsicher betrachten.  
−
 
+
*Das Eingabefeld sollte nur als String und nicht als Code Block interpretiert werden.
−
Einfache XSS-Attacken wehren Sie außerdem durch den Einsatz von Web-Application-Firewalls ab.
+
*Alle Daten sollten entsprechend geprüft werden.  
 +
*Auch hier kann man Whitelisten anlegen
 +
*Man kann Eingaben auf Ihrer Website zu scannen und nur vertrauenswürdige Inhalte zuzulassen,
 +
*Exzellenten Schutz gegen Cross-Site-Scripting.
 +
*Vorgeschaltete Webprotection(z.B. Sophos Webprotection)
 +
*Datenausgabe sollte auch abgesichert werden
 +
*Problematischen HTML-Metazeichen durch Zeichenreferenzen ersetzen
 +
*Metazeichen werden normale Zeichen gewertet
 +
*potenzielle eingeschleuste Skripte können nicht gestartet werden.
 +
*Die meisten Programmiersprachen können dies.
  
−
Cross-Site-Scripting bildet oftmals nur die Vorstufe für schwerwiegendere Angriffe, die Sie mit einem umfassenden Schutz der ein- und ausgehenden Dateneingabe Ihres Webservers also schon in der Entstehung vereiteln können.
+
=Quelle=
 +
*https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-xss-bzw-cross-site-scripting/
 +
*https://raidboxes.io/blog/security/cross-site-scripting/

Aktuelle Version vom 4. September 2024, 12:40 Uhr

XSS/Cross-Site-Scripting

  • Ausnutzen von Sicherheitslücken in Webanwendungen
  • Schädliche Skripte werden dabei in einen vertrauenswürdigen Kontext eingespeist
  • System der Nutzer kann angeriffen werden
  • Meist in JavaScript und/oder Quelltextdatei programmiert werden.
  • harmlosen Varianten beispielsweise aufpoppende Fenster
  • Worst Case - Zugriff auf vertrauliche Informationen

Gefahr

  • Gefahr besteht wenn Benutzerdaten ohne Überprüfung an den Webbrowser weiterleitet werden
  • Über XSS-Löcher gelangen die schädlichen Skripte zu den betroffenen Clients.
  • Dort kommt es zur manipulieren serverseitige Skripte zur Benutzeranmeldung.

Es gibt 3 Arten des Cross-Site-Scripting/XSS

Schutzmaßnahmen für Internet-User

  • Ausschalten der JavaScript-Unterstützung im Browser.
  • Es gibt Add-ons, die Sie vor XSS-Angriffen schützen können.
  • Beispiel Mozilla Firefox Erweiterung NoScript.
  • Man kann Whitelisten setzen wenn diese sicher sind

Maßnahme der Website-Betreiber gegen XSS-Attacken

  • Alle eingehenden Eingabewerte als unsicher betrachten.
  • Das Eingabefeld sollte nur als String und nicht als Code Block interpretiert werden.
  • Alle Daten sollten entsprechend geprüft werden.
  • Auch hier kann man Whitelisten anlegen
  • Man kann Eingaben auf Ihrer Website zu scannen und nur vertrauenswürdige Inhalte zuzulassen,
  • Exzellenten Schutz gegen Cross-Site-Scripting.
  • Vorgeschaltete Webprotection(z.B. Sophos Webprotection)
  • Datenausgabe sollte auch abgesichert werden
  • Problematischen HTML-Metazeichen durch Zeichenreferenzen ersetzen
  • Metazeichen werden normale Zeichen gewertet
  • potenzielle eingeschleuste Skripte können nicht gestartet werden.
  • Die meisten Programmiersprachen können dies.

Quelle

Abgerufen von „http://wiki.ixheim.de/index.php?title=Cross-Site-Scripting_Grundlagen&oldid=56021“