JavaScripts einschmuggeln?

[Tom]

Hello,

ich rekapituliere gerade meine Sammlug der Sicherheitslücken...

Ich möchte zur Sicherheit nochmal die Frage stellen:

Wo könnte man Javascripts unterbringen, um sie auf den Server einer Community hochzuladen?

Wodurch kann man die eingeschmuggelten Scripts aktivieren?

Das Script selber könnt man bestimnmt durch viele Filter schmuggeln, aber die Tags dazu werden (hoffentlich) überall ausgefiltert.

Welche Lücken gäbe es denn trotzdem, um nun z.B. in einem Benutzerprofil eines "Singleforums" die textlichen Javascripts auf dem Browser des Besuchers der Seite auszuführen?

Ich hoffe, ich konnte die "Aufgabenstellung" einigermaßen rüberbringen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christoph Schnauß]

hallo Tom,

ich rekapituliere gerade meine Sammlug der Sicherheitslücken...

Nett.

Wo könnte man Javascripts unterbringen, um sie auf den Server einer Community hochzuladen?

Sofern Serverzugriff (z.B. per FTP) besteht: überall. In jedem beliebigen öffentlich erreichbaren Verzeichnis.

Wodurch kann man die eingeschmuggelten Scripts aktivieren?

Gar nicht. Jedenfalls du als Scriptautor mit einem Userkonto kannst das nicht.

HA!!!!!!!!
Es handelt sich hier um eine typische Fangfrage kurz vor Beginn der Walpurgisnacht! Du möchtest nämlich, hinterlistig, wie du bist, wissen, wie es manche Provider (z.B. Yahoo) anstellen, daß ihre dämliche Werbung immer per Javascript in alle ausgegebenen Dokumente eingebunden wird  -  selbst wenn es sich um scriptgesteuerte Ausgaben handelt. DU BIST ERTAPPT!
Sowas kannst du nur dann machen, wenn du auf dem Server selbst Administratorrechte hast. Und da du ein Novize bist, dem die höheren Weihen fehlen, DARF ich dir nicht verraten, wie das geht.

Das Script selber könnt man bestimnmt durch viele Filter schmuggeln, aber die Tags dazu werden (hoffentlich) überall ausgefiltert.

Nö. So einfach isses denn auch nicht.

Welche Lücken gäbe es denn trotzdem, um nun z.B. in einem Benutzerprofil eines "Singleforums" die textlichen Javascripts auf dem Browser des Besuchers der Seite auszuführen?

Keine  -  solange du nicht Serveradministrator bist oder auf irgendeine andere perfide Weise tatsächlich _JScript_ (oder serverseitiges Javascript) hochlädst. Was der Serveradministrator allerdings verhindern kann. Wenn es trotzdem klappt, setze den Admin ab und übergib ihn den heute nacht auf dem Blocksberg tanzenden Hexen.

Ich hoffe, ich konnte die "Aufgabenstellung" einigermaßen rüberbringen.

Ja. Sie gilt allerdings wirklich nur für die heutige Walpurgisnacht.

Grüße aus Berlin

Christoph S.

[Tom]

Hello,

Sofern Serverzugriff (z.B. per FTP) besteht: überall. In jedem beliebigen öffentlich erreichbaren Verzeichnis.

FTP-Zugang besteht i.d.R. nicht.
Man lädt eben über ein Uploadformular seinen Text, seine Bilder und ggf. auch Formatierungen hoch.
Aber selbst bei Bulletin-Systemen mit eigenem Formatierungscode ist es manchmal möglich, den String <script> in der Ausgabe zu erzeugen. Das reicht dann i.d.R. schon, um ein Script zu aktivieren.

Auch <meta ...> wäre eventuell tödlich.

Die Idee mit einer kleinen Walpurgis-Teufelei ist zwar nett, aber diesmal nicht die meine ;-)

Nö. So einfach isses denn auch nicht.

Was ist nicht so einfach? Die Tags rauszufiltern?

Es gab ein System, dass diverse JavaScripts zugelassen hat, weil der Autor dort <b> und <p> und noch ein paar ausgewählte Tags nebst CSS zugelassen hat. Da hatte er übersehen, dass die auch locker ein onLoad oder ein onClick usw. vertragen haben. Das war dann die Sicherheitslücke, diverse andere Dinge, bis hin zur Cookie-Entführung (auch den Session-Cookie des jeweiligen Besuchers der Seite) durchzuführen. Ich habe das System seinerzeit nachgebaut und den Betreiber gewarnt. Erst hat er gar nicht gewusst, was ich von ihm wollte...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[XaraX]

Hello Tom,

Du müßtest nur dafür sorgen, daß alle "Sonderzeichen" (also eben '<' '>') bei der Anzeige konsequent in ihre HTMLentytäten umgewandelt  werden. Das ist zuverlässiger Schlagbaum an der "Zollstelle" ;)

Gruß aus Berlin!
eddi

[Christoph Schnauß]

hallo Tom,

Hm. Ich wittere Ungemach.

FTP-Zugang besteht i.d.R. nicht.

Uiiii ... also wird das, was du hochladen möchtest, über irgendeinen anderen Mechanismus realisiert. Du hast verschwiegen, daß du ein upload-Script nutzt, das in PHP oder irgendeiner anderen perfiden Technologie gefaßt ist und mit dem du FTP autricksen willst. Schäm dich! Da hättest du nämlich ein anderes Topic als dieses dümmliche "HTML" auswählen müssen.

Man lädt eben über ein Uploadformular seinen Text, seine Bilder und ggf. auch Formatierungen hoch.

"Formatierungen" sind noch keine Scripts ;-p

Aber selbst bei Bulletin-Systemen mit eigenem Formatierungscode ist es manchmal möglich, den String <script> in der Ausgabe zu erzeugen. Das reicht dann i.d.R. schon, um ein Script zu aktivieren.

Halt mal. _Das_ ist jetzt zu kurz. Ja, du hast recht, wenn in einer derart hochgeladenen Seite ein
  <script>
steht, reicht das  -  für allerhand Dinge, die dann plötzlich auf Clientseite passieren dürfen.

Auch <meta ...> wäre eventuell tödlich.

"Tödlich" ist meines Erachtens etwas zu drastisch ausgedrückt.

Die Idee mit einer kleinen Walpurgis-Teufelei ist zwar nett, aber diesmal nicht die meine ;-)

Kannst du mal sehen, was ich dir alles zugetraut hätte.

Nö. So einfach isses denn auch nicht.
Was ist nicht so einfach? Die Tags rauszufiltern?

Gut, werden wir ernsthaft. Vielleicht habe ich ja auch deine Frage noch nicht wirklich verstanden, oder ... (ähm, heute gibts wegen der Walpurgisnacht keinen Wein, sondern ordinäres Bier)

Es gab ein System, dass diverse JavaScripts zugelassen hat, weil der Autor dort <b> und <p> und noch ein paar ausgewählte Tags nebst CSS zugelassen hat.

Lieber Tom  -  das verstehe ich nicht. Jedenfalls nicht die Kausalität. _weil_ jemand <b> und <p> in seinen HTML-Code einträgt, wird am Ende schädliches Javascript vom Server ausgegeben? Das ist ein mir unerklärliches Phänomen.

Da hatte er übersehen, dass die auch locker ein onLoad oder ein onClick usw. vertragen haben. Das war dann die Sicherheitslücke

Ich fürchte, daß dir zwar die (möglichen) Zusammenhänge sehr klar sind, du sie aber einfach nicht verständlich "rüberbringst". Tut mir leid, Kollege, aber ich verstehe dich nicht. Und du weißt, daß mich mein miserabler "Ruf" in diesem Forum an dieser Stelle zwingen muß, dich mit einem arroganten Hinweis auf

abzuspeisen.

Erst hat er gar nicht gewusst, was ich von ihm wollte...

Mir gehts im Moment genauso. Es gibt irgendein Gedicht von Christian Morgenstern, in dem die Zeile vorkommt:
  "er weiß nicht, was die $name singt,
   er weiß nur, daß es lieblich klingt"

Grüße aus Berlin

Christoph S.

[wahsaga]

hi,

Vielleicht habe ich ja auch deine Frage noch nicht wirklich verstanden,

ja, davon ist wohl auszugehen.

oder ... (ähm, heute gibts wegen der Walpurgisnacht keinen Wein, sondern ordinäres Bier)

dann bleib zukünftig lieber bei deinem holundergebräu - das verträgst du offenbar besser ;-)

Es gab ein System, dass diverse JavaScripts zugelassen hat, weil der Autor dort <b> und <p> und noch ein paar ausgewählte Tags nebst CSS zugelassen hat.

Lieber Tom  -  das verstehe ich nicht.

noch mal zur fragestellung:

tom redet von einem system, wo user eigene texteinträge machen können - also beispielsweise in einem forum wie diesem hier, einem board, einer community-lösung wie flirtportalen, etc.

und er will überlegungen anstellen, auf welche fallstricke der programmierer dabei achten muss, um dem benutzer nicht das einschleusen von javascript-code über seine beiträge zu ermöglichen.

Da hatte er übersehen, dass die auch locker ein onLoad oder ein onClick usw. vertragen haben. Das war dann die Sicherheitslücke

Jedenfalls nicht die Kausalität. _weil_ jemand <b> und <p> in seinen HTML-Code einträgt, wird am Ende schädliches Javascript vom Server ausgegeben? Das ist ein mir unerklärliches Phänomen.

der benutzer dieses systems gibt textbeiträge ein, und dabei wurde die benutzung bestimmter HTML-tags wie <b> und <p> zu foramtierungszwecken erlaubt.

da der programmierer aber nicht genug nachgedacht hat, waren in diesen auch eventhandler und damit die ausführung von javascript-code im kontext der anzeigenden seite möglich.

Und du weißt, daß mich mein miserabler "Ruf" in diesem Forum an dieser Stelle zwingen muß, dich mit einem arroganten Hinweis auf

abzuspeisen.

etwas weniger dieser arroganz (und etwas weniger bier) hätten deinem ruf in diesem falle vermutlich besser getan.

gruß,
wahsaga

[Christoph Schnauß]

hallo,

Und du weißt, daß mich mein miserabler "Ruf" in diesem Forum an dieser Stelle zwingen muß, dich mit einem arroganten Hinweis auf

abzuspeisen.
etwas weniger dieser arroganz (und etwas weniger bier) hätten deinem ruf in diesem falle vermutlich besser getan.

Du verstehst nicht: Tom hat eine Steilvorlage für ein Sonderkapitel im Lehrbuch für "höhere Clownerie" geschrieben und sich dafür ausgerechnet den Beginn der Walpurgisnacht ausgesucht ...

Grüße aus Berlin

Christoph S.

[Ilja]

yo,

Du verstehst nicht: Tom hat eine Steilvorlage für ein Sonderkapitel im Lehrbuch für "höhere Clownerie" geschrieben und sich dafür ausgerechnet den Beginn der Walpurgisnacht ausgesucht ...

aber vielleicht kann man von diesem extra-kapitel ausnahmsweise mal absehen und sich wieder der eigentlichen problematik von tom widmen, die wahasaga noch mal gut widergegeben hat. das thema finde ich nämlich schon sehr interessant, würde gerne die vorschläge mitlesen, da ich dies bezüglich sicherlich auch noch vieles wichtiges erfahren kann.

Ilja

[Tom]

Hello,

[...] würde gerne die vorschläge mitlesen, da ich dies bezüglich sicherlich auch noch vieles wichtiges erfahren kann.

Dann warten wir mal lieber bis Montagabend. Dann ist Walpurga (alias Chr. Schnauss) wieder nüchtern und die 1.Mai-Säufer hoffentlich auch.

Ich suchte eben noch nach solchen Hinweisen, die Candid Dogfish eben gab. Solchen Spuren würde ich gerne nochmal nachgehen. Ersetzungen im Browser, die vor der Interpretation der Seite stattfinden könnten... Dazu könnten auch spezielle Zeichensätze gehören, wenn die die < > darstellen können, ohne dass die Schutzfunktionen am Server etwas davon mitbekommen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Dazu könnten auch spezielle Zeichensätze gehören, wenn die die < > darstellen können, ohne dass die Schutzfunktionen am Server etwas davon mitbekommen.

nein, wohl eher nicht.

selbst wenn ich einen zeichensatz benutzen kann, der ä als < und ö als > darstellt - dann kann ich als user
äscriptö boese_funktion(); ä/scriptö
eingeben, bis ich schwarz werde - dass wird aber keinen browser interessieren.

wenn du einen browser < und > interpretieren lassen willst, musst du auch < und > eingeben - und nichts anderes, das zufällig genauso _dargestellt_ wird.

gruß,
wahsaga

[XaraX]

hi wahsaga,

Deinem Geschreibenen stimme ich zwar zu, aber der Einwand von Candid Dauth ist mir auch schon einmal hier im Forum untergekommen. Das ist so wie Candid Dauth schreibt in der Art ${...} oder &{...} gewesen. Das ist irgendein Gedöns, was der IE interpretiert und mit JavaScript eher weniger zutun hat, aber gleiche Effekte bewirken konnte.
Ich habe gerade die Suche Traktiert, aber nichts gefunden. Wie auch immer, diesen und ähnlichen (unbekannten) Problemen wird man dadurch Herr, daß alle Zeichen, die nicht vom Schema [[:alnum:]] und [:space:] sind, in Entytäten umgewandelt.

Gruß aus Berlin!
eddi

[Tom]

Hello,

[...] in Entytäten umgewandelt.

also alles passend e(i)ntytet, gelle?

*scnr*
Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Deinem Geschreibenen stimme ich zwar zu, aber der Einwand von Candid Dauth ist mir auch schon einmal hier im Forum untergekommen. Das ist so wie Candid Dauth schreibt in der Art ${...} oder &{...} gewesen. Das ist irgendein Gedöns, was der IE interpretiert und mit JavaScript eher weniger zutun hat, aber gleiche Effekte bewirken konnte.

Aber es würde ja auch nie wirksam, da das Dollarzeichen sowieso keine Sonderfunktion in HTML hat, und das Und-Zeichen als Entity im Browser landen würde. Und &amp;{...} ist nun mal nachweislich unschädlich.

Nochmal ganz allgemein gesprochen: Wenn man jeglichen Userinput als Textdaten versteht und sie auch wieder als Text im Browser ausgibt - das setzt zwingend die Codierung von HTML-aktiven Zeichen als Entities voraus, sonst kommt kein Text im Browser an - dann besteht keinerlei Gefahr für irgendwelche Angriffslücken, an die man nicht gedacht hat.

Wenn man hingegen Text un- oder schlechtgefiltert an den Benutzer ausgibt, dann hat man möglicherweise ein Problem. Die Idee, bestimmte HTML-Tags zuzulassen, diese dann aber inklusive aller Attribute - auch der javascripthaltigen - ungeprüft durchzuschleifen, ist natürlich ziemlich unpraktisch.

Genau deshalb ist der Einsatz von BB-Code (dafür gibts viele schöne Klassen und/oder Funktionen zur Wandlung in HTML in vermutlich allen existierenden Sprachen) zur Formatierung von Text extrem vorzuziehen, weil der BB-Code-Parser automatisch prüfen muß, ob der BB-Code valide ist, und er wird nur vollständig validen Code in HTML umsetzen (klar, schlechte BB-Code-Funktionen machen da möglicherweise etwas mehr Mist und geben ungültiges HTML raus, weil nur Stringersetzungen vorgenommen wurden, aber tendentiell wird bei solchen Ersetzungen die Erlaubnis von beliebigen Attributen gerade NICHT gegeben).

Insgesamt sehe ich das Problem weitaus weniger gravierend. Mit der Wandlung sämtlichen Textes in Entities kann nichts passieren, egal was der Angreifer anstellt - damit hat man dann aber auch nur unformatierten Text, allenfalls ein nl2br ginge noch zusätzlich. Mit exakt definiertem BB-Code dürfte ebenfalls kein Risiko bestehen. Und das unveränderte Durchschleifen von Texteingaben verwende ich, wenn es um die Bearbeitung von HTML-Quellcode im Rahmen eines CMS geht, der Eingeber/Angreifer also weiß, was er tut, und das mit voller Absicht.

• Sven Rautenberg

[Tom]

Hello,

Insgesamt sehe ich das Problem weitaus weniger gravierend. Mit der Wandlung sämtlichen Textes in Entities kann nichts passieren, egal was der Angreifer anstellt - damit hat man dann aber auch nur unformatierten Text, allenfalls ein nl2br ginge noch zusätzlich. Mit exakt definiertem BB-Code dürfte ebenfalls kein Risiko bestehen. Und das unveränderte Durchschleifen von Texteingaben verwende ich, wenn es um die Bearbeitung von HTML-Quellcode im Rahmen eines CMS geht, der Eingeber/Angreifer also weiß, was er tut, und das mit voller Absicht.

Ich sehe die Gefahr nach wie vor bei dem Aberglauben, dass bestimmte Funktionen (z.B. htmlentities() in PHP) sicher geschrieben wären. Mit manchen Codierungen kommt diese Funktion (noch) nicht zurecht und lässt sie daher leider raw passieren. Was dann der Browser daraus macht, ist dann extrem spannend. In anderen Sprachen oder Systemen gibt es ähnliche Lücken. Es fehlt mir dazu leider im Moment noch der Überblick. Den gedachte ich mit Hilfe dieses Threads zu verbessern. :-)

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Ich sehe die Gefahr nach wie vor bei dem Aberglauben, dass bestimmte Funktionen (z.B. htmlentities() in PHP) sicher geschrieben wären.

Wieso "Aberglauben"? Die genannte Funktion htmlentities() hat eine definierte Funktion, und alle Abweichungen davon sind als Fehler zu behandeln und alsbald zu beheben. Zumal ich sowieso nicht htmlentities() einsetzen würde, sondern nur htmlspecialchars(), denn die Wandlung von z.B. Umlauten in Entities ist, was die Sicherheit angeht, irrelevant.

Mit manchen Codierungen kommt diese Funktion (noch) nicht zurecht und lässt sie daher leider raw passieren.

Beispiele. Die Zeichencodierung eines Eingabedatenstromes dürfte irrelevant sein bei definierter Zeichencodierung der Ausgabe. Da die HTML-relevanten Zeichen <, > und & als Bestandteil des ASCII-Zeichensatzes in allen existierenden Zeichensätzen an der gleichen Codeposition vorkommen, sollte selbst ein beliebiger Bytedatenstrom sicher gewandelt werden können.

Was dann der Browser daraus macht, ist dann extrem spannend.

Wenn der Browser bei abstrusen Bytefolgen austickt, ist das ein Browserproblem.

• Sven Rautenberg

[Ilja]

yo,

Zumal ich sowieso nicht htmlentities() einsetzen würde, sondern nur htmlspecialchars()

wenn ich dich richtig verstanden habe, dann reicht diese funktion aus, um eingaben über ein formular zu entschärfen, man ist alleine damit auf der sicheren seite ?

Ilja

[Tom]

Hello,

wenn ich dich richtig verstanden habe, dann reicht diese funktion aus, um eingaben über ein formular zu entschärfen, man ist alleine damit auf der sicheren seite ?

Ich dachte da an utf-8 und seine Schwestern.

PHP:::htmlentities() kann die noch nicht richtig fassen.

Ich gestehe ja, dass mir da der Überblick fehlt und erst recht der Durchblick, aber in dieser Richtung gedenke ich genauer hinzugucken!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian Kruse]

你好 Tom,

wenn ich dich richtig verstanden habe, dann reicht diese funktion
aus, um eingaben über ein formular zu entschärfen, man ist alleine damit
auf der sicheren seite ?

Ich dachte da an utf-8 und seine Schwestern.

PHP:::htmlentities() kann die noch nicht richtig fassen.

Das ist quatsch. Zitat:

Table 2. Supported charsets
Charset         Aliases                        Description
ISO-8859-1      ISO8859-1                      Western European, Latin-1
ISO-8859-15     ISO8859-15                     Western European, Latin-9. Adds the Euro sign, French and Finnish letters missing in Latin-1(ISO-8859-1).
UTF-8                                          ASCII compatible multi-byte 8-bit Unicode.
cp866           ibm866, 866                    DOS-specific Cyrillic charset. This charset is supported in 4.3.2.
cp1251          Windows-1251, win-1251, 1251   Windows-specific Cyrillic charset. This charset is supported in 4.3.2.
cp1252          Windows-1252, 1252             Windows specific charset for Western European.
KOI8-R          koi8-ru, koi8r                 Russian. This charset is supported in 4.3.2.
BIG5            950                            Traditional Chinese, mainly used in Taiwan.
GB2312          936                            Simplified Chinese, national standard character set.
BIG5-HKSCS                                     Big5 with Hong Kong extensions, Traditional Chinese.
Shift_JIS       SJIS, 932                      Japanese
EUC-JP          EUCJP                          Japanese

Bitte verifiziere es, wenn du etwas behauptest.

再见,
克里斯蒂安

[Tom]

Hello,

Bitte verifiziere es, wenn du etwas behauptest.

Aber bitte nicht agressiv werden :-(

Mein Alzheimer läst mich lkeider im Moment nicht die gemerkte Lücke finden.
Ob das nun utf-8 oder Unicode oder was auch immer war. Es gibt Codierungen, die hier nicht erfasst werden. Und anstatt dass Du schon wieder den absoluten Allesrichtigwisser spielst, könntest Du auch mal etwas toleranter sein und auch Möglichkeiten außerhalb Deines momentanen Scopes zulassen.

Für den gegebenen Hinweis jedenfalls Dank. Den werde ich in meine weiteren Überlegungen einbeziehen.
Dein Absolutheitsanspruch ist aber ekelhaft!

ICH hatte die Frage gestellt nach weiteren Sicherheitslücken und NICHT BEHAUPTET, dass es keine (oder viele) weitere(n) gäbe. Also berücksichtige doch bitte in Zukunft die Problemstellung.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian Kruse]

你好 Tom,

Bitte verifiziere es, wenn du etwas behauptest.

Aber bitte nicht agressiv werden :-(

Welche Agressivitaet?

Ob das nun utf-8 oder Unicode oder was auch immer war. Es
gibt Codierungen, die hier nicht erfasst werden.

Natuerlich -- aber UTF-8 ist nicht dabei, siehe zitierten
Dokumentationsteil.

ICH hatte die Frage gestellt nach weiteren Sicherheitslücken und NICHT
BEHAUPTET, dass es keine (oder viele) weitere(n) gäbe. Also
berücksichtige doch bitte in Zukunft die Problemstellung.

Du hast behauptet, htmlentities() kaeme mit UTF-8 nicht klar. Ich habe dir
gesagt, das sei Unsinn. Das htmlentities() nicht alle Kodierungen abdeckt,
ist unbestritten, ich habe dir die unterstuetzten Kodierungen sogar
noch zitiert. Man, man, man... guck doch einfach ab und zu mal ins
Handbuch!

再见,
克里斯蒂安

[Tom]

Hello,

[...] Man, man, man... guck doch einfach ab und zu mal ins
Handbuch!

Vielleicht sehen wir uns eines Tages, wenn Du fertig bist mit handbuchgucken und auch mal kämpfen musst gegen den Tagesablauf ;-)

CU

PS: dass ich mich bemühe, immer alle (alten) Erfahrungen zu berücksichtigen, erkläre ich hier an Eiders Statt!
Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Anonymous]

[...] Man, man, man... guck doch einfach ab und zu mal ins
Handbuch!

Vielleicht sehen wir uns eines Tages, wenn Du fertig bist mit handbuchgucken und auch mal kämpfen musst gegen den Tagesablauf ;-)

Mir drängt sich der Eindruck auf, dass dir Argumente fehlen.

PS: dass ich mich bemühe, immer alle (alten) Erfahrungen zu berücksichtigen, erkläre ich hier an Eiders Statt!

Normalerweise erklärt man etwas an Eides statt. Die Eider hat damit nichts zu tun.

[Tom]

Hello,

Mir drängt sich der Eindruck auf, dass dir Argumente fehlen.

Das habe ich doch von Anfang an gesagt, dass ich weitere Tatsachen und Argumente suche, um meine Sammlung sortieren, untermauern oder ad absurdum zu führen.

(nimm's bitte nicht persönlich. Aber ein Anonymous hat ja gar keine, oder? )

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Anonymous]

Mir drängt sich der Eindruck auf, dass dir Argumente fehlen.

Das habe ich doch von Anfang an gesagt, dass ich weitere Tatsachen und Argumente suche, um meine Sammlung sortieren, untermauern oder ad absurdum zu führen.

Nein, eigentlich nicht. Aber sei es, wie es sei, du bist mir zu langweilig um mit dir zu diskutieren.

[Tom]

Hello,

Nein, eigentlich nicht. Aber sei es, wie es sei, du bist mir zu langweilig um mit dir zu diskutieren.

ich zitirere nochmals:

---------
Hello,

ich rekapituliere gerade meine Sammlug der Sicherheitslücken...

Ich möchte zur Sicherheit nochmal die Frage stellen:
[...]
---------

Wenn Dir das also zu langweilig ist, was paulst Du mich dann also hier an?
Könntest Du nicht einfach mal zugeben, dass Du Dich im Ton vergriffen hast, weil Du Dich einfach nicht gut genug in den Thread eingelesen hast? Und nun auch nochmals nachzutreten als "Anonymous", das ist Dir eigentlich nicht würdig.

Oder?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Anonymous]

Und nun auch nochmals nachzutreten als "Anonymous", das ist Dir eigentlich nicht würdig.

Ich verstehe nicht so recht, worauf du hinaus willst.

[Dennis]

Hi Anonymous,

Und nun auch nochmals nachzutreten als "Anonymous", das ist Dir eigentlich nicht würdig.

Ich verstehe nicht so recht, worauf du hinaus willst.

Ich glaube Tom möchte dir sagen, dass du dich doch bitte raushalten sollst, wenn du nicht auf die Fragestellung eingehst. Na ja.

ICH jedenfalls finde, sämtliche Kommentare die hier jetzt von verschiedenen Seiten gefallen sind gehören absolut nicht in ein Diskussionsforum - wer sich "zoffen" will, kann das per E-Mail machen. ;-)

Somit würde ich hier vorschlagen: self.close() - EOT.

MfG, Dennis.

[Tom]

Hello,

ICH jedenfalls finde, sämtliche Kommentare die hier jetzt von verschiedenen Seiten gefallen sind gehören absolut nicht in ein Diskussionsforum - wer sich "zoffen" will, kann das per E-Mail machen. ;-)

So ungefähr.
Ich persönlich finde es jedenfalls schade, dass manche, die vielleicht mal was studiert haben, nun glauben, das wäre die einzige Wahrheit und die würde auf ewig gelten. Wenn sie denn die momentane wissenschaftliche Meinung mit gewissem Recht vertreten könnten, sollten sie dies keinesfalls  mit der Arroganz der "Besserwissenden" und dem Anspruch auf Absolutheit tun. Die Geschichte hat gezeigt, dass es immer wieder Neuerungen gibt.

Ich wünsche mir, dass die "Wissenden" in diesem Forum mit soviel Fingerspitzengefühl vorgehen, dass sowohl der didaktische Aspekt als auch der innovative gewahrt bleiben. Es muss doch heute nicht immer mit dem Hammer sein - insbesondere, wenn sich die Wissenschaft morgen wieder "erneurt".

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian Kruse]

你好 Tom,

[...] Man, man, man... guck doch einfach ab und zu mal ins
Handbuch!

Vielleicht sehen wir uns eines Tages, wenn Du fertig bist mit
handbuchgucken und auch mal kämpfen musst gegen den Tagesablauf ;-)

Halten wir fest: du hast eine Behauptung aufgestellt. Ich habe dir mit
einem Zitat gezeigt, dass es Quatsch ist. Du beharrst weiter auf deiner
Behauptung und versuchst mich zu diskreditieren, indem du mich als
Praxisfern darstellst. Gut zu wissen, mehr brauche ich nicht, danke.

再见,
克里斯蒂安

[Christian Kruse]

你好 Ilja,

Zumal ich sowieso nicht htmlentities() einsetzen würde, sondern nur
htmlspecialchars()

wenn ich dich richtig verstanden habe, dann reicht diese funktion aus, um
eingaben über ein formular zu entschärfen, man ist alleine damit auf der
sicheren seite ?

Ja.
Um aktive Inhalte (in welcher Form auch immer) einzuschleusen, benoetigt
man <, > und &. Wenn man die codiert (und das tut htmlspecialchars()), ist
es technisch nicht moeglich, etwas unerwuenschtes einzuschleusen.

再见,
克里斯蒂安

[Candid Dauth]

Heißa, Tom,

Irgendwo habe ich mal gelesen, dass es Browser gibt, die eine Syntax wie
&{variable+1};
interpretieren. Ich kann mich nicht mehr genau erinnern, wie die Syntax war. Jedenfalls konnte man auf diese Weise hier zum Beispiel den Rückgabewert der Aktion variable+1 in den HTML-Code (überall, wo halt HTML-Entities hindürfen) hineinschreiben. Auf diese Weise könnte man auch einfach den Rückgabewert von window.open() oder sonstigen schädlichen Aktionen ausgeben lassen – eine weitere Sicherheitslücke also.

Nicht, dass ich hier irgendjemandem erzählen möchte, dass er solche Dinge benutzen soll, ich möchte dich nur darauf hinweisen, dass es die Möglichkeit gibt. Du wirst im Internet bestimmt noch etwas darüber finden. Ansonsten könnte ich hier noch mal mein O’Reilly-JavaScript-Buch herauskramen.

Caramba!
Grüße aus Biberach Riss,
Candid Dauth (ehemals Dogfish)