Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Firefox und generiertes Bild über eine gesicherte PHP-Datei
5 views
Skip to first unread message
Sven Ebert
May 10, 2012, 10:20:51 AM5/10/12
to
Hi :)
Scheinbar ruft Firefox (keine Ahnung ab welcher Version, auf jedenfall
schon seit einigen Versionen bis zur aktuellsten 12.0) ein Bild auf,
ohne mitzuliefern wo dieser Aufruf herkommt. Dies ist dann
Problematisch, wenn das Bild über einen PHP-Aufruf generiert wird und
dieses nur auf der jeweiligen Seite zur Verfügung stehen soll - also
nicht einfach jemand auf seiner eigenen Seite diese Funktion mit
benutzen kann.
Im Speziellen habe ich dieses Problem auf folgender Seite:
<http://www.dasradio.de/e107_plugins/sendeplan/sendeplan.php>
Was beim Firefox passiert ist, das überall wo der generierte Text bzw.
das Bild stehen sollte immer nur "Eigentum von www.das-radio.de"
auftaucht, weil dort scheinbar dieser Schutzmechanismus greift. Zum Test
habe ich die Seite auch mal im IE aufgerufen und dieser löst diesen
Schutzmechanismus nicht aus. Im nachfolgenden Bild habe ich beides mal
als Screenshot zusammengefasst.
<http://imgs.to/uwy/das_radio_FF_IE.png>
Zuerst dachte ich es hätte eventuell mit Cookies, oder AB+ zu tun, aber
beides schon gelöscht bzw. deaktiviert und es wird immer noch so angezeigt.
Ich habe mal im Quelltext nach einer Stelle gesucht welche so einen
Aufruf auslöst und bin da auf folgendes gestoßen.
<img
src="/textout.php?size=18&color=EEEEEE&glow=FFFFFF&dist=1&text=hört%20ihr"
alt="" />
Auch wenn ich kein Experte im HTML/PHP bin, aber so auf den ersten Blick
sieht das schon mal ganz normal aus und sollte eigentlich keine Probleme
machen.
Auch kann ich mir erst mal nicht vorstellen, dass in dieser textout.php
eine IE-Only-Funktion genutzt wird, denn ich habe von der Seite ein
Cookie "PHPSESSID" und gehe mal davon aus, dass hier ganz normale
Schutzmechanismen greifen, welche auch auf jeder PHP-Basierten Seite zum
Tragen kommen und ja scheinbar auch erst mal generell mit jedem Browser
zusammenarbeiten.
Da ich aber keine Ahnung habe, ob dies nicht eventuell doch an meinem
Firefox/Addons liegt, meine Frage: Kann dies jemand ebenfalls
nachvollziehen?
Falls es nicht nur an meinem FF liegt (es also wirklich ein generelles
Problem ist) - hat ggf. jemand eine Lösung wie man dem FF beibringen
kann Bildaufrufe ebenso mit allen php-relevanten Informationen
durchzuführen, wie dies wohl auch bei allen anderen Aufrufen der Fall ist?
Ciao
Sven
PS: Wie schon erwähnt, bin wirklich kein Experte in solch tief
greifender Programmierung und deswegen bitte nicht hauen, wenn meine
obigen Theorien zu dem Problem ganz und gar nicht passen. Ist halt das
was ich mir da bis jetzt draus reimen konnte.
Scheinbar ruft Firefox (keine Ahnung ab welcher Version, auf jedenfall
schon seit einigen Versionen bis zur aktuellsten 12.0) ein Bild auf,
ohne mitzuliefern wo dieser Aufruf herkommt. Dies ist dann
Problematisch, wenn das Bild über einen PHP-Aufruf generiert wird und
dieses nur auf der jeweiligen Seite zur Verfügung stehen soll - also
nicht einfach jemand auf seiner eigenen Seite diese Funktion mit
benutzen kann.
Im Speziellen habe ich dieses Problem auf folgender Seite:
<http://www.dasradio.de/e107_plugins/sendeplan/sendeplan.php>
Was beim Firefox passiert ist, das überall wo der generierte Text bzw.
das Bild stehen sollte immer nur "Eigentum von www.das-radio.de"
auftaucht, weil dort scheinbar dieser Schutzmechanismus greift. Zum Test
habe ich die Seite auch mal im IE aufgerufen und dieser löst diesen
Schutzmechanismus nicht aus. Im nachfolgenden Bild habe ich beides mal
als Screenshot zusammengefasst.
<http://imgs.to/uwy/das_radio_FF_IE.png>
Zuerst dachte ich es hätte eventuell mit Cookies, oder AB+ zu tun, aber
beides schon gelöscht bzw. deaktiviert und es wird immer noch so angezeigt.
Ich habe mal im Quelltext nach einer Stelle gesucht welche so einen
Aufruf auslöst und bin da auf folgendes gestoßen.
<img
src="/textout.php?size=18&color=EEEEEE&glow=FFFFFF&dist=1&text=hört%20ihr"
alt="" />
Auch wenn ich kein Experte im HTML/PHP bin, aber so auf den ersten Blick
sieht das schon mal ganz normal aus und sollte eigentlich keine Probleme
machen.
Auch kann ich mir erst mal nicht vorstellen, dass in dieser textout.php
eine IE-Only-Funktion genutzt wird, denn ich habe von der Seite ein
Cookie "PHPSESSID" und gehe mal davon aus, dass hier ganz normale
Schutzmechanismen greifen, welche auch auf jeder PHP-Basierten Seite zum
Tragen kommen und ja scheinbar auch erst mal generell mit jedem Browser
zusammenarbeiten.
Da ich aber keine Ahnung habe, ob dies nicht eventuell doch an meinem
Firefox/Addons liegt, meine Frage: Kann dies jemand ebenfalls
nachvollziehen?
Falls es nicht nur an meinem FF liegt (es also wirklich ein generelles
Problem ist) - hat ggf. jemand eine Lösung wie man dem FF beibringen
kann Bildaufrufe ebenso mit allen php-relevanten Informationen
durchzuführen, wie dies wohl auch bei allen anderen Aufrufen der Fall ist?
Ciao
Sven
PS: Wie schon erwähnt, bin wirklich kein Experte in solch tief
greifender Programmierung und deswegen bitte nicht hauen, wenn meine
obigen Theorien zu dem Problem ganz und gar nicht passen. Ist halt das
was ich mir da bis jetzt draus reimen konnte.
Sascha Grage
May 10, 2012, 10:32:43 AM5/10/12
to
Sven Ebert meinte:
> Da ich aber keine Ahnung habe, ob dies nicht eventuell doch an meinem
> Firefox/Addons liegt, meine Frage: Kann dies jemand ebenfalls
> nachvollziehen?
Kann ich nicht nachvollziehen. Screenshot:
https://docs.google.com/file/d/0B1DP28fRO4hvb3M5UGNrZmlvYVk/edit?pli=1
Im Safe-Mode probieren, falls Problem noch vorhanden, neues Testprofil...
bye,
Sascha
--
Deep 'n Dance Radio | www.deepanddanceradio.com
Chicago House Radio | www.chicagohouseradio.com
(c)
np:
> Da ich aber keine Ahnung habe, ob dies nicht eventuell doch an meinem
> Firefox/Addons liegt, meine Frage: Kann dies jemand ebenfalls
> nachvollziehen?
https://docs.google.com/file/d/0B1DP28fRO4hvb3M5UGNrZmlvYVk/edit?pli=1
Im Safe-Mode probieren, falls Problem noch vorhanden, neues Testprofil...
bye,
Sascha
--
Deep 'n Dance Radio | www.deepanddanceradio.com
Chicago House Radio | www.chicagohouseradio.com
(c)
np:
Arno Welzel
May 10, 2012, 10:44:54 AM5/10/12
to
Am 10.05.2012 16:20, schrieb Sven Ebert:
> Scheinbar ruft Firefox (keine Ahnung ab welcher Version, auf jedenfall
> schon seit einigen Versionen bis zur aktuellsten 12.0) ein Bild auf,
> ohne mitzuliefern wo dieser Aufruf herkommt. Dies ist dann
Du meinst den HTTP-Referer - nein, er schickt den Referer auch bei
> Scheinbar ruft Firefox (keine Ahnung ab welcher Version, auf jedenfall
> schon seit einigen Versionen bis zur aktuellsten 12.0) ein Bild auf,
> ohne mitzuliefern wo dieser Aufruf herkommt. Dies ist dann
Bildern mit. Ich vermute eher, Du hast irgendein AddOn installiert, dass
hier Probleme macht. Schon mal mit einem neuen Profil oder im "Safe
Mode" probiert?
> Problematisch, wenn das Bild über einen PHP-Aufruf generiert wird und
> dieses nur auf der jeweiligen Seite zur Verfügung stehen soll - also
> nicht einfach jemand auf seiner eigenen Seite diese Funktion mit
> benutzen kann.
>
> Im Speziellen habe ich dieses Problem auf folgender Seite:
>
> <http://www.dasradio.de/e107_plugins/sendeplan/sendeplan.php>
>
> Was beim Firefox passiert ist, das überall wo der generierte Text bzw.
> das Bild stehen sollte immer nur "Eigentum von www.das-radio.de"
> auftaucht, weil dort scheinbar dieser Schutzmechanismus greift. Zum Test
Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
Abfrage der HTTP-Referer reichlich unsinnig ist, da jeder einen
passenden Referrer selber mitschicken kann - etwa wenn jemand das Bild
mit curl o.Ä. auf seinem eigenen Server holt.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
Sebastian Will
May 10, 2012, 11:30:59 AM5/10/12
to
Am 10.05.2012 16:20, schrieb Sven Ebert:
> Falls es nicht nur an meinem FF liegt (es also wirklich ein generelles
> Problem ist) - hat ggf. jemand eine Lösung wie man dem FF beibringen
> kann Bildaufrufe ebenso mit allen php-relevanten Informationen
> durchzuführen, wie dies wohl auch bei allen anderen Aufrufen der Fall ist?
Wie schon gesagt wurde, hat es mit dem Referer zu tun. Rufe mal
> Problem ist) - hat ggf. jemand eine Lösung wie man dem FF beibringen
> kann Bildaufrufe ebenso mit allen php-relevanten Informationen
> durchzuführen, wie dies wohl auch bei allen anderen Aufrufen der Fall ist?
about:config auf und schau, welcher Wert bei
network.http.sendRefererHeader steht.
Wenn dort 0 steht, ändere es auf 2 und es sollte wieder funktionieren.
--
Gruß,
Sebastian
http://www.lastfm.de/user/MusikRebell
Sven Ebert
May 10, 2012, 11:45:56 AM5/10/12
to
Ändern auf 2 ging es nun tatsächlich. Vielen Dank :)
Allerdings weiß ich nicht warum es auf 1 stand - auch wenn ich schon mal
in der about:config drin war, habe ich nur ganz wenige Sachen selbst
eingestellt und auch nur nach in der Regel vertrauenswürdigen Seiten.
Falls aber 1 irgendwann mal standard war, könnte es tatsächlich an
meinem seit Generationen mitgeschleppten Profil liegen.
Ciao
Sven
PS: Mein Dank geht auch an Sascha und Arno - an neues Profil und Safe
Mode hatte ich schon gar nicht mehr gedacht bezüglich Testen :)
Peter J. Holzer
May 12, 2012, 5:12:34 AM5/12/12
to
On 2012-05-10 14:44, Arno Welzel <use...@arnowelzel.de> wrote:
> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
> Abfrage der HTTP-Referer reichlich unsinnig ist,
Da stimme ich zu.
> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
> Abfrage der HTTP-Referer reichlich unsinnig ist,
> da jeder einen passenden Referrer selber mitschicken kann - etwa wenn
> jemand das Bild mit curl o.Ä. auf seinem eigenen Server holt.
Der Referrer-Check soll nicht dagegen schützen, dass jemand das Bild
kopiert. Dagegen kann er nicht schützen, dann natürlich muss das Bild an
den Client übertragen werden, um angezeigt zu werden und dann kann es
auch abgespeichert werden.
Der Referrer-Check soll dagegen schützen, dass jemand anderer auf seiner
Website mittels <img src="..."/> einbindet. In den 90er-Jahren, als ein
Webspace typischerweise <= 10 MB groß[1] und Traffic auf wenige 100 MB
pro Monat beschränkt war, war die Versuchung natürlich groß, Platz- und
Traffickosten anderen aufzubürden, und dementsprechend auch der Anreiz
gegeben, sich dagegen zu wehren. Diesen Zweck erfüllt der
Referrer-Check, denn der Server, der die Seite ausliefert, hat keine
Möglichkeit, dem Client zu sagen, welchen Referrer er beim Laden der
Bilder mitschicken soll. Der Besitzer des Clients hätte zwar
theoretisch die Möglichkeit, den Referrer zu setzen, in der Praxis
mangelt es ihm aber an technischem Wissen und auch am Wollen. Er wird
feststellen, dass die Seite "nicht funktioniert" und sich woanders
umsehen. Mission accomplished.
hp
[1] Eunet.at hat anlässlich der Einführung des Euro den Webspace auf
13.7603 MB aufgestockt.
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org
Arno Welzel
May 15, 2012, 4:32:11 AM5/15/12
to
Am 12.05.2012 11:12, schrieb Peter J. Holzer:
> On 2012-05-10 14:44, Arno Welzel<use...@arnowelzel.de> wrote:
>> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
>> Abfrage der HTTP-Referer reichlich unsinnig ist,
>
> Da stimme ich zu.
>
>> da jeder einen passenden Referrer selber mitschicken kann - etwa wenn
>> jemand das Bild mit curl o.Ä. auf seinem eigenen Server holt.
>
> Bei der Begründung aber nicht.
>
> Der Referrer-Check soll nicht dagegen schützen, dass jemand das Bild
> kopiert. Dagegen kann er nicht schützen, dann natürlich muss das Bild an
> den Client übertragen werden, um angezeigt zu werden und dann kann es
> auch abgespeichert werden.
>
> Der Referrer-Check soll dagegen schützen, dass jemand anderer auf seiner
> Website mittels<img src="..."/> einbindet. In den 90er-Jahren, als ein
Das kann er trotzdem. Indem er eben curl, fopen() o.Ä. in PHP benutzt
> On 2012-05-10 14:44, Arno Welzel<use...@arnowelzel.de> wrote:
>> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
>> Abfrage der HTTP-Referer reichlich unsinnig ist,
>
> Da stimme ich zu.
>
>> da jeder einen passenden Referrer selber mitschicken kann - etwa wenn
>> jemand das Bild mit curl o.Ä. auf seinem eigenen Server holt.
>
> Bei der Begründung aber nicht.
>
> Der Referrer-Check soll nicht dagegen schützen, dass jemand das Bild
> kopiert. Dagegen kann er nicht schützen, dann natürlich muss das Bild an
> den Client übertragen werden, um angezeigt zu werden und dann kann es
> auch abgespeichert werden.
>
> Der Referrer-Check soll dagegen schützen, dass jemand anderer auf seiner
> Website mittels<img src="..."/> einbindet. In den 90er-Jahren, als ein
und sich das Bild so vom anderen Server holt, ohne es lokal auf seinem
eigenen Webspace speichern zu müssen. Das geht mit 2 Befehlen in PHP und
kann auch so universell gemacht werden, dass es für jedes Bild funktioniert.
Peter J. Holzer
May 15, 2012, 6:40:33 AM5/15/12
to
On 2012-05-15 08:32, Arno Welzel <use...@arnowelzel.de> wrote:
> Am 12.05.2012 11:12, schrieb Peter J. Holzer:
>> On 2012-05-10 14:44, Arno Welzel<use...@arnowelzel.de> wrote:
>>> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
>>> Abfrage der HTTP-Referer reichlich unsinnig ist,
>>
>> Da stimme ich zu.
>>
>>> da jeder einen passenden Referrer selber mitschicken kann - etwa wenn
>>> jemand das Bild mit curl o.Ä. auf seinem eigenen Server holt.
>>
>> Bei der Begründung aber nicht.
>>
>> Der Referrer-Check soll nicht dagegen schützen, dass jemand das Bild
>> kopiert. Dagegen kann er nicht schützen, dann natürlich muss das Bild an
>> den Client übertragen werden, um angezeigt zu werden und dann kann es
>> auch abgespeichert werden.
>>
>> Der Referrer-Check soll dagegen schützen, dass jemand anderer auf seiner
>> Website mittels<img src="..."/> einbindet. In den 90er-Jahren, als ein
>
> Das kann er trotzdem.
Nein.
> Am 12.05.2012 11:12, schrieb Peter J. Holzer:
>> On 2012-05-10 14:44, Arno Welzel<use...@arnowelzel.de> wrote:
>>> Dennoch sollte man den Betreibern mitteilen, dass ein "Schutz" über die
>>> Abfrage der HTTP-Referer reichlich unsinnig ist,
>>
>> Da stimme ich zu.
>>
>>> da jeder einen passenden Referrer selber mitschicken kann - etwa wenn
>>> jemand das Bild mit curl o.Ä. auf seinem eigenen Server holt.
>>
>> Bei der Begründung aber nicht.
>>
>> Der Referrer-Check soll nicht dagegen schützen, dass jemand das Bild
>> kopiert. Dagegen kann er nicht schützen, dann natürlich muss das Bild an
>> den Client übertragen werden, um angezeigt zu werden und dann kann es
>> auch abgespeichert werden.
>>
>> Der Referrer-Check soll dagegen schützen, dass jemand anderer auf seiner
>> Website mittels<img src="..."/> einbindet. In den 90er-Jahren, als ein
>
> Das kann er trotzdem.
> Indem er eben curl, fopen() o.Ä. in PHP benutzt
> und sich das Bild so vom anderen Server holt, ohne es lokal auf seinem
> eigenen Webspace speichern zu müssen.
und nicht das Bild eines anderen Servers eingebettet. Dass dabei die
Kopie bei jedem Zugriff neu erzeugt wird (und eventuell zu keinem
Zeitpunkt vollständig ist) ändert prinzipiell nichts. Es mag geringfügig
Speicherplatz sparen, dafür hat es auf den Traffic genau den
gegenteiligen Effekt (Verdoppelung statt Ersparnis).
> Das geht mit 2 Befehlen in PHP und kann auch so universell gemacht
> werden, dass es für jedes Bild funktioniert.
hp
Arno Welzel
May 15, 2012, 9:39:24 AM5/15/12
to
Am 15.05.2012 12:40, schrieb Peter J. Holzer:
> On 2012-05-15 08:32, Arno Welzel<use...@arnowelzel.de> wrote:
[...]
> On 2012-05-15 08:32, Arno Welzel<use...@arnowelzel.de> wrote:
>> Indem er eben curl, fopen() o.Ä. in PHP benutzt
>> und sich das Bild so vom anderen Server holt, ohne es lokal auf seinem
>> eigenen Webspace speichern zu müssen.
>
> Auch hier wird das Bild vom eigenen Server an den Browser ausgeliefert
> und nicht das Bild eines anderen Servers eingebettet. Dass dabei die
> Kopie bei jedem Zugriff neu erzeugt wird (und eventuell zu keinem
> Zeitpunkt vollständig ist) ändert prinzipiell nichts. Es mag geringfügig
> Speicherplatz sparen, dafür hat es auf den Traffic genau den
> gegenteiligen Effekt (Verdoppelung statt Ersparnis).
Richtig.
>> und sich das Bild so vom anderen Server holt, ohne es lokal auf seinem
>> eigenen Webspace speichern zu müssen.
>
> Auch hier wird das Bild vom eigenen Server an den Browser ausgeliefert
> und nicht das Bild eines anderen Servers eingebettet. Dass dabei die
> Kopie bei jedem Zugriff neu erzeugt wird (und eventuell zu keinem
> Zeitpunkt vollständig ist) ändert prinzipiell nichts. Es mag geringfügig
> Speicherplatz sparen, dafür hat es auf den Traffic genau den
> gegenteiligen Effekt (Verdoppelung statt Ersparnis).
Es ging mir nur um die Illustration, wie simpel die Umgehung solcher
"Sperren" ist und wie unsinnig sie sind. Ähnlich wie manche Schlaumeier
die Benutzung der rechten Maustaste per JavaScript unterbinden, weil sie
glauben, man könne so Leute davon abhalten, Inhalte lokal abzuspeichern
- also ob das Kontextmenü per Maus die einzige Möglichkeit wäre.
0 new messages