Diskussion:Cross-Site-Scripting

Was haltet ihr davon die Titel Cross-Site Authentication, Cross-Site Cooking, Cross-Site Tracing und Cross-Site Request Forgery, die ja alle bloß Formen des Cross-Site Scripting sind, in diesem Artikel zusammenzuführen? Andernfalls sollten sie weiter ausgebaut werden, um dem Informationsgehalt eines eigenständigen Artikels gerecht zu werden. 89.166.154.153 21:11, 18. Sep. 2007 (CEST)Beantworten

Cross-Site Request Forgery hat absolut gar nichts mit Cross-Site Scripting zu tun! XSS macht CSRF nur einfacher ausnutzbar. Unter Cross-Site Request Forgery ist der Untersched bereits sehr gut erklärt. Der Begriff CSRF ist genau wie XSS aus heutiger Sicht etws unglücklich, da damit unterschiedliche Angriffe/Schwachstellen bezeichnet werden. Leider haben sich diese Begriffe durchgesetzt, auch dann wenn sie nicht genau passen (HTML-Injection ist eigentlich kein XSS da kein Scripting). Also tragt mit der vorgeschlagenen "Zusammenführung" bitte nicht noch mehr zur Verwirrung bei. -- 24- Nov. 2007 Circe

Bitte lest doch mal Hilfe:Diskussionsseiten --SonniWP2 15:18, 12. Aug. 2007 (CEST)Beantworten

Ausbau

Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Dieser Text ist sicherlich noch sehr weit ausbaufähig, da es ein sehr komplexes Thema ist. Werde es evtl. demnächst mal gründlich erweitern. Beispiele für PHP-Programmierer etc... Besteht daran Interesse? Bin mir nicht sicher... Dieser Kommentar ist von 00:36, 10. Jul. 2005 Shurakai

PHP läßt einen eigenen Artikel vermuten? --SonniWP2 15:24, 22. Aug. 2007 (CEST)Beantworten

=> Idee: SonniWP2 konzentrier dich auf die Gabe die Artikel korrekt darzustellen, aber bitte lass den Inhalt zumindest in diesem Thema sein, du verstehst zu wenig davon.

XSS nicht nur clientseitig?

Bisher hatte ich immer gelesen, dass CSS eine rein clientseitige Angelegenheit ist, serverseitig sind das doch ganz andere Angriffe. Ich finde es auch absolut nicht sinnvoll dies zu vermischen. Komentar von 217.166.237.2

=> Der eingeschläuste Code wird in jedem Fall im Server- Kontext ausgeführt, darum geht es ja.

  Ich versuche Werte von der Datenbank AUF DEM SERVER zu erhalten. Seiten können auch über Xss 
  verändert und zu Vieren- Schleudern werden, Fachbegriff kenne ich nicht, die Art und Weise wie
  diese Angriffsart im endeffekt dazu genutzt wird, Userdaten zu erhalten geht mehr in die Richtung
  von Phishing.
  Ein kleines, gaaaaaaanz einfaches Beispiel:
  Auf dem Server läuft die Webanwendung, diese enthält eine php Datei zur user- authentifizierung.
  Angenommen folgendes Code- Stück ist enthalten:
  
  $username = $_POST["username"];
  $pwd= $_POST["pwd"];
  $query = mysql_query("Selecdt * from users where user = '$username' And password='$pwd'");
  //Note: not syntaxchecked, only pseudo- code, Database-result overwritten in $query is assumed
  if($query != null){
      //acces granted (remember the pseudo code note)
  }else{
      //wrong usr/pwd (remember the pseudo code note)
  }

  Wird der Seite nun anstelle eines Usernamen einfach folgender String übergeben: ' OR '1' = 1'

  Sieht dasselbe Snipped folgendermassen aus

  $username = $_POST["username"];
  $pwd= $_POST["pwd"];
  //Im logischen Klartext, also mit Variablenwerten
  $query = mysql_query("Selecdt * from users where user =  or '1' = '1' And password= or '1' =    
  '1'");
  //Note: not syntaxchecked, only pseudo- code, Database-result overwritten in $query is assumed
  if($query != null){
      //acces granted (remember the pseudo code note)
  }else{
      //wrong usr/pwd (remember the pseudo code note)
  }

  N Bissle SQL Grundwissen und mann erkennt wie der Einfache (is ja nur pseudo code...)   
  Prüfmechanismus umgangen wurde.

  Das und nix anderes is xss in seiner einfachsten Form;)

Was du hier beschreibst ist SQL-Injection, das hat mit XSS wenig bis nichts zu tun. Ich denke einer der Admins sollte das wieder löschen ;-) -- 15.Feb.08, Circe

"Samy" als Beispiel?

Vielleicht könnte man auch die "Samy Story" als Beispiel für mögliche Auswirkungen einbauen: http://www.heise.de/newsticker/meldung/65039 Komentar von 217.166.237.2

Lemma

Letzter Kommentar: vor 17 Jahren9 Kommentare7 Personen sind an der Diskussion beteiligt

Ich habe hier mal das Standardstichwort für solche Diskussion drüber gesetzt --SonniWP2 14:59, 12. Aug. 2007 (CEST)Beantworten

Titel: Cross-Site Scripting

Im Englischen werden keine Bindestriche zur Verbindung von Substantiven verwendet: "cross site scripting". Im Deutschen macht diese Verwendung jedoch keinen Sinn und wird gerne als Deppenleerzeichen bezeichnet. Meiner Ansicht nach sollte der Titel damit "Cross-site-scripting" heissen. Besonders die Mischung von einem Bindestriche mit Leerzeichen macht meiner Meinung nach keinen Sinn. Titel ändern? Kore 11:55, 20. Mai 2007 (CEST)Beantworten

Im Englischen (auch US) werden beide Varianten benutzt: "cross site" und "cross-site", letztere ist IMHO häufiger, falsch ist keine. "Cross-site-scripting" ist definitiv falsch, weil alle drei Bestandteile Substantive sind. Darum ist die richtige Schreibweise Cross-Site-Scripting. Geht man jedoch von "cross site" aus, dann wäre "Cross-site-Scripting" richtig. Aber ich denke in der Praxis kann man diesen kleinen Unterschied durchaus verschmerzen, schauen wir in 99 Jahren nochmal ... BTW, "Sinn macht" nie etwas ;-) es kann nur Sinn haben/ergeben. -- 24. Nov 2007, Circe

Mein Vorschlag: Internetscripting - lieber wäre mir allerdings ein rein deutsches Lemma --SonniWP2 14:59, 12. Aug. 2007 (CEST)Beantworten

Uh nein, bitte nicht. Bitte nicht einen etablierten Begriff wie "Cross-Site-Scripting" durch einen nichtssagenden, immer noch nicht deutschsprachigen und irreführenden Begriff wie "Internetscripting" ersetzen ;-) Warp 16:44, 12. Aug. 2007 (CEST)Beantworten

Was haltet ihr denn von Rechnerfernsteuerung übers Netz? --SonniWP2 15:20, 22. Aug. 2007 (CEST)Beantworten

Gar nichts! --84.157.129.236 21:59, 18. Dez. 2007 (CET)Beantworten

Serverseitig

Die Beschreibung von Serverseitig finde ich unglücklich bis falsch. Solche Dinge wie include() in PHP fallen in die allgemeinere Kategorie Code-Injection, dazu würde dann auch asp, jsp, perl, usw. gehören.. Wenn die Shell Ziel des Angriffs ist, dann spricht man von OS-Command-Injection gelegntlich auch OS-Commanding). Analog gibt es LDAP-Injection. XML-Injection und XPATH-Injection tauchen vereinzelt auch schon auf.

Im englischen Sprachgebrauch wurde (wird vereinzelt noch) dann von "server side" gesprochen, wenn "persistent injection" --im Gegensatz zu "reflected injection"-- gemeint ist. Gibt es dafür schon eine gute Übersetzung? 2 Kommentare von Circe

grrrrrrr* include() bildet ein zentrales Herzstück von Xss!

(geschrieben von demselben dude der oben auch das kleine Beispiel eingefügt hat, bitte nur infos wo ihr euch sicher seit;))

oje, da hat jemand (der dude:) gar nichts verstanden.

Serverseitig / Schutz

In aller größter Eile.

Der Hinweis auf den Microsoft Mitarbeiter und Buch haben für den Leser keinerlei informelle Qualität. In dieser Form kann ich das nur als werbend bezeichnen.
Schutz: "<script />" Tags werden gerade vom HTML Parser interpretiert und delegieren zu einem entsprechend angedachten Parser. Um die Interpretation von Zeichenfolgen zu verhindern müssen sie als CDATA (Character Data) Bereich oder (innerhalb von HTML) als <pre> (Preformated) gekennzeichnet sein.

Im Großen und Ganzen wirkt der Artikel sachlich stark mangelhaft, ich setz das mal auf meine TODO Liste und bitte solange um ein Review... --spheredancer 07:11, 20. Dez. 2006 (CET)Beantworten

"Dabei sollte man sich nicht darauf verlassen, „böse“ Eingaben zu definieren (Schwarze Liste), um diese herauszufiltern, da man nicht genau wissen kann, welche Angriffsmethoden es gibt. Besser ist es daher, die „guten“ Eingaben exakt zu definieren (Weiße Liste) und nur solche Eingaben zuzulassen." Diese Beschreibung ist viel zu schwammig und undifferenziert. Blacklisting und Whitelisting sind nicht beliebig austauschbar, sondern hängen vom Einsatzgebiet ab. Whitelisting ist in einem Wiki z.B. im eigentlichen Sinne nicht möglich, nur verbunden mit einem Filter. Besser wäre es zu behaupten, dass Whitelisting vorzuziehen ist, wo immer es möglich ist, da dadurch auch bisher unbekannte Angriffe ausgeschlossen werden. Das bezieht sich auch auf den zweiten Halbsatz im Artikel. "Welche Angriffsmethoden ist gibt" kann man wissen, welche zukünftigen Angriffsmethoden es gibt kann man nicht wissen. --migg 11:20, 6. Mär. 2008 (CET)Beantworten

Jein. Sicher kann man in einem Wiki nichts generell Whitelisten. Aber man soll eben nicht nur bestimmte böse Sachen rausfiltern, sondern generell definieren, was gut ist und was nicht. Also muss man z.B. generell alle bösen Zeichen escapen. Was allerdings auch leicht den Charakter einer Blacklist hast. Schwierig. -- [tʁaˈveːn] 13:53, 6. Mär. 2008 (CET)Beantworten

Überarbeiten

Letzter Kommentar: vor 17 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Siehe auch die Kommentare zum Serverseitigen Scripting.

Einleitung überarbeiten
Unterschiedliche Typen vorstellen
Begriff "Cross-Site" erklären (Persistant Scripting funktioniert ja eigentlich auf einer einzigen Seite)

-- iGEL·대화·Bew 14:54, 12. Aug. 2007 (CEST)Beantworten

Die Weblinks sollten ausgedünnt und nur auf wirklich Relevantes reduziert werden. Zudem sollte ein engerer Bezug zu den anderen Cross-Site-Formen (siehe Kategorie Sicherheitslücken) hergestellt werden. 212.95.109.137 11:38, 12. Sep. 2007 (CEST)Beantworten

Ich hab mal angefangen ein bisschen dran zu werkeln (Abschnitt 1 und 2). Da ich mich sowieso gerade mit dem Thema beschäftige, werde ich in den nächsten Tagen den ganzen Artikel einmal überarbeiten. Mal sehen, ob ich die Abgrenzung zu den anderen genannten Artikel schaffe. -- Glue 17:12, 17. Mai 2008 (CEST)Beantworten