HTTP_REFERER

[Richie]

hallo

Ich hab versucht eine seite durch den HTTP_REFERER zu schützen, dieser, so hab ich gehört enthält die adresse des formulars mit dem submit botton...

Jedoch bleibt dieser immer leer...
Dann hab ich gesucht und herausgefunden dass manche firewalls den HTTP_REFERER löschen und hab diese ausgeschalten.... ohne erfolg... es funktioniert immer noch nicht...

Hat irgendwer von euch eine idee woran das liegen könnt oder eine besseren Vorschlag wie ich eine Datei schützen kann so dass man nicht mit der direkten Adresse darauf zugreifen kann sondern nur durch den login...

thx Richie

PS:<?
if(!eregi("http://itchy.uttx.net/login.php",$HTTP_REFERER))
header("Location:http://itchy.uttx.net/login.php")
?>

Das ist der code den ich vor der geschützen datei gesetzt hab...

[Dennis]

Hi Richie,

<?

if(!eregi("http://itchy.uttx.net/login.php",$HTTP_REFERER))
header("Location:http://itchy.uttx.net/login.php")
?>

  
Du greifst auf die falsche Variable zurück! Der HTTP\_REFERER steht in `$_SERVER['HTTP_REFERER'];`{:.language-php}.  
  
Lasse dir zur Information auch mal das ganze $\_SERVER Array ausgeben:  
~~~php
<?php  
echo "<pre>";  
print_r($_SESSION);  
echo "</pre>";  
?>

In Anbetracht der Tatsache, dass manche Firewalls den Referer löschen oder man die Übermittlung des Referers in machen Browsern auch abstellen kann, solltest du die Abfrage so gestalten:

<?php  
if(!eregi("http://itchy.uttx.net/login.php", $_SERVER['HTTP_REFERER')  
   AND !empty($_SERVER['HTTP_REFERER']))  
{  
   header("Location: http://itchy.uttx.net/login.php");  
}  
?>

Beachte allerdings, dass dies immer noch nicht "schummelsicher" ist. Man kann dir auch einen falschen Referer unterschieben - dann ist dein ganzer Schutz zunichte ;-)

MfG, Dennis.

[Richie]

Geht das wirklich so leicht??

Welche möglichkeit hab ich das vollkommen zu schützen??

mfg richie

[Dennis]

Hi Richie,

Geht das wirklich so leicht??

Ja.

Welche möglichkeit hab ich das vollkommen zu schützen??

Ich will nicht lang rumdrucksen: Gar keine.

Wozu auch? Was willst du verhindern?

MfG, Dennis.

[Richie]

Mit $Server_['Http_Referer'] funktionierts nur kann ich wenn ich mich eingeloggt hab auf die anderen geschützten php dateien auch zugreifen
woran kann das liegen??

mfg richie

[Dennis]

Hi Richie,

Mit $Server_['Http_Referer'] funktionierts ...

Damit sicher nicht, du meinst $_SERVER['HTTP_REFERER'] (Großbuchstaben sind wichtig!).

...nur kann ich wenn ich mich eingeloggt hab auf die anderen geschützten php dateien auch zugreifen
woran kann das liegen??

Ist das nicht der Sinn des einloggens??

MfG, Dennis.

[Richie]

Das man das groß schreiben muss ist mir schon klar ich wollt mich damit nur nicht aufhalten...

...nur kann ich wenn ich mich eingeloggt hab auf die anderen geschützten php dateien auch zugreifen
woran kann das liegen??

»»Ist das nicht der Sinn des einloggens??

Nicht wenn das die persönlichen Daten des anderen users sind...

mfg Richie

[Johannes Zeller]

Hallo Richie,

»»Ist das nicht der Sinn des einloggens??

Nicht wenn das die persönlichen Daten des anderen users sind...

Dann muss es irgendwo in deinem Programm noch mehr Fehler geben. Aber ohne dass du genauer erklärst, wie das aufgebaut ist, kann man leider noch nicht mal Vermutungen darüber anstellen, wo der liegen könnte.

Schöne Grüße,

Johannes

[Johannes Zeller]

Hallo Dennis,

Geht das wirklich so leicht??

Ja, das tut es.

Welche möglichkeit hab ich das vollkommen zu schützen??

Durch Überprüfen des Referrers: Keine. Deshalb solltest du dich von dieser
Vorgehensweise verabschieden und dich mit Sessions beschäftigen. _Das_ ist die Lösung für dein Problem.

Schöne Grüße,

Johannes

[Johannes Zeller]

Hallo Richie,

Ich hab versucht eine seite durch den HTTP_REFERER zu schützen, dieser, so hab ich gehört enthält die adresse des formulars mit dem submit botton...

Da diese Angabe vom Client übertragen wird, kann da auch was komplett anderes oder gar nichts drin stehen. Oft werden auf diese Weise z.B. eigene Webseiten »beworben«, such mal nach »Referrer Spam«. Du kannst dich also nicht darauf verlassen.

Hat irgendwer von euch eine idee woran das liegen könnt oder eine besseren Vorschlag wie ich eine Datei schützen kann so dass man nicht mit der direkten Adresse darauf zugreifen kann sondern nur durch den login...

Da ich durch dein folgendes Code-Beispiel vermute, dass du nicht HTML sondern PHP meinst, rate ich dir mal unter http://de3.php.net/manual/en/ref.session.php zu gucken. Das dürfte die Lösung für dein Problem sein.

PS:<?
if(!eregi("http://itchy.uttx.net/login.php",$HTTP_REFERER))
header("Location:http://itchy.uttx.net/login.php")
?>

Noch drei Anmerkungen dazu:

1. Verschichte auf die Kurzform der PHP-Tags wie <? ... ?>, das ist schlechter Stil. Verwende lieber die Komplettform <?php ... ?>.

2. Es ist hier überhaupt nicht nötig mit regulären Ausdrücken zu arbeiten, strcasecmp() reicht hier völlig aus.

3. $HTTP_REFERER sollte nicht mehr verwendet werden bzw. ist überhaupt nicht mehr verfügbar, falls in der Konfiguration register_globals auf Off gesetzt ist. Seit PHP 4.2.0 ist das so auch die Standardeinstellung. Der Grund dafür lag darin, dass es sonst bei schlecht programmierten Scripten unter Umständen möglich war bösartigen Code einzuschleusen. (Mehr dazu: http://www.php.net/manual/en/security.globals.php)

Stattdessen solltest du es so wie in http://www.php.net/manual/en/language.variables.predefined.php beschrieben machen. In deinem Fall müsstest du also $HTTP_REFERER durch $_SERVER['HTTP_REFERER'] ersetzen.

Hier könnte dein Problem also auch begründet liegen. Um die Einstellung für register_globals auf deinem System herauszufinden, kannst du eine Date anlegen, die nur <?php phpinfo(); ?> enthält. Beim Aufruf dieser Datei werden dir dann Informationen über das System deines Servers angezeigt, u.a. auch die Konfigurationseinstellungen.

Aber auch wenn du damit das Referrer-Problem scheinbar gelöst hast, ist es nicht die richtige Lösung für dein Problem, da es nicht sicher ist. Verwende also deshalb Sessions.

Schöne Grüße,

Johannes

[Ashura]

Hallo Johannes.

1. Verschichte auf die Kurzform der PHP-Tags wie <? ... ?>, das ist schlechter Stil. Verwende lieber die Komplettform <?php ... ?>.

Hat das eine bestimmte Bewandtnis?
Anders gefragt: Warum sollte man die Short-Open-Tags nicht verwenden?

Gruß, Ashura

[Dennis]

Hi Ashura,

Anders gefragt: Warum sollte man die Short-Open-Tags nicht verwenden?

Weil diese deaktiviert sein können.

Könnte man genauso gut fragen: "Warum soll ich nicht $foobar statt $_POST['foobar'] nehmen?" ;-)

MfG, Dennis.

[Johannes Zeller]

Hallo Dennis,

Könnte man genauso gut fragen: "Warum soll ich nicht $foobar statt $_POST['foobar'] nehmen?" ;-)

Nein, denn bei register_globals geht es auch noch um Sicherheitsaspekte. Das _sollte_ also sogar deaktiviert sein.

Schöne Grüße,

Johannes

[Dennis]

Hi Johannes,

Könnte man genauso gut fragen: "Warum soll ich nicht $foobar statt $_POST['foobar'] nehmen?" ;-)

Nein, denn bei register_globals geht es auch noch um Sicherheitsaspekte. Das _sollte_ also sogar deaktiviert sein.

Na ja, man kann ein Script auch so programmieren, dass es (um beim obigen Bsp. zu bleiben) $foobar nutzt und trotzdem sicher[tm] ist - ist natürlich aufwendiger und erfordert mehr Aufmerksamkeit, aber möglich ist es.

MfG, Dennis.

[Johannes Zeller]

Hallo Dennis,

Nein, denn bei register_globals geht es auch noch um Sicherheitsaspekte. Das _sollte_ also sogar deaktiviert sein.

Na ja, man kann ein Script auch so programmieren, dass es (um beim obigen Bsp. zu bleiben) $foobar nutzt und trotzdem sicher[tm] ist - ist natürlich aufwendiger und erfordert mehr Aufmerksamkeit, aber möglich ist es.

Nein, eigentlich ist es nicht aufwendiger. Es ist (oder sollte zumindest so sein ;-)) eine Selbstverständlichkeit alle Variablen vor ihrer Verwendung zu
initialisieren, das sollte man unabhängig von register_globals _immer_ machen.

Bei register_globals erhöht sich nur das Risiko, falls man dies einmal vergisst
bzw. wenn der Programmierer nicht programmieren kann. Deshalb sollte man auch
beim Testen grundsätzlich alle Fehler (E_ALL, also auch Notices) anzeigen
lassen.[1]

Schöne Grüße,

Johannes

[1] Auf einem Produktivserver dagegen gar keine, da es sonst möglich ist, dass
ein Unbefugter zu viele Informationen über das System herausfindet. Hier
gehören dann die Fehlermeldungen ins Log.

[Dennis]

Hi Johannes,

[1] Auf einem Produktivserver dagegen gar keine, da es sonst möglich ist, dass
ein Unbefugter zu viele Informationen über das System herausfindet. Hier
gehören dann die Fehlermeldungen ins Log.

Hm, wenn man aber bei seinem Provider (da nur Webspace und kein Server) keinen Zugrif auf die PHP Error Log-Datei bekommt?
Eine umständliche Methode wäre natürlich manuell überalle eventuelle Fehlermeldungen abzufangen und eine eigene Log-Datei zu schreiben....

MfG, Dennis.

[Johannes Zeller]

Hallo Dennis,

[1] Auf einem Produktivserver dagegen gar keine, da es sonst möglich ist, dass
ein Unbefugter zu viele Informationen über das System herausfindet. Hier
gehören dann die Fehlermeldungen ins Log.

Hm, wenn man aber bei seinem Provider (da nur Webspace und kein Server) keinen Zugrif auf die PHP Error Log-Datei bekommt?

...dann sollte man den Provider wechseln, bzw. diesen dazu bitten, dass er es
einem zur Verfügung stellt. Ich weiß auch, dass es Provider gibt, die dies
nicht tun. Bei dem ersten Provider, bei dem ich war gab es auch kein PHP-Error-
Log. Der Provider ist wenige Monate, nachdem ich dort Kunde geworden bin,
bankrott gegangen.

Ein PHP-Errorlog gehört meiner Meinung nach aber zu den Dingen, die man als
Webseitenbetreiber[1] definitiv benötigt. Sonst bekommt man ja meistens gar
nicht mit, dass Fehler beim Aufruf des Scripts aufgetreten sind oder etwas
nicht ganz so funktioniert, wie es sollte.

Eine umständliche Methode wäre natürlich manuell überalle eventuelle Fehlermeldungen abzufangen und eine eigene Log-Datei zu schreiben....

Wenn man den Provider nicht wechseln will und dieser auch nicht bereit ist,
eine Logdatei anzulegen, bleibt einem wirklich nichts anderes übrig.

Schöne Grüße,

Johannes

[1] Natürlich nur, wenn man auch PHP einsetzt ;-)

[Dennis]

Hi Johannes,

Ein PHP-Errorlog gehört meiner Meinung nach aber zu den Dingen, die man als
Webseitenbetreiber[1] definitiv benötigt. Sonst bekommt man ja meistens gar
nicht mit, dass Fehler beim Aufruf des Scripts aufgetreten sind oder etwas
nicht ganz so funktioniert, wie es sollte.

Habe gerade noch mal geguckt - sowohl bei 1und1 als auch bei allinkl.com kriege ich (zumindest per FTP) keine PHP-ErrorLog. Ich kriege lediglich die access.log und eine ftp.log ...

MfG, Dennis.

[Johannes Zeller]

Hallo Ashura,

1. Verschichte auf die Kurzform der PHP-Tags wie <? ... ?>, das ist schlechter Stil. Verwende lieber die Komplettform <?php ... ?>.

Hat das eine bestimmte Bewandtnis?

Ja, hat es.

Anders gefragt: Warum sollte man die Short-Open-Tags nicht verwenden?

Die Kurzform sowie die ASP-Form kann man in der Konfiguration deaktivieren. Die Scripte sind dann also weniger portabel.

Ein Grund, weshalb man das deaktivieren wollen könnte, ist zum Beispiel beim Einsatz von XHTML oder XML allgemein. Schließlich ist es meistens nicht so gedacht, dass die XML-Deklaration als PHP geparst wird ;-)

Schöne Grüße,

Johannes

[Ashura]

Hallo Johannes.

Die Kurzform sowie die ASP-Form kann man in der Konfiguration deaktivieren. Die Scripte sind dann also weniger portabel.

Gut, mit ASP arbeite ich nicht. Und dass man die Short-Open-Tags deaktivieren kann, war mir bereits bewusst.
Jedoch lokal auf meinem Rechner, als auch auf meinem Remoteserver sind diese aktiviert.

Ich merke es mir aber für die Zukunft. ;)

Schließlich ist es meistens nicht so gedacht, dass die XML-Deklaration als PHP geparst wird ;-)

Das habe ich bisher immer mit einem echo '<?xml version""?>'; anstelle des einfachen <?xml version=""?> umgangen.
Für diese eine Zeile erschien mir der geringe Mehraufwand bisher immer gerechtfertigt.

Gruß, Ashura

[Auge]

Hallo

Das habe ich bisher immer mit einem echo '<?xml version""?>'; anstelle des einfachen <?xml version=""?> umgangen.
Für diese eine Zeile erschien mir der geringe Mehraufwand bisher immer gerechtfertigt.

Darum ging es Johannes nicht (behaupte ich mal). Beides fängt mit "<?" an. Damit es da zu keinen Verwechslungen kommt, muss man in xml die Sprache spezifizieren, also "<?php" oder "<?xml".

Tschö, Auge

[Ashura]

Hallo Auge.

Darum ging es Johannes nicht (behaupte ich mal). Beides fängt mit "<?" an.

Eben. Also kann man z. B. in einer PHP-Datei, in der HTML Code steht nicht einfach so <?xml...?> schreiben, ohne dass die PHP-Codeschnipsel hervorgehoben werden. (Also entweder mit <?php ?> oder eben meiner echo Methode.)

Damit es da zu keinen Verwechslungen kommt, muss man in xml die Sprache spezifizieren, also "<?php" oder "<?xml".

Muss man das nicht sowieso?

Gruß, Ashura

[Auge]

Hallo

Damit es da zu keinen Verwechslungen kommt, muss man in xml die Sprache spezifizieren, also "<?php" oder "<?xml".

Muss man das nicht sowieso?

Ja eben. Dann kann man das auch gleich grundsätzlich tun. Ich habe jedenfalls noch keinen Server gesehen, auf dem "<?php" nicht aktiviert gewesen wäre. Wär' ja, spätestens beim Einsatz von XHTML, auch quatsch.

Tschö, Auge

[Johannes Zeller]

Hallo Auge,

Ja eben. Dann kann man das auch gleich grundsätzlich tun. Ich habe jedenfalls noch keinen Server gesehen, auf dem "<?php" nicht aktiviert gewesen wäre. Wär' ja, spätestens beim Einsatz von XHTML, auch quatsch.

Das lässt sich auch nicht deaktivieren. Lediglich die Formen <? ... ?> und <% .
.. %> lassen sich deaktivieren.

Schöne Grüße,

Johannes