SELFHTML-Aktuell-Artikel zum Kontextwechsel - Bitte um Rezension

[dedlfix]

Hi!

Recht häufig wird die Problematik des Kontextwechsels unbeachtet gelassen. Um nicht immer wieder das Gleiche erzählen zu müssen und dabei die Hälfte zu vergessen, schrieb ich einen SELFTHML-Aktuell-Artikel dazu. Nun bitte ich euch darum die derzeitige Fassung zu lesen und auf Verständlichkeit, Ergänzungspotenzial und sprachliche Fehler (Stil, Rechtschreibung) zu prüfen.

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

Lo!

[suit]

Nun bitte ich euch darum die derzeitige Fassung zu lesen und auf Verständlichkeit, Ergänzungspotenzial und sprachliche Fehler (Stil, Rechtschreibung) zu prüfen.

"(Das passende Thema dazu wäre Zeichenkodierung, das jedoch nicht im Focus dieses Artikels liegt.)"

Verlinke doch hierzu gleich den entsprechenden W3C-Artikel von Gunnar ;)

[dedlfix]

Hi!

"(Das passende Thema dazu wäre Zeichenkodierung, das jedoch nicht im Focus dieses Artikels liegt.)"
Verlinke doch hierzu gleich den entsprechenden W3C-Artikel von Gunnar ;)

Nö, das schweift zu sehr vom Thema ab.

Lo!

[Sven Rautenberg]

Moin!

Recht häufig wird die Problematik des Kontextwechsels unbeachtet gelassen. Um nicht immer wieder das Gleiche erzählen zu müssen und dabei die Hälfte zu vergessen, schrieb ich einen SELFTHML-Aktuell-Artikel dazu. Nun bitte ich euch darum die derzeitige Fassung zu lesen und auf Verständlichkeit, Ergänzungspotenzial und sprachliche Fehler (Stil, Rechtschreibung) zu prüfen.

Ich glaube, du fasst das Thema von der falschen Seite her an.

Schon der allererste Absatz führt in Weiten, die viel zu weit weg sind von dem, was eigentlich wirklich relevant ist. Um was geht es? Um die Darstellung von etwas in verschiedenen Kontexten. Aber was ist "etwas"?

Das kann "Text" sein. Muss es aber nicht immer, es kann auch "HTML" sein, oder "Ein Bild als Binärdaten".

Definiere zu Beginn, dass es dir erstmal wirklich nur um das Thema "Text" geht, und um nichts anderes. Was ist Text abstrakt betrachtet? Und was ist der einfachste Kontext-Wechsel von abstraktem Text hin zur einfachsten realen Speicherungsform? Die 1:1-Transformation in eine Zeichenkette im RAM beispielsweise.

Darauf aufbauend kommt dann als Schritt 2: Wie kriege ich meine Programmiersprache dazu, aus dem Programmcode eine Zeichenkette so einzulesen, dass das Speicherabbild das ist, was ich will?

Und dann kommen Dinge wie die Frage: Wie kriege ich das Speicherabbild so ausgegeben, dass im Kontext HTML, SQL, Javascript, URL, URL in HTML etc. immer noch das korrekte Ergebnis heraus kommt.

Und dann kann man sich noch mit der Frage befassen, warum die Welt zusammenbricht, wenn man beim Kontextwechsel Mist baut.

Als Krönung dann noch: "Ich habe HTML als Kontext im Speicher und will den ausgeben - was tun?" - das schlägt dann nämlich direkt voll durch in das Thema Security.

Ich würde den Artikel auch nicht unbedingt im Bereich "Programmiertechnik" lokalisieren, sondern - weil man um konkrete Infos zur Programmiersprache nicht herum kommt - direkt nur PHP-Beispiele verwenden und deshalb PHP als Rubrik wählen.

- Sven Rautenberg

[Felix Riesterer]

Lieber Sven,

Ich glaube, du fasst das Thema von der falschen Seite her an.

harte Worte als Einleitung zu einer Rezension. Immerhin seid Ihr doch dankbar, wenn jemand einen Artikel schreibt und bei Euch einreicht, oder?

Schon der allererste Absatz führt in Weiten, die viel zu weit weg sind von dem, was eigentlich wirklich relevant ist. Um was geht es? Um die Darstellung von etwas in verschiedenen Kontexten. Aber was ist "etwas"?

Das kann "Text" sein. Muss es aber nicht immer, es kann auch "HTML" sein, oder "Ein Bild als Binärdaten".

Du hast selbstverständlich Recht, wenn Du von dem Artikel erwartest, dass er "Kontextwechsel" im Allgemeineren behandelt, und sich nicht nur auf PHP/MySQL beschränkt. Auch ich hätte gerne gesehen, wie das große Thema "Enkodierungen" und "Kontextwechsel" mittels "kontextgerechtes Enkodieren" zusammenfinden.

Im Grunde ist der Artikel in seiner jetzigen Form bereits wertvoll, wenn auch aus meiner Sicht zu einseitig, aber auf alle Fälle ein sinnvoller und in sich stimmiger Anfang, um das zugegeben sehr umfangreiche Thema irgendwie in Angriff zu nehmen, bei dem Du mit Recht ergänzt, dass es in den Themenbreich "Security" hineinspielt.

Ich würde den Artikel auch nicht unbedingt im Bereich "Programmiertechnik" lokalisieren, sondern - weil man um konkrete Infos zur Programmiersprache nicht herum kommt - direkt nur PHP-Beispiele verwenden und deshalb PHP als Rubrik wählen.

Da würde ich dann aber doch die Rubrik "Programmiertechnik" bestätigen wollen, selbstverständlich unter der Annahme, dass der Artikel "kontextgerechtes Enkodieren" behandelt, dabei nicht nur PHP als Sprache in den Beispielen verwendet, sondern insbesondere den Übergang zwischen den (für Webapplikationen) relevanten Sprachen zeigt: PHP->JS, HTML->JS, JS->HTML, PHP->CSS, JS->PHP, PHP->MySQL etc.

Wer noch andere serverseitige Scriptsprachen benötigt, kann sich das Ganze ja dann in Perl, Ruby, Java und sonstigen Sprachen entsprechend dazudenken.

Liebe Grüße,

Felix Riesterer.

[jobo]

Hallo,

Ich glaube, du fasst das Thema von der falschen Seite her an.

harte Worte als Einleitung zu einer Rezension. Immerhin seid Ihr doch dankbar, wenn jemand einen Artikel schreibt und bei Euch einreicht, oder?

(;-)

Gruß

jobo

[dedlfix]

Hi!

Ich glaube, du fasst das Thema von der falschen Seite her an.
harte Worte als Einleitung zu einer Rezension.

Kein Problem für mich. Ich bevorzuge ehrliche Kritik in jeder respektierenden Form. Deren Worte müssen für mich nicht in Watte gebettet sein.

Lo!

[Jörg]

Hi,

Ich würde den Artikel auch nicht unbedingt im Bereich "Programmiertechnik" lokalisieren, sondern - weil man um konkrete Infos zur Programmiersprache nicht herum kommt - direkt nur PHP-Beispiele verwenden und deshalb PHP als Rubrik wählen.

so, wie man z. B. keine "Fahrschule" mehr macht, sondern zum Beispiel einen "Golfkurs". ;-)

Viele Grüße

Jörg

BTW:

"Der Text enthält drei oder mehr gleiche Zeichen hintereinander oder enthält keine Satzzeichen (-2.00 Punkte)."

Ups, wo sind die denn?

"Der Betreff enthält nur große Buchstaben (-3.00 Punkte)."

Ja, ist klar.

[dedlfix]

Hi!

Ich glaube, du fasst das Thema von der falschen Seite her an.

Deine Argumente erscheinen mir sinnvoll. Ich werde deinen Gedanken bei mir noch etwas reifen lassen und zumindest den Anfang nochmal in diese Richtung gehend umarbeiten.

Lo!

[Sebastian]

Hi!

Recht häufig wird die Problematik des Kontextwechsels unbeachtet gelassen. Um nicht immer wieder das Gleiche erzählen zu müssen und dabei die Hälfte zu vergessen, schrieb ich einen SELFTHML-Aktuell-Artikel dazu.
Lo!

Kommt genau zur rechten Zeit für mich. Danke :-)

[Christoph Jeschke]

Guten Tag,

Und hier noch ein Link auf das entsprechende Kapitel im MySQL-Manual. Die deutsche Übersetzung ist übrigens fehlerhaft und sollte nicht verwendet werden.

Gruß
Christoph Jeschke

[Christoph Jeschke]

Guten Tag,

Sinnvollerweise ist meine erste Antwort nicht angekomme. Fehler in der Matrix?

Und hier noch ein Link auf das entsprechende Kapitel im
MySQL-Manual.
Die deutsche Übersetzung ist übrigens fehlerhaft und sollte nicht verwendet
werden.

Es geht darum, dass in MySQL - je nach Server-Modus - Double Quotes nicht mehr als String-Anführungszeichen verwendet werden dürfen. Dies ist immer dann der Fall, wenn ANSI_QUOTES aktiviert ist.

Gruß
Christoph Jeschke

[dedlfix]

Hi!

Es geht darum, dass in MySQL - je nach Server-Modus - Double Quotes nicht mehr als String-Anführungszeichen verwendet werden dürfen. Dies ist immer dann der Fall, wenn ANSI_QUOTES aktiviert ist.

SQL-Standard sind einfache Anführungszeichen. Dass MySQL auch doppelte annimmt, ist eine Eigenheit. In meinen Beispielen hab ich nur die einfachen verwendet. Da das eher ein Kompatibilitätsproblem als ein Kontextwechselproblem ist, würde ich das nicht weiter thematisieren.

Lo!

[globe]

n'abend,

SQL-Standard sind einfache Anführungszeichen. Dass MySQL auch doppelte annimmt, ist eine Eigenheit. In meinen Beispielen hab ich nur die einfachen verwendet. Da das eher ein Kompatibilitätsproblem als ein Kontextwechselproblem ist, würde ich das nicht weiter thematisieren.

Sind Backticks zur Identifier-Abgrenzung Standard oder MySQL-Proprietär? Diese Thematisierst du ja schliesslich auch. PostGreSQL will an der Stelle beispielsweise DoubleQuotes sehen, MSSQL SquareBrackets, and so on.

weiterhin schönen abend...

[Vinzenz Mai]

Hallo,

Sind Backticks zur Identifier-Abgrenzung Standard oder MySQL-Proprietär?

MySQL-proprietär und - wie ich finde - fürchterlich häßlich.

Diese Thematisierst du ja schliesslich auch. PostGreSQL will an der Stelle beispielsweise DoubleQuotes sehen, MSSQL SquareBrackets, and so on.

doppelte Anführungszeichen akzeptiert MS SQL-Server standardmäßig ebenfalls - siehe </archiv/2009/5/t186393/#m1237895>, auch wenn er bei seinem generierten SQL standardmäßig eckige Klammern nimmt.

Doppelte Anführungszeichen sind mit hoher Wahrscheinlichkeit Standard. Warum glaube ich das? Weil diese Einstellung in MySQL ANSI-Quotes heißt, siehe z.B. </archiv/2009/5/t186807/#m1241015>.

Freundliche Grüße

Vinzenz

[Christoph Jeschke]

Guten Tag,

ich war gestern etwas in Eile, deswegen wollte ich noch einen Dank für deine Mühen nachholen.

SQL-Standard sind einfache Anführungszeichen. Dass MySQL auch doppelte annimmt,
ist eine Eigenheit. In meinen Beispielen hab ich nur die einfachen verwendet.

Im Gegenteil: Die double quotes sind ANSI-Standard (aus diesem Grunde heißt der Modus auch ANSI_QUOTES). Man muss also den MySQL-Modus erst in einen standardgerechten Modus versetzen. Das ist prinzipiell eh eine gute Idee; MySQL verhält sich dann deutlich strenger.

Da das eher ein Kompatibilitätsproblem als ein Kontextwechselproblem ist, würde
ich das nicht weiter thematisieren.

Würde ich nicht so sehen: Wenn sich der Kontext der Quotes je nach Einstellung des Servers ändert, sollte schon erwähnt werden, dass double quotes den Kontext innerhalb der Datenbank ändern. Du erwähnst ja auch PHP-spezifische Settings, wie Magic Quotes.

Dies bringt mich auch gleich zu einem weiteren Punkt: Ich denke, es ist sinnvoll erst mal die vermutlich größte Basis an Interessenten, hier Webentwickler, die MySQL und PHP verwenden, anzusprechen. Nur solltes dies dann auch konsequent geschehen. Ich könnte mir vorstellen, dass man daraus langfristig sogar eine Artikelserie macht, die mit einer allgemeinen Einleitung zum Thema Kontextwechsel beginnt und dann im Weiteren auf die Details der jeweiligen Implementierung eingeht. So könnte es dann einen übergeordneten Artikel, einen für PHP und einen für MySQL geben.

Gruß
Christoph Jeschke

[dedlfix]

Hi!

Die double quotes sind ANSI-Standard (aus diesem Grunde heißt der Modus auch ANSI_QUOTES).

Aus dem Wort ANSI_QUOTES kann ich irgendwie nicht darauf schließen, welche damit gemeint sind. Das MySQL-Handbuch jedenfalls sagt, dass damit die single quotes als alleinige Möglichkeit für Strings eingeschaltet werden. Die double quotes sind dann die Quote-Zeichen für Identifier.

Man muss also den MySQL-Modus erst in einen standardgerechten Modus versetzen. Das ist prinzipiell eh eine gute Idee; MySQL verhält sich dann deutlich strenger.

Aber was nützt mir das? Dass ich mich auf die Standard-Zeichengebung "einschränken" muss? Das sähe ich ja noch ein, wenn ich von einem Standard-System komme und dauernd " statt ` tippe. Aber wenn ich nie die Absicht habe, das Projekt von MySQL wegzubewegen ... Also, warum ist das eine gute Idee und warum prinzipiell?

Da das eher ein Kompatibilitätsproblem als ein Kontextwechselproblem ist, würde ich das nicht weiter thematisieren.

Würde ich nicht so sehen: Wenn sich der Kontext der Quotes je nach Einstellung des Servers ändert, sollte schon erwähnt werden, dass double quotes den Kontext innerhalb der Datenbank ändern. Du erwähnst ja auch PHP-spezifische Settings, wie Magic Quotes.

Solange ich hier im Forum mitlese ist mir noch nie aufgefallen, dass jemand aufgrund des ANSI_QUOTES-Modus Kontextwechselnichtbeachtungsprobleme bekam. Noch nicht mal dass den jemand ernsthaft nutzt.

Es mag ein Problem sein, wenn jemand die falschen Zeichen am falschen Ort verwendet und daraufhin mit den falschen Maskierfunktionen die Werte bearbeitet. Doch das wird eher auffallen, weil der Programmteil generell nicht wie gewünscht arbeitet und weniger weil bestimmte Daten ein Problem bereiten. (Und wem das nicht auffällt testet seine Programme nicht genug.)

Es kommt mir nicht darauf an, den Artikel mit allen möglichen Konstellationen zu (über)füllen. Es sollte schon eine gewisse Relevanz haben und die Leser hauptsächlich für die Problematik als solche sensibilisieren. In Relevanzsinne habe ich die Magic Quotes aufgenommen, weil die leider immer noch ein signifikantes Problem sind.

Lo!

[Christoph Jeschke]

Guten Tag,

Aus dem Wort ANSI_QUOTES kann ich irgendwie nicht darauf schließen, welche damit gemeint sind. Das MySQL-Handbuch jedenfalls sagt, dass damit die single quotes als alleinige Möglichkeit für Strings eingeschaltet werden. Die double quotes sind dann die Quote-Zeichen für Identifier.

Und im Nicht-ANSI_QUOTES-Modus funktionieren die Quotes eben in einem anderen Kontext. Und da der Kontext je nach Einstellung wechselt, sollte das zumindest vermerkt sein.

Aber was nützt mir das? Dass ich mich auf die Standard-Zeichengebung "einschränken" muss? Das sähe ich ja noch ein, wenn ich von einem Standard-System komme und dauernd " statt ` tippe. Aber wenn ich nie die Absicht habe, das Projekt von MySQL wegzubewegen ... Also, warum ist das eine gute Idee und warum prinzipiell?

Der TRADITIONAL-Modus, der MySQL zu einem strikteren Verhalten zwingt, bezieht sich nicht nur auf die Quotes, sondern z.B. auch darauf, wie MySQL auf Fehler reagiert (z.B. erzeugt MySQL in gewissen Fällen einfach nur eine Warnung und setzt die Verarbeitung trotzdem fort, wo es sinnvoll wäre, die Verarbeitung abzubrechen. Oder MySQL versucht bei falschen Typen oder einem Wertebereichüberlauf, den Wert zu einem möglichst passenden Wert zu konvertieren). So ein Verhalten kann gewünscht sein, es kann aber auch geändert werden. Ich vermute einfach mal, dass die meisten Nutzer gar nicht wissen, dass man MySQL so (um)konfigurieren kann.

Solange ich hier im Forum mitlese ist mir noch nie aufgefallen, dass jemand aufgrund des ANSI_QUOTES-Modus Kontextwechselnichtbeachtungsprobleme

Ich mag Komposita ;-)

bekam. Noch nicht mal dass den jemand ernsthaft nutzt.

Da würde ich dir zustimmen. Ich bin schon glücklich, wenn dies jemand liest und ggf. auf die Idee kommt, nach dem Modus zu schauen.

Es mag ein Problem sein, wenn jemand die falschen Zeichen am falschen Ort verwendet und daraufhin mit den falschen Maskierfunktionen die Werte bearbeitet. Doch das wird eher auffallen, weil der Programmteil generell nicht wie gewünscht arbeitet und weniger weil bestimmte Daten ein Problem bereiten. (Und wem das nicht auffällt testet seine Programme nicht genug.)

Nun, das ist ja eh immer das Problem. Auch wer Probleme mit den magic_quotes_* bekommt, hat sein Programm nicht ausreichend getestet.

Es kommt mir nicht darauf an, den Artikel mit allen möglichen Konstellationen zu (über)füllen. Es sollte schon eine gewisse Relevanz haben und die Leser hauptsächlich für die Problematik als solche sensibilisieren. In Relevanzsinne habe ich die Magic Quotes aufgenommen, weil die leider immer noch ein signifikantes Problem sind.

Aus diesem Grund schlug ich vor, den Artikel in mehrere, thematisch zusammenhängende Artikel zu teilen, so bald weitere Systeme (egal ob Programmiersprachen, Datenbanken oder sonstwas) behandelt werden.

Gruß
Christoph Jeschke

[dedlfix]

Hi!

Und im Nicht-ANSI_QUOTES-Modus funktionieren die Quotes eben in einem anderen Kontext. Und da der Kontext je nach Einstellung wechselt, sollte das zumindest vermerkt sein.

Das sind nicht die Art Kontextwechsel, die mit dem Artikel gemeint sind. Denn dann müsste beispielsweise auch ein Wechsel des DBMS von MySQL zu PostgreSQL thematisiert werden. Ist ja auch ein anderer Kontext. Der ANSI_QUOTES-Modus ändert nichts am Prinzip und der Vorgehensweise. mysql_real_escape_string() kann weiterverwendet werden und bei den Identifiern ist immer noch das Quote-Zeichen zu verdoppeln.

Der TRADITIONAL-Modus, der MySQL zu einem strikteren Verhalten zwingt, bezieht sich nicht nur auf die Quotes,

Streiche "nur", denn dafür ist ANSI_QUOTES zuständig und nicht TRADITIONAL.

sondern z.B. auch darauf, wie MySQL auf Fehler reagiert (z.B. erzeugt MySQL in gewissen Fällen einfach nur eine Warnung und setzt die Verarbeitung trotzdem fort, wo es sinnvoll wäre, die Verarbeitung abzubrechen. Oder MySQL versucht bei falschen Typen oder einem Wertebereichüberlauf, den Wert zu einem möglichst passenden Wert zu konvertieren). So ein Verhalten kann gewünscht sein, es kann aber auch geändert werden. Ich vermute einfach mal, dass die meisten Nutzer gar nicht wissen, dass man MySQL so (um)konfigurieren kann.

Gut, das ware ein Argument. Jedoch eins für TRADITIONAL und nicht für ANSI_QUOTES. Du schweifst ab :-)

Ich bin schon glücklich, wenn dies jemand liest und ggf. auf die Idee kommt, nach dem Modus zu schauen.

Aber welchen genau meinst du nun? Es gibt derer ja noch eine ganze Menge. Und kombinieren kann man sie auch, wenn man will.

Auch wer Probleme mit den magic_quotes_* bekommt, hat sein Programm nicht ausreichend getestet.

Das Problem der Magic Quotes ist aber eins, das man (als Anfänger) nicht unbedingt kennt. In den ANSI_QUOTES-Modus zu schalten passiert hingegen mit Absicht.

Lo!

[jobo]

Hallo dedlfix,

Svens Argumentation kann ich nicht folgen, zumal ich denke, man sollte dem grundelegenden Ansatz eines Autoren erst einmal folgen und nicht herangehen mit: "ich würde das ganz anders machen". Ich finde den Artikel stringent und auch im richtigen Thema angesiedelt, denn die kontextspezifische Maskierung betrifft ja, wie du sagst, gerade die Übergänge. Dein Beispiel ist klar und betrifft genau die Lücke, die immer wieder in Forumsfragen erörtert wirde, inklusive eine Beispiel für SQL-Injektion. Zu detaillierterem Lektorat bin ich jetzt nicht gekommen, wollte aber mal dem Grunde nach o.g. positives, verstärkendes Feedback geben.

Gruß

jobo

[dedlfix]

Hi!

Hallo dedlfix,

Svens Argumentation kann ich nicht folgen, zumal ich denke, man sollte dem grundelegenden Ansatz eines Autoren erst einmal folgen und nicht herangehen mit: "ich würde das ganz anders machen".

Einen passenden und zum Weiterlesen anregenden Einstieg in ein Thema zu finden, fällt mir nicht unbedingt leicht. Aufsätze schreiben mochte ich noch nie, doch das Antworten im Forum hat mich auch in der Richtung geschult, finde ich. So wie die Einleitung jetzt ist, gefällt sie mir selbst noch nicht richtig. Der erste externe Anregung ist jedoch schon eingeflossen. Was den Aufbau angeht, hat sicher jeder seine eigenen Gedanken. Die meinigen müssen nicht immer die besten sein. Andere Gedankengänge heiße ich durchaus als Inspiration dankbar willkommen.

Lo!

[Alexander (HH)]

Moin Moin!

Ich vermisse ein Beispiel zu Prepared Statements.

Ich vermisse die Aussage, dass man bei zusammengeklebten Statements sich sehr leicht SQL Injections einfängt, wenn man versehentlich nicht die richtige Quoting-Funktion benutzt (von denen es in PHP wohl einen ganzen Haufen gibt) oder den Funktionsaufruf rund um jeden einzelnen Parameter bei auch nur einem Parameter vergißt.

Ich vermisse die Aussage, dass bei Prepared Statements das Quoting-Problem wegfällt und damit das Risiko der SQL-Injection wegfällt.

Ein Beispiel für SQL-Injection fehlt ebenfalls.

Der ganze Absatz rund um die Prepared Statements kann leicht so gelesen werden, dass Prepared Statements eigentlich eine unnütze Erfindung sind, die man besser durch die altbewährte Cargo-Cult-Programmierung ersetzt. Selbst wenn PHP für jeden Request eine neue DB-Connection öffnet, kann die DB selbst die Prepared Statements unabhängig von der Connection cachen und sich das tausendfache Neuparsen des selben Statements verkneifen -- und wenn nicht die DB, dann ein dazwischen geschaltetes Stückchen Software, z.B. zum Connection Pooling.

Prepared Statements sind sinnvoll, wenn man mehrere Datensätze schreiben will: prepare, execute for each record, finish. Sie sind auch sinnvoll, wenn man mehrere, bis auf die Parameter identische Abfragen laufen lassen will.

Ich sehe nur PHP und MySQL. Zugegeben, das ist die Standard-Lösung aller Billig- und Massenhoster. Aber es gibt noch andere Datenbanken (wie müßte da die entsprechende Quote-Funktion heißen?) und es gibt noch andere Programmiersprachen für die Serverseite (Perl, Ruby, Java, ...), die exakt die selben Kontextwechsel-Probleme haben.

Alexander

[Alexander (HH)]

Ein Beispiel für SQL-Injection fehlt ebenfalls.

Sorry, das ist natürlich drin, nur nicht da, wo ich es erwartet habe.

Alexander

[dedlfix]

Hi!

Ein Beispiel für SQL-Injection fehlt ebenfalls.
Sorry, das ist natürlich drin, nur nicht da, wo ich es erwartet habe.

Das kann ich schlecht dahin bringen, wo du es erwartest (aus welchem Grund auch immer), wenn du mir diese Stelle nicht nennst. Hast du es bei der Aufzählung der anderen Kontextwechsel gesucht? Ich werde dort noch einen Verweis einbauen.

Lo!

[Alexander (HH)]

Moin Moin!

Hi!

Ein Beispiel für SQL-Injection fehlt ebenfalls.
Sorry, das ist natürlich drin, nur nicht da, wo ich es erwartet habe.

Das kann ich schlecht dahin bringen, wo du es erwartest (aus welchem Grund auch immer), wenn du mir diese Stelle nicht nennst.

Richtig. Das ich das Beispiel anfangs nicht gefunden habe, lag schlicht und ergreifend daran, dass ich den Text nicht linear von vorne nach hinten gelesen habe, sondern wild hin und her gesprungen bin. So hab ich erst "Verhindernde Maßnahmen" gelesen und erst später "Fehler und deren Auswirkungen". Wenn man den Text linear liest, ist das Beispiel schon an der richtigen Stelle.

Alexander

[dedlfix]

Hi!

Wenn man den Text linear liest, ist das Beispiel schon an der richtigen Stelle.

Auch gut. Sagt dir der Abschnitt zu den Prepared Statements nun eher zu?

P.S. Der Abschnitt zu den falsch erkannten Kontextwechseln (und der zu den Magic Quotes) ist in meiner Arbeitsversion aufgelöst und deren Unterabschnitte sind zu den anderen gewandert. Durch die angewachsene Größe des Artikels wurde der Abstand größer und dann übersieht man sie sicher ebenso leicht, wenn man selektiv liest.

Lo!

[Alexander (HH)]

Moin Moin!

Sagt dir der Abschnitt zu den Prepared Statements nun eher zu?

Ja.

P.S. Der Abschnitt zu den falsch erkannten Kontextwechseln (und der zu den Magic Quotes) ist in meiner Arbeitsversion aufgelöst und deren Unterabschnitte sind zu den anderen gewandert. Durch die angewachsene Größe des Artikels wurde der Abstand größer und dann übersieht man sie sicher ebenso leicht, wenn man selektiv liest.

Klingt erstmal gut. Machst Du noch eine Kennzeichnung dran? Sowas wie "Achtung:", "Falle:", oder schlicht ein Warndreieck?

Alexander

[dedlfix]

Hi!

P.S. Der Abschnitt zu den falsch erkannten Kontextwechseln [...]
Machst Du noch eine Kennzeichnung dran? Sowas wie "Achtung:", "Falle:", oder schlicht ein Warndreieck?

Gute Idee, mal sehen, wie sich das mit den SELFHTML-Layoutregeln lösen lässt.

Lo!

[Vinzenz Mai]

Hallo Alexander,

Ich vermisse [...]
Ich vermisse [...]
Ich vermisse [...]
Ein Beispiel für SQL-Injection fehlt ebenfalls.

[...]

ich vermisse bei Dir positive und konstruktive Rückmeldung für jemanden, der sich Arbeit gemacht hat, um einen wichtigen Themenbereich aufzubereiten [1], [2].
Und nein, ich habe nichts positives aus Deinem Beitrag gelöscht - es war nichts da.

So sieht konstruktive Kritik meiner Meinung nach nicht aus - und ich kann Dir nur zurufen: "Mach's besser!" Oder nicht so fordernd: "Mach' überhaupt was!".

Konstruktive Grüße

Vinzenz

[1] Vollständigkeit kann meiner Meinung nach nicht angestrebt werden.
[2] Zitat aus der Einleitung:
    "Der Artikel beschäftigt sich mit der Erkennung und Behandlung der
     häufigsten Kontextwechsel im Web."

[jobo]

Hallo,

Ich vermisse [...]
Ich vermisse [...]
Ich vermisse [...]
Ein Beispiel für SQL-Injection fehlt ebenfalls.
[...]

ich vermisse bei Dir positive und konstruktive Rückmeldung für jemanden, der sich Arbeit gemacht hat, um einen wichtigen Themenbereich aufzubereiten [1], [2].

Auf die Gefahr mich hier zum dritten Mal zu wiederholen: Full ACK oder wie man sonst so online sagt! [Wobei ich Alexanders Anhaltspunkte als durchaus einbaubar und konstruktiv umwandelbar gelesen habe]

Gruß

jobo

[Alexander (HH)]

Moin Moin!

ich vermisse bei Dir positive und konstruktive Rückmeldung

Oh ja, wir haben uns alle ganz fürchterlich lieb und schreiben das deswegen auch jedes Mal mit in die Postings, damit wir das nicht vergessen.

Und nein, ich habe nichts positives aus Deinem Beitrag gelöscht - es war nichts da.

Nee, beim zweiten oder dritten "Ich vermisse" warst Du so fürchterlich eingeschnappt und stellvertretend beleidigt angesichts der nicht ganz kuschelig-liebhabenden Formulierungen, dass Du statt Inhalten nur noch auf Formulierungen rumhacken konntest.

So sieht konstruktive Kritik meiner Meinung nach nicht aus

Ich hab aufgeschrieben, was mir in dem Artikel fehlt. Natürlich hätte ich das in ein kuschelweiches "Du könntest ... ergänzen" einpacken können. Ich hätte es auch als Gedicht formulieren können, oder als Liebeslied. Hab ich aber nicht.

• und ich kann Dir nur zurufen [...]
  Konstruktive Grüße

Sanfte Grüße,
Alexander <--- packt das Strickzeug aus

[dedlfix]

Hi!

ich vermisse bei Dir positive und konstruktive Rückmeldung für jemanden, der sich Arbeit gemacht hat, um einen wichtigen Themenbereich aufzubereiten [1], [2].
Und nein, ich habe nichts positives aus Deinem Beitrag gelöscht - es war nichts da.

Ach weißt du, sachlich bleiben reicht. Ich antworte auf mir vorgetragene Argumente auch nicht immer mit Samthandschuhen. Manchmal sieht es auch so aus, als ob ich sie ablehne. Doch oft ist es eher der Fall, dass ich nur nicht davon überzeugt bin. Mit den passenden nachvollziehbaren Argumenten bin ich durchaus umzustimmen. Man darf sich nur nicht zu schnell entmutigen lassen.

Lo!

[dedlfix]

Hi!

Ich vermisse ein Beispiel zu Prepared Statements.

Ich wollte die Prepared-Statements-Thematik nicht zu sehr ausbauen. Damit und mit den Eigenheiten und Unterschieden zwischen mysqli und PDO kann man gut einen eigenen Artikel füllen.

Ich vermisse die Aussage, dass man bei zusammengeklebten Statements sich sehr leicht SQL Injections einfängt, wenn man versehentlich nicht die richtige Quoting-Funktion benutzt (von denen es in PHP wohl einen ganzen Haufen gibt) oder den Funktionsaufruf rund um jeden einzelnen Parameter bei auch nur einem Parameter vergißt.

Egal, welche der in Frage kommenden Funktionen (mysql_escape_string, mysql(i)_real_escape_string und auch addslashes) man verwendet, die kritischen Zeichen sind damit abgedeckt. Der Unterschied zwischen addslashes und mysql_(real_)escape_string ist eher kosmetischer Natur - siehe den geklammerten Satz "Strictly speaking ...".

Es gibt ein Problem mit hierzulande nicht üblichen Mehrbytekodierungen. Wenn da die MySQL-Client-API nicht auf korrektem Weg die Kodierung mitgeteilt bekommen hat, maskiert sie falsch. Mit ISO-8859-x und UTF-8 ist das Problem jedoch nicht existent.

Ich vermisse die Aussage, dass bei Prepared Statements das Quoting-Problem wegfällt und damit das Risiko der SQL-Injection wegfällt.
Ein Beispiel für SQL-Injection fehlt ebenfalls.

Ist beides drin. Das Problem beim Kontextwechsel ist nicht primär der Sicherheitsaspekt. Deswegen reite ich auch nicht zu sehr auf dieser "Dramatik" rum.

Der ganze Absatz rund um die Prepared Statements kann leicht so gelesen werden, dass Prepared Statements eigentlich eine unnütze Erfindung sind, die man besser durch die altbewährte Cargo-Cult-Programmierung ersetzt.

Es ist Mehraufwand, der sich nicht in jedem Fall lohnt. Erheblich wird der Mehraufwand unter mysqli, wenn das Statement auch noch erst zur Laufzeit zusammengebaut werden soll. Der Wiederverwendbarkeitsvorteil ist damit auch aus dem Rennen.

Selbst wenn PHP für jeden Request eine neue DB-Connection öffnet, kann die DB selbst die Prepared Statements unabhängig von der Connection cachen und sich das tausendfache Neuparsen des selben Statements verkneifen -- und wenn nicht die DB, dann ein dazwischen geschaltetes Stückchen Software, z.B. zum Connection Pooling.

Wie soll das gehen? Nach dem Prepare bekommt man ein Handle auf das PS. Mit diesem Handle bindet und executiert man. Das Handle wird spätestens am Requestende entsorgt. Ich wüsste nicht (alles kann ich auch nicht wissen), dass da bei MySQL (andere DBMS kenne ich nicht intensiv genug) noch ein Statement-Cache existiert, der mir dann das "alte" Handle wieder besorgt. Der normale Query-Cache jedenfalls vergleicht die SQL-Statements erst nach der Platzhalter-Ersetzung. Alles andere wäre ja auch nicht sinnvoll, weil das Ergebnis ja von diesen Werten abhängig ist.

Prepared Statements sind sinnvoll, wenn man mehrere Datensätze schreiben will: prepare, execute for each record, finish. Sie sind auch sinnvoll, wenn man mehrere, bis auf die Parameter identische Abfragen laufen lassen will.

Ja, das schrieb ich, dass das ihre eigentliche Intention ist. Wer dafür Bedarf hat, kann sie ruhig einsetzen. Die Intention des Artikels ist jedoch Kontextwechsel und nicht Performance. Schon deshalb will ich nicht zu sehr in Details der PS gehen.

Ich sehe nur PHP und MySQL. Zugegeben, das ist die Standard-Lösung aller Billig- und Massenhoster. Aber es gibt noch andere Datenbanken (wie müßte da die entsprechende Quote-Funktion heißen?) und es gibt noch andere Programmiersprachen für die Serverseite (Perl, Ruby, Java, ...), die exakt die selben Kontextwechsel-Probleme haben.

Wer für das Thema erst einmal sensibilisiert ist, wird sich die entsprechenden Funktionen in anderen Systemen raussuchen können, finde ich. Da ich nicht mit allen DBMS-Schnittstellen Erfahrung habe, möchte ich dazu auch nichts sagen. Manche sind auch zu exotisch. Der Artikel sollte auch nicht zu voll werden.

Lo!

[Alexander (HH)]

Moin Moin!

Mal vorweg: Ich arbeite seit Jahren mit Perl und DBI, wo Prepared Statements und Platzhalter der empfohlene Weg sind, von dem man nur in besonderen Ausnahmefällen abweichen sollte.

Ich vermisse ein Beispiel zu Prepared Statements.

Ich wollte die Prepared-Statements-Thematik nicht zu sehr ausbauen. Damit und mit den Eigenheiten und Unterschieden zwischen mysqli und PDO kann man gut einen eigenen Artikel füllen.

Ich wollte ja keine 100 Beispiele. Ein einziges, in etwa wie ...

  
my $sth=$dbh->prepare('select foo,bar from baz where bla=?');  
$sth->execute($bla);  
while (my $data=$sth->fetchrow_hashref()) {  
  print $data->{'foo'},' => ',$data->{'bar'},"\n";  
}  
$sth->finish();  

... und dazu ein Satz wie "Egal welchen Wert $bla annimmt, ist SQL Injection unmöglich, ohne dass manuelles Quoting nötig ist."

Ich vermisse die Aussage, dass man bei zusammengeklebten Statements sich sehr leicht SQL Injections einfängt, wenn man versehentlich nicht die richtige Quoting-Funktion benutzt (von denen es in PHP wohl einen ganzen Haufen gibt) oder den Funktionsaufruf rund um jeden einzelnen Parameter bei auch nur einem Parameter vergißt.

Egal, welche der in Frage kommenden Funktionen (mysql_escape_string, mysql(i)_real_escape_string und auch addslashes) man verwendet, die kritischen Zeichen sind damit abgedeckt.

Keine Kritik an Dir, sondern an PHP: Quoting-Funktionen einzeln für jede einzelne DB und jedes einzelne Interface ist Krampf.

DBI hat eine(!) Quote-Methode, die Werte passend quotet. DBI definiert eine Basis-Methode, die für die meisten DBs paßt, Die einzelnen DB-Treiber können bei Bedarf ihre eigene Methode definieren. Aber egal wie, es endet immer damit, my $quotedValue=$dbh->quote($value); zu schreiben, unabhängig von der Datenbank. Genau dieser Mechanismus greift auch, wenn eine Datenbank Prepared Statements nicht unterstützt: In dem Fall wird das SQL-Statement von prepare() einfach nur gespeichert und execute() ersetzt die Platzhalter durch gequotete Werte.

(DBI hat übrigens eine zweite Quote-Methode, die sich um das richige Quoten von Identifiern wie Tabellen- und Spaltennamen kümmert. Auch wieder komplett unabhängig von der DB.)

Der Unterschied zwischen addslashes und mysql_(real_)escape_string ist eher kosmetischer Natur - siehe den geklammerten Satz "Strictly speaking ...".

OK. (Wobei ich es schon merkwürdig finde, dass man sich beim Schreiben von SQL-Statements bzw. Programmcode Sorgen um das Log-Format des DB-Servers machen soll. Naja, MySQL-Philosophie halt ...)

Ich vermisse die Aussage, dass bei Prepared Statements das Quoting-Problem wegfällt und damit das Risiko der SQL-Injection wegfällt.
[...] Das Problem beim Kontextwechsel ist nicht primär der Sicherheitsaspekt. Deswegen reite ich auch nicht zu sehr auf dieser "Dramatik" rum.

Ich denke, Du solltest darauf herumreiten. SQL Injections kommen genau durch verpaßte Kontext-Wechsel zustande, genau wie Code Injections und Shell Injections.

Der ganze Absatz rund um die Prepared Statements kann leicht so gelesen werden, dass Prepared Statements eigentlich eine unnütze Erfindung sind, die man besser durch die altbewährte Cargo-Cult-Programmierung ersetzt.

Es ist Mehraufwand, der sich nicht in jedem Fall lohnt.

Schon alleine, weil man sich nicht fehlerträchtig selbst um das Quoting von Parametern kümmern muß und damit SQL-Injections garantiert und automatisch verhindert werden, lohnt sich der Weg über Prepared Statements. Ein Kontext-Wechsel weniger, um den man sich kümmern muß.

Erheblich wird der Mehraufwand unter mysqli, wenn das Statement auch noch erst zur Laufzeit zusammengebaut werden soll.

Irgendetwas verstehe ich hier nicht. Wo ist der Mehraufwand? sprintf und prepare unterscheiden sich nur im Platzhalter-Zeichen, quoting jedes einzelnen Parameters entfällt, do() wird durch execute() ersetzt.

Der Wiederverwendbarkeitsvorteil ist damit auch aus dem Rennen.

Wir scheinen aneinander vorbei zu reden.

Selbst wenn PHP für jeden Request eine neue DB-Connection öffnet, kann die DB selbst die Prepared Statements unabhängig von der Connection cachen und sich das tausendfache Neuparsen des selben Statements verkneifen -- und wenn nicht die DB, dann ein dazwischen geschaltetes Stückchen Software, z.B. zum Connection Pooling.

Wie soll das gehen? Nach dem Prepare bekommt man ein Handle auf das PS. Mit diesem Handle bindet und executiert man.

Du kannst execute() mit dem selben Handle mehrfach aufrufen. (Jedenfalls kann DBI das.)

Das Handle wird spätestens am Requestende entsorgt.

Nö, beim expliziten Aufruf von finish() oder implizit wenn $sth aus dem Scope läuft.

Ich wüsste nicht (alles kann ich auch nicht wissen), dass da bei MySQL (andere DBMS kenne ich nicht intensiv genug) noch ein Statement-Cache existiert, der mir dann das "alte" Handle wieder besorgt.

Du brauchst kein altes Handle.

Der normale Query-Cache jedenfalls vergleicht die SQL-Statements erst nach der Platzhalter-Ersetzung. Alles andere wäre ja auch nicht sinnvoll, weil das Ergebnis ja von diesen Werten abhängig ist.

Das ist MySQL, da funktioniert vieles etwas anders als bei anderen (ich bin versucht, "richtgen" zu schreiben) RBDMS.

Andere RDBMS parsen beim prepare() das SQL-Statement mit Platzhaltern, bauen daraus eine interne Repräsentation auf, wie sie durch die Tabellen graben wollen, und setzten für jeden Lauf von execute() nur noch die Werte in die interne Repräsentation ein. Das SQL-Statement mit Platzhalten kann zusammen mit der internen Repräsentation (ggf. auch über Session-Grenzen hinweg) im Speicher gehalten werden, so dass bei einem erneuten prepare() mit einem identischen Statement der SQL-Parser gar nicht erst gestartet wird.

DBI bietet mit prepare_cached() einen ähnlichen, anwendungsseitigen Cache an, der allerdings pro identischem Statement ein Handle belegt.

Ich sehe nur PHP und MySQL. Zugegeben, das ist die Standard-Lösung aller Billig- und Massenhoster. Aber es gibt noch andere Datenbanken (wie müßte da die entsprechende Quote-Funktion heißen?) und es gibt noch andere Programmiersprachen für die Serverseite (Perl, Ruby, Java, ...), die exakt die selben Kontextwechsel-Probleme haben.

Wer für das Thema erst einmal sensibilisiert ist, wird sich die entsprechenden Funktionen in anderen Systemen raussuchen können, finde ich.

OK. Vielleicht ergänzt Du dann den Titel um "in PHP" bzw. "mit PHP"?

Da ich nicht mit allen DBMS-Schnittstellen Erfahrung habe, möchte ich dazu auch nichts sagen. Manche sind auch zu exotisch. Der Artikel sollte auch nicht zu voll werden.

Genau das ist der Unterschied zwischen PHPs Datenbank-Anbindung und DBI. Mit DBI muß ich keine Erfahrungen mit unterschiedlichen Datenbanken haben. So lange ich keine DB-spezifischen SQL-Erweiterungen benutze, ist DBI-basierender Code komplett von der DB und der DB-Schnittstelle unabhängig, die einzige notwendige Änderung für die Migration auf eine andere DB ist der Connect-String, der ohnehin meistens in einer Konfigurationsdatei steht.

Alexander

[dedlfix]

Hi!

Ich wollte ja keine 100 Beispiele. Ein einziges, in etwa wie ...

Gibts im PHP-Handbuch zu den entsprechenden Funktionen. Ich spare mir das. Vielleicht verlinke ich noch die Beispielseite direkt.

... und dazu ein Satz wie "Egal welchen Wert $bla annimmt, ist SQL Injection unmöglich, ohne dass manuelles Quoting nötig ist."

Ist drin.

Keine Kritik an Dir, sondern an PHP: Quoting-Funktionen einzeln für jede einzelne DB und jedes einzelne Interface ist Krampf.

Das liegt an den einzeln hinzugefügten Extensions für die verschiedenen DBMS. Es gibt ja PDO, das eine einigermaßen einheitliche Oberfläche bereitstellt.

Ich vermisse die Aussage, dass bei Prepared Statements das Quoting-Problem wegfällt und damit das Risiko der SQL-Injection wegfällt.
[...] Das Problem beim Kontextwechsel ist nicht primär der Sicherheitsaspekt. Deswegen reite ich auch nicht zu sehr auf dieser "Dramatik" rum.

Ich denke, Du solltest darauf herumreiten. SQL Injections kommen genau durch verpaßte Kontext-Wechsel zustande, genau wie Code Injections und Shell Injections.

Wenn der Sicherheitsaspekt zu sehr im Vordergrund steht, denkt jeder nur an Sicherheitsaspekte. "Hier kommen meine Daten aus einer sicheren Quelle, da maskiere ich jetzt mal nichts" - solche Denkweise will ich durch das allgemeine und nicht nur sicherheitsspezifische Sensibilisieren erreichen.

Erheblich wird der Mehraufwand unter mysqli, wenn das Statement auch noch erst zur Laufzeit zusammengebaut werden soll.
Irgendetwas verstehe ich hier nicht. Wo ist der Mehraufwand? sprintf und prepare unterscheiden sich nur im Platzhalter-Zeichen, quoting jedes einzelnen Parameters entfällt, do() wird durch execute() ersetzt.

Es ist unter mysqli nicht vorgesehen, ein Array von Werten zu binden, nur einzelne Variablen. Wenn man eine unbestimmte Anzahl Werte hat, muss man das sehr umständlich programmieren. Da kommt man wesentliche einfacher mit dem Selbst-Quoten und -Maskieren.

Du kannst execute() mit dem selben Handle mehrfach aufrufen. (Jedenfalls kann DBI das.)

Das Handle wird spätestens am Requestende entsorgt.
Nö, beim expliziten Aufruf von finish() oder implizit wenn $sth aus dem Scope läuft.

Am Requestende ist unter PHP auch der Scope zu Ende. Punkt. Da ist nichts mit Wiederverwendbarkeit von Ressourcen.

Der normale Query-Cache jedenfalls vergleicht die SQL-Statements erst nach der Platzhalter-Ersetzung. Alles andere wäre ja auch nicht sinnvoll, weil das Ergebnis ja von diesen Werten abhängig ist.
Das ist MySQL, da funktioniert vieles etwas anders als bei anderen (ich bin versucht, "richtgen" zu schreiben) RBDMS.

Der Query-Cache speichert die Ergebnismenge. Die ist abhängig von den übergebenen WHERE-Parametern. Das ist in jedem DBMS so.

Wer für das Thema erst einmal sensibilisiert ist, wird sich die entsprechenden Funktionen in anderen Systemen raussuchen können, finde ich.
OK. Vielleicht ergänzt Du dann den Titel um "in PHP" bzw. "mit PHP"?

Der Artikel ist ja nun auch unter PHP angesiedelt.

Da ich nicht mit allen DBMS-Schnittstellen Erfahrung habe, möchte ich dazu auch nichts sagen. Manche sind auch zu exotisch. Der Artikel sollte auch nicht zu voll werden.

Ist nun doch "zu voll" geworden ...

Genau das ist der Unterschied zwischen PHPs Datenbank-Anbindung und DBI. Mit DBI muß ich keine Erfahrungen mit unterschiedlichen Datenbanken haben. So lange ich keine DB-spezifischen SQL-Erweiterungen benutze, ist DBI-basierender Code komplett von der DB und der DB-Schnittstelle unabhängig, die einzige notwendige Änderung für die Migration auf eine andere DB ist der Connect-String, der ohnehin meistens in einer Konfigurationsdatei steht.

Wenn du dabei nur den Perl-Code im Auge hast, so mag das stimmen. SQL-Dialekte und Features sind aber zu unterschiedlich, um nur mit einem Connectionstring-Ändern komplett auf ein anderes DBMS umstellen zu können. Wenn man mehr als 0815-Abfragen gegen das DBMS sendet, bleibt das ein unrealistisches Wunschdenken.

Lo!

[dedlfix]

Hi!

Ich wollte ja keine 100 Beispiele. Ein einziges, in etwa wie ...
Gibts im PHP-Handbuch zu den entsprechenden Funktionen. Ich spare mir das. Vielleicht verlinke ich noch die Beispielseite direkt.

Ist in meiner Arbeitsversion bereits verlinkt.

Wenn der Sicherheitsaspekt zu sehr im Vordergrund steht, denkt jeder nur an Sicherheitsaspekte. "Hier kommen meine Daten aus einer sicheren Quelle, da maskiere ich jetzt mal nichts" - solche Denkweise will ich durch das allgemeine und nicht nur sicherheitsspezifische Sensibilisieren erreichen.

"Dass sich eine solche Denkweise nicht erst einschleicht, weil ich ..." sollte es passenderweise heißen.

Du kannst execute() mit dem selben Handle mehrfach aufrufen. (Jedenfalls kann DBI das.)

Das Handle wird spätestens am Requestende entsorgt.
Nö, beim expliziten Aufruf von finish() oder implizit wenn $sth aus dem Scope läuft.

Am Requestende ist unter PHP auch der Scope zu Ende. Punkt. Da ist nichts mit Wiederverwendbarkeit von Ressourcen.

Besser als das "Da" wäre ein "Danach" gewesen. Innerhalb des Scripts kann man natürlich mehrfach exekutieren. Doch das hat man deutlich seltener als die Fälle, dass ein Statement nur einmal im Script benötigt wird.

Lo!

[Tom]

Hello,

ich Speicher steht dann ...

Beispiel mit " drin

ich wäre da eher für

66 101 105 115 112 105 101 108 32 109 105 116 32 34 32 100 114 105 110

Denn auch das Holen der Bytes aus dem Speicher und Darstellen als Glyphen ist ein Kontextwechsel!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

ich Speicher steht dann ...
     Beispiel mit " drin
ich wäre da eher für
     66 101 105 115 112 105 101 108 32 109 105 116 32 34 32 100 114 105 110

Ich will es nicht zu wissenschaftlich machen. Dann könnte ich auch die Binärdarstellung oder gleich Spannungs- oder Magnetisierungszustände nehmen. :-) Es soll vor allem auch für Anfänger verständlich sein. Meinst du, man versteht das mit den Codes besser als mit den Zeichen, die man eigentlich im Sinn hat? Ich werde als Klammerbemerkung sowas wie "(besser gesagt: die Codes der Zeichen)" hinzufügen. Das muss an Genauigkeit reichen.

Lo!

[Tom]

Hello,

ich Speicher steht dann ...
     Beispiel mit " drin
ich wäre da eher für
     66 101 105 115 112 105 101 108 32 109 105 116 32 34 32 100 114 105 110

Ich will es nicht zu wissenschaftlich machen. Dann könnte ich auch die Binärdarstellung oder gleich Spannungs- oder Magnetisierungszustände nehmen. :-) Es soll vor allem auch für Anfänger verständlich sein. Meinst du, man versteht das mit den Codes besser als mit den Zeichen, die man eigentlich im Sinn hat?

Ja, ich meine, dass man an _dieser_ Stelle den Kontextwechsel bzw. das Herstellen eines Kontextbezuges noch am leichtesten versteht und schließlich führen doch alle Probleme immer wieder auf die Code(Points) zurück, auch nachher die Wahl der Codierung (ISO, UTF-x, ...)

Ich werde als Klammerbemerkung sowas wie "(besser gesagt: die Codes der Zeichen)" hinzufügen. Das muss an Genauigkeit reichen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

ich Speicher steht dann ...
     Beispiel mit " drin
ich wäre da eher für
     66 101 105 115 112 105 101 108 32 109 105 116 32 34 32 100 114 105 110

[...] Meinst du, man versteht das mit den Codes besser als mit den Zeichen, die man eigentlich im Sinn hat?

Ja, ich meine, dass man an _dieser_ Stelle den Kontextwechsel bzw. das Herstellen eines Kontextbezuges noch am leichtesten versteht

Gerade in einem Artikel, der sich an Anfänger richtet, halte ich das für kontraproduktiv.

Selbst wenn wir das als "Kontextwechsel" ansehen wollen - dann es ist einer, der weit ausserhalb meiner Reichweite als Ersteller eines PHP-Scriptes (o.ä.) liegt, und bei dem "ich" auch nichts machen muss.

$string = "Beispiel mit \" drin";

• an dieser Stelle muss ich in meinem Script die/eine korrekte Notierung wählen, damit der PHP-Parser mich versteht; darauf weist der Arikel korrekt hin.

Wie der PHP-Interpreter diesen Text jetzt an den die CPU/den Speicher übergibt und wie sie in letzterem abgelegt werden, ist für mich als Scriptschreiber a) absolut belanglos, und b) nicht mal ansatzweise beeinflussbar.

Wenn du diesen "Kontextwechsel" jetzt explizit im Artikel erwähnt sehen willst - dann halte ich das unter der darüber stehenden Faustregel

"Wann immer Daten in einen anderen Kontext eingefügt werden sollen, sind diese dem Kontext entsprechend zu behandeln."

für kontraproduktiv. Dem Anfänger wurde gerade gesagt, dass wir bei "jedem" Kontextwechsel aktiv etwas unternehmen müssen. Hier unternehmen wir aber nichts, hier können wir nicht mal was unternehmen.

MfG ChrisB

[Tom]

Hello,

l

"Wann immer Daten in einen anderen Kontext eingefügt werden sollen, sind diese dem Kontext entsprechend zu behandeln."
für kontraproduktiv. Dem Anfänger wurde gerade gesagt, dass wir bei "jedem" Kontextwechsel aktiv etwas unternehmen müssen. Hier unternehmen wir aber nichts, hier können wir nicht mal was unternehmen.

Doch, wir müssen hier bereits beginnen, die richtige Wahl zu treffen.
Wir müssen nämlich unserem Editor sagen, ob er aus 'Beispiel mit Häkchen (") drin' nun

66 101 105 115 112 105 101 108 32 109 105 116 32 72 228 107 99 104 101 110 32 40 34 41 32 100 114 105 110
oder
66 101 105 115 112 105 101 108 32 109 105 116 32 72 195 164 107 99 104 101 110 32 40 34 41 32 100 114 105 110

machen soll.

Kontext und Codierung sind mMn für einen Artikel auch nicht zu trennen, sondern es muss auf beide eingegangen werden.

Es muss mMn auch klar gemacht werden, dass in der Datenhaltung dann eben später auch nur der Code 34 und nicht 92 34 drinsteht. Wie soll man das begreifen, wenn man es nicht ausdrücklich gezeigt bekommt?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Auge]

Hallo

"Wann immer Daten in einen anderen Kontext eingefügt werden sollen, sind diese dem Kontext entsprechend zu behandeln."
für kontraproduktiv. Dem Anfänger wurde gerade gesagt, dass wir bei "jedem" Kontextwechsel aktiv etwas unternehmen müssen. Hier unternehmen wir aber nichts, hier können wir nicht mal was unternehmen.

Doch, wir müssen hier bereits beginnen, die richtige Wahl zu treffen.
Wir müssen nämlich unserem Editor sagen, ob er aus 'Beispiel mit Häkchen (") drin' nun

66 101 105 115 112 105 101 108 32 109 105 116 32 72 228 107 99 104 101 110 32 40 34 41 32 100 114 105 110
oder
66 101 105 115 112 105 101 108 32 109 105 116 32 72 195 164 107 99 104 101 110 32 40 34 41 32 100 114 105 110

machen soll.

Müssen wir das? Was sagen wir dem Editor an dieser Stelle überhaupt? Wenn man es genau nimmt: garnichts. Er ist ein Werkzeug, in dem wir Code notieren. Was mit dem Code zu geschehen hat, interessiert den Editor nicht, im Fall von PHP interessiert es dessen Interpreter.

Deine Zahlencodes als Entsprechungen der eingegebenen Zeichen interessieren mich als Autor eines Skripts im Übrigen in keinster Weise, denn sie sind eben nur Entsprechungen meiner Eingaben. Das überschaue ich nicht und ich muss es auch nicht, denn ich komme mit diesen Codes garnicht in Berührung.

Wichtig ist das Wissen um die Notwendigkeit, Ausgaben entsprechend den Regeln des Ausgabemediums zu behandeln. Ich muss mir genau dieses Fakts klar sein und wissen, mit welchen Mitteln ich das in der benutzten Sprache erreichen kann. Zudem muss ich wissen, wann ich das selbst machen muss und wann die benutzte Sprache oder z.B. der Browser das für mich automatisch erledigt.

Es muss mMn auch klar gemacht werden, dass in der Datenhaltung dann eben später auch nur der Code 34 und nicht 92 34 drinsteht. Wie soll man das begreifen, wenn man es nicht ausdrücklich gezeigt bekommt?

Noch einmal: Wen interessieren an der Stelle die Zahlencodes anstatt der durch sie repräsentierten Zeichen?

Deine Einlassungen gehen mMn zu tief in Details, die im Kontext der Entwicklung von Webanwendungen keine Rolle spielen. Wenn wir HTML-Dokumente oder PHP- oder JavaScript-Skripte auf eine Weise schreiben müssten, die die Eingabe dieser Zahlencodes anstatt der Zeichen selbst erforderte, wäre das wohl etwas anderes.

Tschö, Auge

[ChrisB]

Hi,

Deine Zahlencodes als Entsprechungen der eingegebenen Zeichen interessieren mich als Autor eines Skripts im Übrigen in keinster Weise, denn sie sind eben nur Entsprechungen meiner Eingaben. Das überschaue ich nicht und ich muss es auch nicht, denn ich komme mit diesen Codes garnicht in Berührung.

In Matrix gibt's diese eine Stelle, wo der Operator zu Neo sagt, dass er sich die Matrix inzwischen nur noch kodiert anschauen würde.

Wenn Tom das mit seinen (Script-)Dateien gerne genauso macht, sei's ihm freigestellt.
Im hier zur Diskussion stehenden Artikel hat das aber m.E. wenig bis gar nichts verloren.

MfG ChrisB

[molily]

»Da in Javascript ein String nicht über mehrere Zeilen gehen darf ...«

Darf er schon, wenn die Zeile mit einem »\« endet:

alert("bla\n\ bla" == "bla\nbla");

Aber das nur am Rande... Genauer kann ich mir den Artikel gerade nicht ansehen.

Mathias

[molily]

Bei der Überführung von Daten in einen JavaScript-String müsste man folgende Maskierungen vornehmen (die von dir verlinkte Quelle ist da nicht so genau):

• natürlich die (jeweiligen) Stringbegrenzer.

• Die in ECMAScript eingebauten Escape-Sequenzen
  \b \t \n \v \f \r

• Hexadezimale, Oktale und Unicode-Escape-Sequenzen:
  \xNN \N \NN \NNN \uNNNN
  (N = arabische Ziffer)

(Oktale sind deprecated in Netscape JS 1.5 und nicht Teil von ECMAScript)

• \ selbst

Ich weiß grad nicht, ob man etwas damit falsch macht, wenn man grundsätzlich »addslashes« macht, also jedem \ ein \ voranstellt.

D.h. wenn ich

bla"bla\bbla\x11bla\u1111\bla'bla

eins zu eins abbilden will, ohne dass JS die Escape-Sequenzen interpretiert, dann müsste ich einfach

var string = "bla"bla\bbla\x11bla\u1111\bla'bla";

schreiben können.

Hier wäre vielleicht ein Hinweis auf gängige JSON-Bibliotheken angemessen, die einem das abnehmen und den Kontextwechsel zu JS vereinfachen.

molily (enthält nur kleine Buchstaben. Bin ich mir sicher, dass ich das Posting so abschicken will?)

[dedlfix]

Hi!

Bei der Überführung von Daten in einen JavaScript-String müsste man folgende Maskierungen vornehmen (die von dir verlinkte Quelle ist da nicht so genau):

Irgendwie fand ich beim Recherchieren keine ordentliche Quelle. Danke für die Auflistung.

molily (enthält nur kleine Buchstaben. Bin ich mir sicher, dass ich das Posting so abschicken will?)

Das "Hauptproblem" ist, dass ich SELFHTML so wie es richtig ist in Großbuchstaben schreiben wollte ... was auch wieder nicht richtig war.

Lo!

[dedlfix]

Hi!

»Da in Javascript ein String nicht über mehrere Zeilen gehen darf ...«
Darf er schon, wenn die Zeile mit einem »\« endet:

Dann gehört aber der \ nicht zu den Nutzdaten sondern ist die Maskierung für den dort stehenden Zeilenumbruch. Ich werde es zusätzlich zum \n erwähnen.

Lo!

[molily]

Dann gehört aber der \ nicht zu den Nutzdaten sondern ist die Maskierung für den dort stehenden Zeilenumbruch.

Richtig, das wollte ich mit meinem alert-Beispiel zeigen.

Grüße,
Mathias

[hotti]

Hi!

Recht häufig wird die Problematik des Kontextwechsels unbeachtet gelassen. Um nicht immer wieder das Gleiche erzählen zu müssen und dabei die Hälfte zu vergessen, schrieb ich einen SELFTHML-Aktuell-Artikel dazu.

Prima und schön, mal wieder einen neuen Artikel im SELFRaum lesen zu dürfen, danke Dir!

Hotte

[Auge]

Hallo

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

Abschnitt "Einleitung"
Das Beispiel ist etwas fern des Kontexts, das wurde ja schon angemerkt. Ich würde ohne Umschweife auf Programmier- und Auszeichnungssprachen kommen, die halt bestimmte Zeichen für die Umsetzung ihrer Syntax benutzen die aber auch in einer Zeichenkette vorkommen können und in diesem Fall eine Behandlung brauchen um nicht missverstanden zu werden.

Womit wir beim Abschnitt "Das Problem" wären.
"Nutzdaten" und "Begleitdaten" ... ich musste die ersten Sätze zwei- dreimal lesen, um zu verstehen, worauf du hinaus willst. Erst ab "Wie auch immer, ein Programmierer ..." wird klar, worum es gehen soll: "Was ist zu tun, wenn in einer Zeichenkette ein Zeichen benutzt wird, welches in der/einer konkreten Sprache Bestandteil der Syntax ist?".

Einordnung des Artikels in eine Kategorie:
Für "PHP" spricht, dass die Beispiele alle anhand von PHP durchexerziert werden, für "Programmiertechnik" steht die Tatsache, dass das Problem überall auftaucht. Ich wäre für letztere Kategorie, wobei ein Hinweis auf die beispielhafte Verwendung von PHP in der Einleitung stehen sollte.

Tschö, Auge

[dedlfix]

Hi!

Abschnitt "Einleitung"

Der wird nochmal überarbeitet, das steht schon auf dem Plan.

"Nutzdaten" und "Begleitdaten" ... ich musste die ersten Sätze zwei- dreimal lesen, um zu verstehen, worauf du hinaus willst. Erst ab "Wie auch immer, ein Programmierer ..." wird klar, worum es gehen soll: "Was ist zu tun, wenn in einer Zeichenkette ein Zeichen benutzt wird, welches in der/einer konkreten Sprache Bestandteil der Syntax ist?".

Das werde ich etwas genauer erläutern, aber nicht so tief gehend wie Tom sich das vorstellt.

Einordnung des Artikels in eine Kategorie:

Ich bin da fein raus, das muss letztlich nicht ich entscheiden :-)

[...] wobei ein Hinweis auf die beispielhafte Verwendung von PHP in der Einleitung stehen sollte.

Kommt rein.

Lo!

[Tom]

Hello,

Das werde ich etwas genauer erläutern, aber nicht so tief gehend wie Tom sich das vorstellt.

Du sollst auch nicht bei Adam und Eva anfangen, sondern lediglich bildlich machen, warum es da zu Unterscheidungen kommt.

Wesentlich ist doch die Konsistenz der Rohdaten und die spiegeln sich nun mal in der Datenhaltung wieder. Setzt man voraus (was auch nicht selbstverständlich ist), dass die Datenhaltung im Wesentlichen byteorientiert funktioniert heute, dann wäre das die gemeinsame Basis für alle weiteren Handlungen. Es muss möglich sein, von den Rohdaten über die Übertragungsstrecke, auf der dann die Kontextwechsel stattfinden, wieder zu den Rohdaten zu gelangen.

Das kannst Du prinzipiell grafisch darstellen.

Eine grafische Darstellung sollte auch in der Lage sein klarzustellen, dass man nicht jeden Transformationsschritt irgendwann machen darf und nicht jede Hilfsmaßnahme irgendwann ergreifen darf (Escaping für eine Schnittstelle), sondern diese in einer wohlüberlegten reihenfolge stattfinden müssen.

Ich muss für den Eintrag von Daten in eine Datenbank keine Tags ziehen, vorausgesetzt, sie gehören zu den Rohdaten. Ich muss auch kein addslashes() für eine MySQL-Text-Schnittstelle benutzten. Das passt nämlich nicht zusammen. usw.

|----------------------------|
----------------------------------   Übertragung als HTML-Text  ---------------------------
Rohdaten                     Kontextwechsel               Kontextwecsel   Weiterverarbeitung als
                                                                          Rohdaten

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Das werde ich etwas genauer erläutern, aber nicht so tief gehend wie Tom sich das vorstellt.
Du sollst auch nicht bei Adam und Eva anfangen, sondern lediglich bildlich machen, warum es da zu Unterscheidungen kommt.

Zeichenkodierung möchte ich wirklich aus diesem Artikel raushalten. Das füllt locker einen eigenen. Denn bei Zeichenkodierung spielt nicht nur der sichtbare Code im Editor eine Rolle sondern auch noch die versteckte Konfiguration zur Kodierung beim Speichern. Das Thema ist schon reichhaltig genug. Wenn ich da auch noch die Unwägbarkeiten des Editors in die Erläuterung aufnehme, wird mir das zu viel Stoff für das angestrebte Publikum, weil ich dann wirklich die Bytesequenzen zur Veranschaulichung heranziehen müsste.

Wesentlich ist doch die Konsistenz der Rohdaten und die spiegeln sich nun mal in der Datenhaltung wieder. Setzt man voraus (was auch nicht selbstverständlich ist), dass die Datenhaltung im Wesentlichen byteorientiert funktioniert heute, dann wäre das die gemeinsame Basis für alle weiteren Handlungen.

Ich setze für diesen Artikel eine Zeichenorientierung als unterstes technisches Level voraus.

Es muss möglich sein, von den Rohdaten über die Übertragungsstrecke, auf der dann die Kontextwechsel stattfinden, wieder zu den Rohdaten zu gelangen.

Deswegen bereite ich sie zeichenorientiert für den passenden Kontext auf. Ob die Übertragungsstrecke sie in Byte oder was anderes zerlegt, ist mir als Anwender egal. Ich hab sie ordnungsgemäß dem Transporteur übergeben, die Gefahr geht damit auf den Käufer über ... ups, falscher Kontext :-)

Eine grafische Darstellung sollte auch in der Lage sein klarzustellen, dass man nicht jeden Transformationsschritt irgendwann machen darf und nicht jede Hilfsmaßnahme irgendwann ergreifen darf (Escaping für eine Schnittstelle), sondern diese in einer wohlüberlegten reihenfolge stattfinden müssen.

Das hab ich doch auch ohne grafische Darstellung schon in den Abschnitten zu geschachtelten Kontexten drin? Und die Reihenfolge ergibt sich aus der Schachtlung. Sie von innen nach außen aufzulösen, habe ich erwähnt.

Ich muss für den Eintrag von Daten in eine Datenbank keine Tags ziehen, vorausgesetzt, sie gehören zu den Rohdaten. Ich muss auch kein addslashes() für eine MySQL-Text-Schnittstelle benutzten. Das passt nämlich nicht zusammen. usw.

Benutzen müssen muss man addslashes() nicht, aber völlig unpassend ist es nun auch wieder nicht. Es behandelt alle für MySQL-Strings wirklich kritischen Zeichen: ", ', \ und für Binärdaten das Null-Byte. Der Rest ist nice-to-have: "(Striktly speaking, ...)"

Lo!

[dedlfix]

Hi!

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

Der Artikel hat nun eine Überarbeitung in fast allen Bereichen bekommen. Hier das "ChangeLog":

• Der Anfang ist komplett erneuert, aus zwei Abschnitten wurden vier.
• Kapitel Auswirkungen, neu: "Fehler und deren Auswirkungen" hat kleinere Ergänzungen bekommen.
• "Verhindernde Maßnahmen": eine kleine Erläuterung zu sprintf() ist ergänzt
    - hinzugekommen ist bei den Besonderheiten der LIKE-Operator
    - Die Prepared Statements sind nun (hoffentlich) nicht ganz so ablehnend formuliert.
    - und ja, auch der ANSI_QUOTES-Modus findet eine Erwähnung.
• "Kontextwechsel erkennen" + "und behandeln": Einleitung erweitert
    - Abschnitt SQL hinzugefügt mit kurzer Erwähnung einiger anderer DBMS
    - Abschnitt HTML stark erweitert. u.a. Zeilenumbruch-Problematik hinzugefügt
    - URL: kleine Ergänzung
    - JavaScript: jetzt 200% mehr Inhalt :-)
    - AJAX hinzugekommen
• Falsch erkannte / behandelte Kontextwechsel
    - Abschnitte "JavaScript im HTML-Dokument" und "HTML in der Datenbank" hinzugefügt

Als Kategorie hab ich nun PHP gewählt, da alle Erläuterungen stark PHP-orientiert sind.

Nun bitte ich euch darum die derzeitige Fassung zu lesen und auf Verständlichkeit, Ergänzungspotenzial und sprachliche Fehler (Stil, Rechtschreibung) zu prüfen.

Diesen Wunsch möchte ich auch gern erneuern.

Übrigens: Die bisherige Version ist nun zu finden unter http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/indexold.htm

Lo!

[Christian Seiler]

Hallo dedlfix,

Im Abschnitt "Javascript im HTML-Dokument" würde ich an Deiner Stelle noch ein paar Beispiele hinzufügen, um die Gefährlichkeit von XSS etwas zu demonstrieren.

Genauso wäre bei Datenbanken auch ein Beispiel für die Identifier-Geschichte wichtig, damit klar gemacht wird, wie Du das genau meinst (gerade für Anfänger ist es IMHO oft schwierig, ohne Beispiel so etwas zu verstehen). Zudem könntest Du andere Dinge bei automatisch zusammengebaute SELECTs erwähnen, es gibt ja oft sowas wie $sql = "SELECT ... ORDER BY " . $_GET['order_by']; oder so...

(Vielleicht als Inpsiration was man erwähnen sollte: Stefan Esser hat auf der "Dutch PHP Conference" ein paar Vorträge gehlaten, von denen die Folien verfügbar sind.)

Ansonsten: Ich hab's mir nur flüchtig durchgelesen, gefällt mir aber bisher. Gute Arbeit!

Viele Grüße,
Christian

[dedlfix]

Hi!

Im Abschnitt "Javascript im HTML-Dokument" würde ich an Deiner Stelle noch ein paar Beispiele hinzufügen, um die Gefährlichkeit von XSS etwas zu demonstrieren.

Für XSS wäre das aber der falsche Abschnitt, denn dann geht es ja um das Einfügen von Daten in JavaScript, was im Abschnitt "JavaScript" behandelt wird. Und vermutlich hast du auch noch document.write(... + daten) im Sinn. Das wäre der Kontext HTML, diesmal von JavaScript aus. Wenn der JS-Code auch noch mit PHP erzeugt wird ... es gibt einfach zu viele Kombinationsmöglichkeiten beim Schachteln von Kontexten.

Die Inspiration zu dem von dir genannten Abschnitt kam mir aufgrund des Postings https://forum.selfhtml.org/?t=188423&m=1254156. Da sind keine Benutzereingaben vorgesehen. Es handelt sich dabei nur um einen Irrtum vom Autor beim Schreiben von JS-Code. Der Abschnitt verträgt sicher noch ein paar Wörter und ein Beispiel mehr, damit er etwas eindeutiger wird.

Genauso wäre bei Datenbanken auch ein Beispiel für die Identifier-Geschichte wichtig, damit klar gemacht wird, wie Du das genau meinst (gerade für Anfänger ist es IMHO oft schwierig, ohne Beispiel so etwas zu verstehen). Zudem könntest Du andere Dinge bei automatisch zusammengebaute SELECTs erwähnen, es gibt ja oft sowas wie $sql = "SELECT ... ORDER BY " . $_GET['order_by']; oder so...

Danke für das gute Beispiel. Mir fielen beim Entwerfen des Artikels immer nur Stellen ein, für die selten Identifier aus Benutzereingaben verwendet werden (à la Datenbankverwaltungssoftware). Doch das ORDER BY ist eine Stelle, die schon eher in "normalen" Anwendungen aufgefunden werden kann. Insofern bekommt die Identifier-Geschichte auch noch etwas mehr praktische Relevanz.

(Vielleicht als Inpsiration was man erwähnen sollte: Stefan Esser hat auf der "Dutch PHP Conference" ein paar Vorträge gehlaten, von denen die Folien verfügbar sind.)

Mal sehen, was ich davon noch "verwerten" kann.

Ansonsten: Ich hab's mir nur flüchtig durchgelesen, gefällt mir aber bisher. Gute Arbeit!

Danke für's Feedback. Es ist immer gut, wenn nochmal jemand anderes den Text liest. Ich selbst bin ja "befangen" und sehe nicht unbedingt immer die Problemstellen bei der thematischen Verständlichkeit oder der meines Geschreibsels.

Lo!

[Christian Seiler]

Hallo,

Im Abschnitt "Javascript im HTML-Dokument" würde ich an Deiner Stelle noch ein paar Beispiele hinzufügen, um die Gefährlichkeit von XSS etwas zu demonstrieren.

Für XSS wäre das aber der falsche Abschnitt, denn dann geht es ja um das Einfügen von Daten in JavaScript, was im Abschnitt "JavaScript" behandelt wird. Und vermutlich hast du auch noch document.write(... + daten) im Sinn. Das wäre der Kontext HTML, diesmal von JavaScript aus. Wenn der JS-Code auch noch mit PHP erzeugt wird ... es gibt einfach zu viele Kombinationsmöglichkeiten beim Schachteln von Kontexten.

Mir ginge es eher um Inline-Eventhandler, Beispiel-PHP-Code:

// WARNUNG: NICHT VERWENDEN  
echo "<span onclick=\"tuwas ('".htmlspecialchars ($usereingabe)."');\">";

Zudem könntest Du andere Dinge bei automatisch zusammengebaute SELECTs erwähnen, es gibt ja oft sowas wie $sql = "SELECT ... ORDER BY " . $_GET['order_by']; oder so...

Danke für das gute Beispiel. Mir fielen beim Entwerfen des Artikels immer nur Stellen ein, für die selten Identifier aus Benutzereingaben verwendet werden (à la Datenbankverwaltungssoftware).

Oha, ich hab da sogar noch was vergessen: Mir ging's nicht nur um die Identifier beim ORDER BY, sondern auch um die Sortierrichtung. Also sowas wie "SELECT ... ORDER BY ".$_GET['order_by']." ".$_GET['order_direction']; oder ähnliches...

Viele Grüße,
Christian

[dedlfix]

Hi!

Mir ginge es eher um Inline-Eventhandler, Beispiel-PHP-Code:

// WARNUNG: NICHT VERWENDEN

echo "<span onclick="tuwas ('".htmlspecialchars ($usereingabe)."');">";

  
Hier fehlt nur als zweiter Parameter von htmlspecialchars() ein ENT\_QUOTES, wegen der Verwendung von ' als Stringbegrenzer im JavaScript. Ansonsten muss der onclick-Inhalt gemäß HTML behandelt werden. Die für PHP und JavaScript kritischen Zeichen ', " und \ sind ja abgedeckt. Oder hab ich noch was übersehen?  
  

> Oha, ich hab da sogar noch was vergessen: Mir ging's nicht nur um die Identifier beim ORDER BY, sondern auch um die Sortierrichtung. Also sowas wie "SELECT ... ORDER BY ".$\_GET['order\_by']." ".$\_GET['order\_direction']; oder ähnliches...  
  
Sehr gut. Und damit haben wir wieder ein False-Friends-Beispiel, bei dem die Kontextbehandlung nicht verwendet werden kann, weil hier Daten als Code eingefügt werden sollen. Hier kann man auch nicht à la intval() beim Zahlenbeispiel auf einfachste Weise nur gültige Werte erzwingen - hier muss mit einer selbst zu schreibenden Werteprüfung aufgewartet werden.  
  
  
Lo!

[Christian Seiler]

Hallo dedlfix,

Hier fehlt nur als zweiter Parameter von htmlspecialchars() ein ENT_QUOTES, wegen der Verwendung von ' als Stringbegrenzer im JavaScript. Ansonsten muss der onclick-Inhalt gemäß HTML behandelt werden. Die für PHP und JavaScript kritischen Zeichen ', " und \ sind ja abgedeckt. Oder hab ich noch was übersehen?

Wenn Du &#039; als die Escape-Sequenz für ' nimmst (also *nur* ent_quotes), dann kommt das trotzdem als Anführungszeichen im Javascript-Interpreter an - was dann zu XSS führt.

Probier's aus, stell Dir vor, $usereingabe wäre so definiert:

$usereingabe = "'); alert ('foobar";  
echo "<span onclick=\"tuwas ('".htmlspecialchars ($usereingabe, ENT_QUOTES)."');\">"

Gibt:

<span onclick="tuwas ('&#039;); alert (&#039;foobar');">

Und der Javascript-Interpreter sieht das:

tuwas (''); alert ('foobar');

Denk Dir nun statt alert ('foobar') irgend einen bösen Code dahin und dann hast Du den XSS-Salat.

Sprich: Du musst das erst als Javascript-String maskieren und *dann* erst als HTML-String maskieren.

Viele Grüße,
Christian

[Tom]

Hello,

Für XSS wäre das aber der falsche Abschnitt, denn dann geht es ja um das Einfügen von Daten in JavaScript, was im Abschnitt "JavaScript" behandelt wird.

Es ist möglich, Formulare zu entführen, gänzlich ohne JavaScript-Einsatz

Hier ist dann eine fehlende Kontextwechselbehandlung/-beachtung Schuld.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Es ist möglich, Formulare zu entführen, gänzlich ohne JavaScript-Einsatz
Hier ist dann eine fehlende Kontextwechselbehandlung/-beachtung Schuld.

Meinst du das PHP_SELF-Problem?

Lo!

[Tom]

Hello,

Es ist möglich, Formulare zu entführen, gänzlich ohne JavaScript-Einsatz
Hier ist dann eine fehlende Kontextwechselbehandlung/-beachtung Schuld.

Meinst du das PHP_SELF-Problem?

Wenn man mit PHP_SELF und eingeschalteter Path-Info richtig umgeht, ist es ja kein Problem. Es wird eben dadurch eins, dass nahezu in allen Publikationen (ich könnte wetten, auch noch in welchen von SelfHTML) die schlampige Schreibweise mit

echo  "<form action="{S_SERVER['PHP_SELF']}" method="POST">";

benutzt wird.

Es ist dann auch für einen Anfänger überhaupt nicht ersichtlich, dass dies eine Sicherheitslücke für Formularentführung darstellt und auch nicht einsichtig, wo es doch genau so in fast jedem Beispiel zum Thema benutzt wird!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

(Vielleicht als Inpsiration was man erwähnen sollte: Stefan Esser hat auf der "Dutch PHP Conference" ein paar Vorträge gehlaten, von denen die Folien verfügbar sind.)

Er hat da als Beispiel unter anderem

alert(/XSS/)

angegeben. Der Firefox schreibt daraufhin /XSS/ ins Alert-Fenster. Das kann man ja auch schon in der Fehlerkonsole probieren. Aber was hat es damit auf sich? Es muss irgendwas regulär ausgedrücktes sein ...

Lo!

[Christian Seiler]

Nallo dedlfix,

Er hat da als Beispiel unter anderem

alert(/XSS/)

angegeben. Der Firefox schreibt daraufhin /XSS/ ins Alert-Fenster. Das kann man ja auch schon in der Fehlerkonsole probieren. Aber was hat es damit auf sich? Es muss irgendwas regulär ausgedrücktes sein ...

/XSS/ ist in JS die Literal-Schreibweise für einen regulären Ausdruck. Du kannst z.B. /XSS/.match () machen oder sowas ähnliches.

alert() akzeptiert nur Strings. Also wird das Reguläre-Ausdruck-Objekt wieder in einen String konvertiert. Und für RegExp-Objekte ist das in JS halt die Darstellung, die auch im Source vorkommt, zumindest im FF. Paste doch mal folgendes in Deine FF-Adresszeile:

alert(new RegExp('XSS'))

Viele Grüße,
Christian

[molily]

Er hat da als Beispiel unter anderem

alert(/XSS/)

angegeben.

Das soll glaube ich zeigen, dass man wegen dem dynamischen Typing nicht auf normale String-Literale wie "XSS" und 'XSS' angewiesen ist, um Strings zu notieren. D.h. der Autor kann ruhig brav " und ' maskieren oder sogar filtern, aber wenn der Angreifer JavaScript einschleusen kann, dann wird ihn das nicht hindern, Strings zu notieren. Eine andere Möglichkeit wäre String.fromCharCode(123).

Allerdings ralle ich nicht so recht, in welchen Fällen das zum XSS-Erfolg führt, während normale String-Literale es nicht tun. Wenn der Angreifer soviel JS einschleusen kann, dass alert() interpretiert wird, und das Maskieren/Filtern von " und ' daran nichts geändert hat, dann ist zu aller dieses XSS-Loch zu stopfen.

Mathias

[molily]

- AJAX hinzugekommen

Da es in SELFHTML nicht drinsteht, aber enorm wichtig ist, könntest du anmerken, dass encodeURIComponent Zeichen außerhalb von ASCII als UTF-8-Bytesequenzen maskiert (z.B. ä > %C3%A4).

Was ich ein wenig vermisse, ist ein konkretes Beispiel für einen verschachtelten Kontextwechsel HTML in JavaScript (ggf. wieder in HTML).

$boeserText = 'Hier können alle <b>Schweinereien</b> der "Welt" stehen, die \'JS\' oder HTML »ownen«.';  
$bessererText = sprintf("alert('%s')", javascriptescape($boeserText));  
$guterText = sprintf('<p onclick="%s">Klick mich</a>', htmlspecialchars($bessererText, ENT_QUOTES));  
echo $guterText
~~~;  
  
Das ist ja nicht selten.  
  
Übrigens sind die Links im Satz  
Siehe auch die Abschnitte AJAX und JavaScript im HTML-Dokument.  
fehlerhaft, es fehlt eine #.  
  
Mathias

-- 
[JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)

[dedlfix]

Hi!

- AJAX hinzugekommen
Da es in SELFHTML nicht drinsteht, aber enorm wichtig ist, könntest du anmerken, dass encodeURIComponent Zeichen außerhalb von ASCII als UTF-8-Bytesequenzen maskiert (z.B. ä > %C3%A4).

Aber nur als Fußnote, denn Zeichenkodierung wollte ich für diesen Artikel eigentlich weglassen, weil es mir zu umfangreich erscheint.

Was ich ein wenig vermisse, ist ein konkretes Beispiel für einen verschachtelten Kontextwechsel HTML in JavaScript (ggf. wieder in HTML).

Ja, das hat ja Christian Seiler auch schon angemerkt. Da will ich noch was bringen.

Übrigens sind die Links im Satz
Siehe auch die Abschnitte AJAX und JavaScript im HTML-Dokument.
fehlerhaft, es fehlt eine #.

Danke. Jetzt wo du es sagst, erinnere ich mich, dass ich nicht daran gedacht habe. Auch im Abschnitt SQL fehlen die.

Lo!

[dedlfix]

Hi!

Nachdem ich den Artikel noch einmal überarbeitet und erweitert habe, bitte ich erneut um Durchsicht und Kritik.

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

Hier das Changelog zur vorherigen Version:

• "Falsch erkannte / behandelte Kontextwechsel" aufgelöst und Themen in andere Abschnitte verschoben
• Fehler und deren Auswirkungen
    Noch ein Beispiel angefügt
• Verhindernde Maßnahmen
    Abschnitt "Besonderheiten" umbenannt und ORDER BY hinzugefügt
    "Zahlen im (My)SQL-Statement" nach hier verschoben
    "PHP-Besonderheit Magic Quotes" nach hier verschoben
• Kontextwechsel erkennen und behandeln
    "HTML in der Datenbank" nach hier verschoben und um Beispiel ergänzt
    "JavaScript und HTML" hinzugefügt
    "<script>- und <style>-Bereiche im HTML-Dokument" hinzugefügt (ex "JavaScript im HTML-Dokument" erweitert)
    "E-Mail" hinzugefügt
• Kontextwechsel und Maskierungen in Code-Beispielen farblich gekennzeichnet

Mit der Farbgebung der Maskierungen (Rot mit geänderter Hintergrundfarbe) bin ich nicht ganz zufrieden. Eigentlich suchte ich eine Nur-Vordergrundfarbenlösung, doch da fiel mir nichts kontrastreiches (sowohl zum Hintergrund als auch zu den anderen Farben) und zugleich erkennbar auffälliges ein.

Lo!

[Alexander (HH)]

Moin Moin!

Nachdem ich den Artikel noch einmal überarbeitet und erweitert habe, bitte ich erneut um Durchsicht und Kritik.

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

In "JavaScript und HTML" ganz hinten schreibst Du: "Beide Kontextwechsel wurden jeweils fehlerfrei gemeistert. Ein Angriff erzeugt zwar – je nachdem wie der Eingabewert weiterverwendet wird – möglicherweise eine ungewollte Ausgabe auf dem Bildschirm, doch wenigstens ist sie sicherheitstechnisch harmlos."

Bei dem Wörtchen "harmlos" sträuben sich mir doch etwas die Haare. Wenn die tuwas()-Funktion wesentlich mehr macht als nur alert() zu wrappen, kann hier trotzdem noch eine Lücke entstehen. Zum Beispiel, wenn eval() im Spiel ist oder der Parameter eigentlich eine relative URL eines weiteren Javascripts sein soll. Das Problem ist doch viel mehr, dass unvalidierte Eingaben wieder ausgegeben werden statt einen Fehler zu erzeugen. Ich weiß, das geht wieder über den Artikelrahmen hinaus. Aber wenn man sich ausreichend blöd stellt, kann man den letzten Satz so lesen, dass saubere Kontextwechsel SÄMTLICHE Sicherheitsprobleme lösen.

Alexander

[dedlfix]

Hi!

In "JavaScript und HTML" ganz hinten schreibst Du: "Beide Kontextwechsel wurden jeweils fehlerfrei gemeistert. Ein Angriff erzeugt zwar – je nachdem wie der Eingabewert weiterverwendet wird – möglicherweise eine ungewollte Ausgabe auf dem Bildschirm, doch wenigstens ist sie sicherheitstechnisch harmlos."
[...] wenn man sich ausreichend blöd stellt, kann man den letzten Satz so lesen, dass saubere Kontextwechsel SÄMTLICHE Sicherheitsprobleme lösen.

Notiz an mich selbst: Wenn man schon beim Schreiben mit der passenden Formulierung nebst Inhalt ringt, sollte man den Absatz liegen lassen und später noch mal neu schreiben.

Ich lass das mit der Bildschirmausgabe ganz weg und formuliere so:

»Beide Kontextwechsel wurden jeweils fehlerfrei gemeistert. Der JavaScript-Code wird nicht kompromittiert. Was die Funktion tuwas() damit anstellt, steht auf einem anderen Blatt. In deren Code sind möglicherweise weitere Kontextwechsel zu beachten.«

Lo!

[Auge]

Hallo

Nachdem ich den Artikel noch einmal überarbeitet und erweitert habe, bitte ich erneut um Durchsicht und Kritik.

http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

Für mich steht der Kontextwechsel als Thema ... wie soll ich sagen ... "zu allein" da. Es fehlt mir die Herleitung, dass es darum geht, dass z.B. mit PHP oder JavaScript oft Zeichenketten erzeugt werden, die in anderen Sprachen (Kontexten), bei diesen Sprachen typischerweise HTML oder SQL, verwendet werden sollen, also beim Kontextwechsel so umgebaut werden müssen, dass sie deren Regeln folgen. Das sollte mMn in der Einleitung erwähnt werden, um die praktische Relevanz zu verdeutlichen.

Tschö, Auge

[dedlfix]

Hi!

Für mich steht der Kontextwechsel als Thema ... wie soll ich sagen ... "zu allein" da. Es fehlt mir die Herleitung, dass es darum geht, dass z.B. mit PHP oder JavaScript oft Zeichenketten erzeugt werden, die in anderen Sprachen (Kontexten), bei diesen Sprachen typischerweise HTML oder SQL, verwendet werden sollen, also beim Kontextwechsel so umgebaut werden müssen, dass sie deren Regeln folgen. Das sollte mMn in der Einleitung erwähnt werden, um die praktische Relevanz zu verdeutlichen.

Tut mir leid, ich verstehe nicht, worauf du konkret hinauswillst. Meiner Meinung nach sind deine Forderungen in den im Artikel verteilten Beispielen enthalten.

Lo!

[Auge]

Hallo

Für mich steht der Kontextwechsel als Thema ... wie soll ich sagen ... "zu allein" da. Es fehlt mir die Herleitung, dass es darum geht, dass z.B. mit PHP oder JavaScript oft Zeichenketten erzeugt werden, die in anderen Sprachen (Kontexten), bei diesen Sprachen typischerweise HTML oder SQL, verwendet werden sollen, also beim Kontextwechsel so umgebaut werden müssen, dass sie deren Regeln folgen. Das sollte mMn in der Einleitung erwähnt werden, um die praktische Relevanz zu verdeutlichen.

Tut mir leid, ich verstehe nicht, worauf du konkret hinauswillst. Meiner Meinung nach sind deine Forderungen in den im Artikel verteilten Beispielen enthalten.

Es sollte mMn exlizit in der Einleitung ausgeführt werden. Bedenke, dass sich der Artikel auch an Anfänger richtet. Der bekommt im Artikel zehntausend-, ach mindestens millionenfach den Begriff "Kontextwechsel" um die Ohren gehauen. Für uns ist der Sinn dahinter klar, für einen Anfänger nicht unbedingt.

Wie wir hier immer wieder lesen können, ist Anfängern meist nicht mal klar, dass ein per echo ausgegebener HTML-Fetzen "nachher", also im Browser, auch wirklich *HTML ist* (Kontext) oder ein im PHP-Quelltext notierter SQL-Query in PHP nur ein String, bei seiner Verarbeitung *durch ...SQL* eben eine SQL-Anweisung (Kontext) ist. Du weißt ja, die Frage lautet nur allzu oft "Ich habe in PHP eine Datenbankabfrage, wieso macht das PHP nicht?".

Tschö, Auge

[dedlfix]

Hi!

Es sollte mMn exlizit in der Einleitung ausgeführt werden. Bedenke, dass sich der Artikel auch an Anfänger richtet.

Ja, eben. deswegen hat ja auch Sven meinen ersten Entwurf sehr verbesserungswürdig gehalten.

Der bekommt im Artikel zehntausend-, ach mindestens millionenfach den Begriff "Kontextwechsel" um die Ohren gehauen. Für uns ist der Sinn dahinter klar, für einen Anfänger nicht unbedingt.

Das Vorwort läuft außer Konkurrenz. Das sind ein paar allgemeine erläuternde Worte, die hauptsächlich nicht an Anfänger gerichtet sind, sondern eher an Wissende, die sich beispielsweise sonst darüber "aufregen", warum da nicht auch noch Kodierungen behandelt werden oder warum keine deutschen PHP-Seiten verlinkt sind.

Wenn der Leser den Abschnitt nach der Einleitung (also "Programmcode und Daten") liest, kommt er (außer eben im Vorwort) mit dem Wort Kontextwechsel zum ersten Mal in Berührung. Bis dahin sind schon einige erläuternde Sätze gefallen und man sollte mitbekommen haben, worum es sich dreht.

Wie wir hier immer wieder lesen können, ist Anfängern meist nicht mal klar, [...]

Am besten wäre es, ein paar Anfänger als Versuchskaninchen darauf anzusetzen ... aber die lesen anscheinend immer nur "oben" mit oder gar nicht.

Wie auch immer, ich bin irgendwie nicht so richtig davon überzeugt, dass die Einleitung noch spezifischer auf eine einzelne oder mehrere spezielle Situation eingehen sollte, denn solche Situationen kommen anschließend und im weiteren Verlauf auch noch geballt.

Du weißt ja, die Frage lautet nur allzu oft "Ich habe in PHP eine Datenbankabfrage, wieso macht das PHP nicht?".

Das liegt meiner Beobachtung nach eher daran, dass sie nicht beachten, dass die Datenbankfunktionen sich nicht nahtlos in PHP einfügen und beispielsweise PHP-Fehler melden, wenn der SQL-Server was zu beanstanden hat. Das ist aber ein Thema für den Artikel "Strategien zur Fehlerfindung".

Lo!

[Vinzenz Mai]

Hallo dedlfix,

Wie wir hier immer wieder lesen können, ist Anfängern meist nicht mal klar, [...]

Am besten wäre es, ein paar Anfänger als Versuchskaninchen darauf anzusetzen ... aber die lesen anscheinend immer nur "oben" mit oder gar nicht.

ich rühre die Werbetrommel, wann immer es passt :-)

Freundliche Grüße

Vinzenz

[dedlfix]

Hi!

ich rühre die Werbetrommel, wann immer es passt :-)

Ich seh das mit Freude und danke dir dafür ☺

Lo!

[jobo]

Hallo,

Wie wir hier immer wieder lesen können, ist Anfängern meist nicht mal klar, dass ein per echo ausgegebener HTML-Fetzen "nachher", also im Browser, auch wirklich *HTML ist* (Kontext) oder ein im PHP-Quelltext notierter SQL-Query in PHP nur ein String, bei seiner Verarbeitung *durch ...SQL* eben eine SQL-Anweisung (Kontext) ist. Du weißt ja, die Frage lautet nur allzu oft "Ich habe in PHP eine Datenbankabfrage, wieso macht das PHP nicht?".

Das oder ähnliches meinte ich wohl mit der kurzen Erläuterung, was Kontext bedeutet, im ersten Absatz (s.o.).

Gruß

jobo

[jobo]

Hallo,

Kleiner Vorschlag für die Einleitung.

vorher:

"Dieser Artikel befasst sich mit der Problematik des Kontextwechsels. „Problematik“ deshalb, weil die Nichtbeachtung des Kontextwechsels eine der häufigsten Quellen für diverse Probleme ist. Ziel ist es, die häufigsten Kontextwechsel im Web-Umfeld aufzuzeigen und wie diese behandelt werden. Das soll vorwiegend mit Beispielen für PHP und MySQL und textbasierenden Daten erklärt werden. Prinzipiell betrifft das Thema jedoch auch andere Sprachen und andere Datentypen."

nachher:

"Dieser Artikel befasst sich mit der Problematik des Kontextwechsels. Die Nichtbeachtung des Kontextwechsels ist eine der häufigsten Quellen für diverse Probleme. Unter "Kontext" ist hierbei der Zusammenhang zu verstehen, in dem Dateninhalte stehen [ggf. kurze Erläuterung]. Ziel ist es, die häufigsten Kontextwechsel im Web-Umfeld aufzuzeigen und zu demonstrieren, wie diese behandelt werden sollten. Das soll vorwiegend mit Beispielen für PHP und MySQL und textbasierenden Daten erklärt werden. Prinzipiell betrifft das Thema jedoch auch andere Sprachen und andere Datentypen."

Ansonsten könnte ich bei Bedarf u.U. noch weitere Rechtschreibkorrekturen anbieten und auch Vorschläge für kleinere Strukturanpassungen bzw. ggf. Ausdruckalternativen. Bin jetzt aber erst wieder ab Montag am Rechner.

Gruß

jobo

[dedlfix]

Hi!

nachher:

"Dieser Artikel befasst sich mit der Problematik des Kontextwechsels. Die Nichtbeachtung des Kontextwechsels ist eine der häufigsten Quellen für diverse Probleme. Unter "Kontext" ist hierbei der Zusammenhang zu verstehen, in dem Dateninhalte stehen [ggf. kurze Erläuterung]. [...]

Eine meiner Meinung nach ausführliche Erläuterung folgt in den anschließenden Abschnitten. Ich verstehe nicht, warum ich das im Vorwort noch einmal darlegen soll. Am liebsten würde ich ja das Vorwort ganz weglassen, ich möchte nur nicht auf die drei nachfolgenden Absätze verzichten. Sie ans Ende verbannen möchte ich allerdings auch nicht.

Ansonsten könnte ich bei Bedarf u.U. noch weitere Rechtschreibkorrekturen anbieten und auch Vorschläge für kleinere Strukturanpassungen bzw. ggf. Ausdruckalternativen.

Ja, mach mal. Das hat sich bis jetzt noch keiner getraut, trotz Aufforderung dazu. Ich habe schon immer versucht, Alternativen für die Wörter zu finden, die ich (zu) häufig verwende. Notepad++ markiert gleiche Wörter ja sehr schön, wenn man eins markiert.

Lo!

[jobo]

Hallo,

"Dieser Artikel befasst sich mit der Problematik des Kontextwechsels. Die Nichtbeachtung des Kontextwechsels ist eine der häufigsten Quellen für diverse Probleme. Unter "Kontext" ist hierbei der Zusammenhang zu verstehen, in dem Dateninhalte stehen [ggf. kurze Erläuterung]. [...]

Eine meiner Meinung nach ausführliche Erläuterung folgt in den anschließenden Abschnitten. Ich verstehe nicht, warum ich das im Vorwort noch einmal darlegen soll.

Einleitung = kurze Darstellung (hier: was ist "kontextwechsel", wieso ist das problemtatisch, was lerne ich im folgenden).

Hauptteil mit detaillierter Beschreibung

Zusammenfassung = was haben wir gelernt (hier: dass Kontextwechsel vieles bedeuten kann (u.U. nochmal ein kurz(zusamen-)gefasstes beispiel)

Diese Gliederung eigentlich Standard, ob in größeren Büchern oder in kleineren Aufsätzen. Ob Du das so machen willst, entscheidest Du, den Lesegewohnheiten kommt es sicherlich entgegen.

Am liebsten würde ich ja das Vorwort ganz weglassen, ich möchte nur nicht auf die drei nachfolgenden Absätze verzichten. Sie ans Ende verbannen möchte ich allerdings auch nicht.

Ansonsten könnte ich bei Bedarf u.U. noch weitere Rechtschreibkorrekturen anbieten und auch Vorschläge für kleinere Strukturanpassungen bzw. ggf. Ausdruckalternativen.

Ja, mach mal. Das hat sich bis jetzt noch keiner getraut, trotz Aufforderung dazu. Ich habe schon immer versucht, Alternativen für die Wörter zu finden, die ich (zu) häufig verwende. Notepad++ markiert gleiche Wörter ja sehr schön, wenn man eins markiert.

Ab Montag dann.

Gruß

jobo

[Auge]

Hallo

Eine meiner Meinung nach ausführliche Erläuterung folgt in den anschließenden Abschnitten. Ich verstehe nicht, warum ich das im Vorwort noch einmal darlegen soll.

Warum sollst du das in den einzelnen Abschnitten erklären (soweit es nichts mit dem konkreten Beispiel zu tun hat) und nicht in der Einleitung? Das ist die Stelle, wo es (offensichtlich nicht nur meiner Meinung nach) hin gehört. Dort wird in das Thema eingeführt, erklärt, was das Problem ist und wie es in der Abhandlung angegangen wird.

Tschö, Auge