http://localhost/phpProg/unbenannt2.php?jahr=2002

[Karl]

Hallo, bin also absoluter Anfänger und versuche nach einem Buch.....
Also, "Hallo World" über PHP und Apache geht schon mal, freufreu !
Aber folgendes geht nicht richtig:

in    unbenannt2.php   steht:
<?PHP
  echo "Jahr: $jahr";
?>

Als URI gebe ich ein:
http://localhost/phpProg/unbenannt2.php?jahr=2002

Im Browser erscheint nur -->  Jahr:

Es sollte aber  -->  Jahr: 2002
erscheinen.

Ich habe schon von PHP4 auf PHP5 gewechselt und drei verschiedene Browser (IE7, firefox, Netscape4.7)ausprobiert - ohne Erfolg!

Was kann ich noch machen?
Danke und Gruß, Kalle

[dedlfix]

echo $begrüßung;

Hallo, bin also absoluter Anfänger und versuche nach einem Buch.....
http://localhost/phpProg/unbenannt2.php?jahr=2002
  echo "Jahr: $jahr";
Im Browser erscheint nur -->  Jahr:

Dein Buch ist veraltet. Es ist schon seit langem nicht mehr üblich, dass aus den Query-String Variablen angelegt werden. Die Werte sind stattdessen im superglobalen Arrays $_GET zu finden. In deinem Fall $_GET['jahr']. Siehe Variables from outside PHP.

Ebenfalls bedenklich ist, dass du Benutzereingaben einfach ungeprüft ausgibst. Das kann man dann für XSS-Attacken ausnutzen. Statt
  echo "Jahr: $jahr";
oder neu
  echo "Jahr: " . $_GET['jahr'];
solltest du lieber
  echo "Jahr: " . htmlspecialchars($_GET['jahr']);
verwenden, dann werden die HTML-eigenen Zeichen <, >, & und auch das " entschärft und können nicht mehr zu ungewünschten HTML- und clientseitigem Script-Code führen.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

echo "Jahr: " . $_GET['jahr'];
  echo "Jahr: " . htmlspecialchars($_GET['jahr']);

Was ich vergaß: Es ist auch noch guter Programmierstil, vor dem Zugriff auf Variablen deren Existenz zweifelhaft ist, z.B. weil sie von außerhalb zur Verfügung gestellt wurden, zu überprüfen, ob sie überhaupt vorhanden sind. Dazu gibt es die Funktion isset().

if (isset($_GET['jahr']))
  echo "Jahr: " . htmlspecialchars($_GET['jahr']);
else
  echo "kein Jahr eingegeben";

echo "$verabschiedung $name";

[hkl]

Hallo dedifix !

Du hast natuerlich voellig recht mit dem Hinweis, dass die Query-Strings geprueft werden sollten.

Eines ist mir aber konzeptionell unklar, das hiermit korreliert:

» zu ungewünschten HTML- und clientseitigem Script-Code führen.

Koennte ein Client, wenn ihm ein Server irgendeinen "schmutzigen" Query-String zureuckschreibt ( einfaches "print" - natuerlich kein "eval" - das ist klar ), mehr Schaeden anrichten als wuede er sich das JS/PHP einfach in eine lokale Datei schreiben und ausfuehren ?

Evtl weil das Ganze ggf. innerhalb einer PHP-Sitzung erfolgt ?

Gruss

Holger

[dedlfix]

echo $begrüßung;

zu ungewünschten HTML- und clientseitigem Script-Code führen.
Koennte ein Client, wenn ihm ein Server irgendeinen "schmutzigen" Query-String zureuckschreibt ( einfaches "print" - natuerlich kein "eval" - das ist klar ), mehr Schaeden anrichten als wuede er sich das JS/PHP einfach in eine lokale Datei schreiben und ausfuehren ?

PHP lokal ausführen zu wollen dürfte ist nur in wenigen Fällen erfolgreich sein. Dazu müsste das jemand bei sich extra installiert haben. Aber Javascript haben die Browser eingebaut.

Der Kontext einer Webseite ist ein anderer als der einer lokalen Datei. Beide müssen nicht unbedingt in der gleichen Sicherheitszone - oder wie auch immer das die Browserhersteller nennen mögen - ausgeführt werden. Die lokale Datei ist vielleicht vertrauenswürdig, die Webseite nicht - oder umgekehrt.

Webseite B (wie böse) enthält einen Link mit schmutzigem Querystring, der auf Webseite A (wie artig) verweist. Dummerweise hat A aber eine XSS-Lücke und ist außerdem beim Client als vertrauenswürdig deklariert. Somit könnte B veranlassen, dass der Code in A Dinge ausführt, die für B einen Nutzen haben könnten. Auslesen von Cookie-Daten von A wäre ein Beispiel, darin könnten Anmeldedaten gespeichert sein.

B könnte auch auf A Aktionen veranlassen, die gegenüber dem Server wie Benutzeraktionen aussehen. In Zeiten von unsichtbar ablaufendem AJAX bieten sich da sicher einige hübsche Möglichkeiten ...

Evtl weil das Ganze ggf. innerhalb einer PHP-Sitzung erfolgt ?

Was ist denn eine Sitzung? Im Grunde doch nur das Speichern von ein paar Daten auf dem Server mit Identifikation durch einen eindeutigen vom Client bereitgestellten Schlüssel. Auch dieser Schlüssel lässt sich auslesen und vom Angreifer so verwenden, dass er im Kontext der Session etwas anstellt.

echo "$verabschiedung $name";

[hkl]

Hallo !

Die lokale Datei ist vielleicht vertrauenswürdig, die Webseite nicht - oder umgekehrt.

Okay, das vesteh ich.

Webseite B (wie böse) enthält einen Link mit schmutzigem Querystring, der auf Webseite A (wie artig) verweist. Dummerweise hat A aber eine XSS-Lücke
und ist außerdem beim Client als vertrauenswürdig deklariert. Somit könnte B veranlassen, dass der Code in A

Nicht andersherum ?
Wenn der Client beim Server A als vertrauenswuerdig bekannt ist  jetzt nicht wg. Bowser-Einstellungen sondern z.B. wg. der Firewall des Servers ?

Dinge ausführt, die für B einen Nutzen haben könnten.
Auslesen von Cookie-Daten von A wäre ein Beispiel, darin könnten Anmeldedaten gespeichert sein.

Das hingegen versteh ich nicht im dem Kontext "Query-Strings ungeprueft zuruckschreiben":

B macht ein response-redirect mit dem maliciuos code. Bon. A prueft nicht und schreibt den Code zum Client zurueck wo der ausgefuehrt wird und auf A irgendwas auloest ?

Das waere doch der gleiche Effekt als wuerde der malicious code direkt auf dem Client C ausgefuehrt. Und darin wuerde dannirgendwas auf der Site A passieren. Also macht sich A doch nicht da durch angreifbar, dass er den (JS-)String zuruecksendet, sondern dadurch dass er sich die Aktionen, die ueber das JS dann passieren, gefallen laesst.

Oder ?

Gruss

Holger

[dedlfix]

echo $begrüßung;

Webseite B (wie böse) enthält einen Link mit schmutzigem Querystring, der auf Webseite A (wie artig) verweist. Dummerweise hat A aber eine XSS-Lücke
und ist außerdem beim Client als vertrauenswürdig deklariert. Somit könnte B veranlassen, dass der Code in A

Nicht andersherum ?
Wenn der Client beim Server A als vertrauenswuerdig bekannt ist  jetzt nicht wg. Bowser-Einstellungen sondern z.B. wg. der Firewall des Servers ?

Mein Szenario war aus Sicht des Clients betrachtet. Die Webseite A ist beim Client als vertrauenswürdige Seite deklariert. Der Server und Gegebenheiten auf ihm sind beim XSS nicht primär von Belang (er wird erstmal nur für das Einschleusen des Codes benötigt, der beim Client ausgeführt werden soll).

Dinge ausführt, die für B einen Nutzen haben könnten.
Auslesen von Cookie-Daten von A wäre ein Beispiel, darin könnten Anmeldedaten gespeichert sein.

Das hingegen versteh ich nicht im dem Kontext "Query-Strings ungeprueft zuruckschreiben":

Genau das ist die Lücke, denn durch das Nicht-Prüfen/Nicht-Behandeln der Eingabedaten gelangt ja erst der Code anstelle von eigentlich harmlosen Nur-Text in den Kontext des Browsers.

Ich betrachte an dieser Stelle nur den Browser. Und A und B sind die Quellen von denen der Browser seinen HTML- und Javascript-Code bekommt.

B macht ein response-redirect mit dem maliciuos code. Bon. A prueft nicht und schreibt den Code zum Client zurueck wo der ausgefuehrt wird und auf A irgendwas auloest ?
Das waere doch der gleiche Effekt als wuerde der malicious code direkt auf dem Client C ausgefuehrt.

Der Unterschied ist, dass die Webseite A als vertrauenswürdige Quelle eingetragen ist, B aber nicht, und der Code der lokalen Datei niemals ausgeführt wird, wenn der Nutzer sie nicht explizit aufruft. Im Web falsch geklickt ist hingegen schnell.

Und darin wuerde dann irgendwas auf der Site A passieren. Also macht sich A doch nicht da durch angreifbar, dass er den (JS-)String zuruecksendet, sondern dadurch dass er sich die Aktionen, die ueber das JS dann passieren, gefallen laesst.

Das Zurücksenden ist letzlich die Ursache für das Auslösen von weiteren Aktionen, die der Benutzer nicht gewollt hat. Das können ganz harmlose Dinge sein, wie das Senden einer Nachricht an einen anderen Benutzer des Systems. Der Empfänger denkt, dass er den Absender kennt und vertraut ihm und im Text steht irgendeine Schweinerei.

Aus aktuellem Anlass: https://forum.selfhtml.org/?t=141240&m=917626

echo "$verabschiedung $name";

[hkl]

Hallo dedlfix !

das ist ja wohl die tollste und praezieseste Antwort die ich mir auf meine Fragen erhoffen konnte !!

Vielen Dank dafuer !

Viele Grusse

Holger

echo $begrüßung;

Webseite B (wie böse) enthält einen Link mit schmutzigem Querystring, der auf Webseite A (wie artig) verweist. Dummerweise hat A aber eine XSS-Lücke
und ist außerdem beim Client als vertrauenswürdig deklariert. Somit könnte B veranlassen, dass der Code in A

Nicht andersherum ?
Wenn der Client beim Server A als vertrauenswuerdig bekannt ist  jetzt nicht wg. Bowser-Einstellungen sondern z.B. wg. der Firewall des Servers ?

Mein Szenario war aus Sicht des Clients betrachtet. Die Webseite A ist beim Client als vertrauenswürdige Seite deklariert. Der Server und Gegebenheiten auf ihm sind beim XSS nicht primär von Belang (er wird erstmal nur für das Einschleusen des Codes benötigt, der beim Client ausgeführt werden soll).

Dinge ausführt, die für B einen Nutzen haben könnten.
Auslesen von Cookie-Daten von A wäre ein Beispiel, darin könnten Anmeldedaten gespeichert sein.

Das hingegen versteh ich nicht im dem Kontext "Query-Strings ungeprueft zuruckschreiben":

Genau das ist die Lücke, denn durch das Nicht-Prüfen/Nicht-Behandeln der Eingabedaten gelangt ja erst der Code anstelle von eigentlich harmlosen Nur-Text in den Kontext des Browsers.

Ich betrachte an dieser Stelle nur den Browser. Und A und B sind die Quellen von denen der Browser seinen HTML- und Javascript-Code bekommt.

B macht ein response-redirect mit dem maliciuos code. Bon. A prueft nicht und schreibt den Code zum Client zurueck wo der ausgefuehrt wird und auf A irgendwas auloest ?
Das waere doch der gleiche Effekt als wuerde der malicious code direkt auf dem Client C ausgefuehrt.

Der Unterschied ist, dass die Webseite A als vertrauenswürdige Quelle eingetragen ist, B aber nicht, und der Code der lokalen Datei niemals ausgeführt wird, wenn der Nutzer sie nicht explizit aufruft. Im Web falsch geklickt ist hingegen schnell.

Und darin wuerde dann irgendwas auf der Site A passieren. Also macht sich A doch nicht da durch angreifbar, dass er den (JS-)String zuruecksendet, sondern dadurch dass er sich die Aktionen, die ueber das JS dann passieren, gefallen laesst.

Das Zurücksenden ist letzlich die Ursache für das Auslösen von weiteren Aktionen, die der Benutzer nicht gewollt hat. Das können ganz harmlose Dinge sein, wie das Senden einer Nachricht an einen anderen Benutzer des Systems. Der Empfänger denkt, dass er den Absender kennt und vertraut ihm und im Text steht irgendeine Schweinerei.

Aus aktuellem Anlass: https://forum.selfhtml.org/?t=141240&m=917626

echo "$verabschiedung $name";

[Hamstar]

Was kann ich noch machen?

Sicherstellen, dass die Variable $jahr nicht "leer" ist. Ist diese erwiesenermassen nicht "leer" und es wird immer noch nichts angezeigt, ist die Wahrscheinlichkeit hoch, dass PHP nicht richtig installiert ist.

[dedlfix]

echo $begrüßung;

Sicherstellen, dass die Variable $jahr nicht "leer" ist. Ist diese erwiesenermassen nicht "leer" und es wird immer noch nichts angezeigt, ist die Wahrscheinlichkeit hoch, dass PHP nicht richtig installiert ist.

Wenn $jahr in dem Fall nicht existent ist, ist PHP richtig installiert. Alles andere ist früher mal so gewesen und ab PHP 6 auch nicht mehr konfigurierbar (Konfigurationseinstellung register_globals), da dieses Feature dann ausgestorben sein wird.

echo "$verabschiedung $name";

[Cheatah]

Hi,

Alles andere ist früher mal so gewesen und ab PHP 6 auch nicht mehr konfigurierbar (Konfigurationseinstellung register_globals), da dieses Feature dann ausgestorben sein wird.

hooray!

Chea "Endlich." tah