nicht angemeldet
Bilderklau verhindern
Hallo,
oftmals "klauen" Homepagebetreiber Bilder durch direktes Einbinden.
Dies verursacht unnötigen Trafic auf der eigenen Seite. Mit diesem
Skript
siehe http://webdienst.webdienst.de/bildklau/
könnte Ihr dem Bilderklau ein Ende setzen.
-
Hi,
oftmals "klauen" Homepagebetreiber Bilder durch direktes Einbinden.
Dies verursacht unnötigen Trafic auf der eigenen Seite. Mit diesem
Skript[Werbung gesnippt]
könnte Ihr dem Bilderklau ein Ende setzen.
das ist faktisch falsch. Das Script sorgt lediglich dafür, dass ein gewisser Teil der User auch an der gewollten Stelle nichts sieht. HTTP ist zustands- und verbindungslos, es existiert kein Kontext, den Du befragen könntest.
Und lass bitte Deine billige Werbung.
Cheatah
--
X-Will-Answer-Email: No-
Der Kontext besteht aus der IP-Adresse + Zeit. Warum sieht ein
gewisser Teil nichts?ICH VERSTEHE DEINE AUFREGUNG NICHT. WARUM SOLL DIESER BEITRAG
WERBUNG SEIN? WOFÜR DEN...-
Halihallo Robert
Der Kontext besteht aus der IP-Adresse + Zeit. Warum sieht ein
gewisser Teil nichts?Weil die IP keineswegs eineindeutig ist und mit jedem Zugriff ändern kann.
Viele Grüsse
Philipp
-
Da (z.B. AOL) die IP bei jedem Bilddownload ändert, nehme ich auch
nur die ersten 2 Zahlen (A.B.*.*) der IP (siehe Quellcode!!!).
Außerdem unterdrückt AOL den USER_AGENT, weshalb dieser auch nicht
verwendet wird.Bisher klappt die Anzeige der Bilder bei allen großen deutschen
Providern.-
Halihallo Robert
Da (z.B. AOL) die IP bei jedem Bilddownload ändert, nehme ich auch
nur die ersten 2 Zahlen (A.B.*.*) der IP (siehe Quellcode!!!).
Außerdem unterdrückt AOL den USER_AGENT, weshalb dieser auch nicht
verwendet wird.Bisher klappt die Anzeige der Bilder bei allen großen deutschen
Providern.Ich zittiere Cheatah:
"das ist faktisch falsch. Das Script sorgt lediglich dafür, dass ein gewisser Teil der User auch an der gewollten Stelle nichts sieht. HTTP ist zustands- und verbindungslos, es existiert kein Kontext, den Du befragen könntest."Er hat nunmal recht. Soviel oder sowenig du auch programmierst. Mag sein, dass es _meistens_ funktioniert. Aber es ist nunmal _nie_ 100% sicher, egal was du machst. Cheatah ist der Realist, du der Optimist. Beides hat was Gutes, basta ;)
Viele Grüsse
Philipp
-
Da (z.B. AOL) die IP bei jedem Bilddownload ändert, nehme ich auch
nur die ersten 2 Zahlen (A.B.*.*) der IP (siehe Quellcode!!!).
Außerdem unterdrückt AOL den USER_AGENT, weshalb dieser auch nicht
verwendet wird.Aber DU verwendest z.B. den Referer wenn ich das richtig gesehen habe, der ist noch weniger sicher als der User_agent!
Bisher klappt die Anzeige der Bilder bei allen großen deutschen
Providern.Mit 3 von 2500(ungefähr ;-)) möglichen Kombinationsmöglichkeiten.
Grüße
Andreas
-
-
-
-
-
Halihallo Robert
oftmals "klauen" Homepagebetreiber Bilder durch direktes Einbinden.
Dies verursacht unnötigen Trafic auf der eigenen Seite. Mit diesem
Skriptsiehe http://webdienst.webdienst.de/bildklau/
könnte Ihr dem Bilderklau ein Ende setzen.
erstens: Das nenne ich SPAM!
zweitens: Durch das Abblocken vereitelst du zwar das Klauen, jedoch erhöhst die Performancebedürfnisse auf deiner Seite wehement (PHP).
drittens: Welcher Dummy verknüpft die Images direkt? - Dürften eher weniger sein => wegen denen lohnt sich a) der Aufwand b) die erhöhte Performanceanforderungen durch php nicht.Viele Grüsse
Philipp
-
Wieso Spam?
Weil ich für eine Antwort auf eine ähnliche Frage einen eigenen
Beitrag schreibe? Lächerlich...1.) Ich zahle bei meinem Webhoster nicht die CPU-Zeit, sondern für den Trafic
2.) Kannst du die Bilder auf deiner Webseite nicht per Skript einbinden (ohne das interne Passwort)
3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
4.) Und das ist es, worum es geht!
5.) Noch Fragen?-
Halihallo Robert
Wieso Spam?
Weil ich für eine Antwort auf eine ähnliche Frage einen eigenen
Beitrag schreibe? Lächerlich...Nö. Wenn du einen eigenen Beitrag schreibst, dann klebe ihn mit URL an die Signatur, jedoch starte keinen neuen Thread.
Oder schreibe deinen Werbungs-Thread als Frage, ala "Was meint ihr dazu?", vielleicht merken dann einige nicht, dass es Spam ist ;)1.) Ich zahle bei meinem Webhoster nicht die CPU-Zeit, sondern für den Trafic
2.) Kannst du die Bilder auf deiner Webseite nicht per Skript einbinden (ohne das interne Passwort)
3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
4.) Und das ist es, worum es geht!
5.) Noch Fragen?Nö. Aber Antworten: Ich halte es immer noch für unnötige Arbeit. a) hast du daran wohl auch einige Minuten an Programmierarbeit verschwendet und zudem würde es mich nicht besonders anmachen, alle schönen einfachen Bild-URL's durch irgendwelche kodierten Passwörtern und PHP-Scripts zu ändern, nur weil ich 10 BilderKlauMännchen den Klau vereiteln will und somit 500kb weniger Traffic hab. Aber vielleicht hast du ja andere Erfahrungen gemacht...
Viele Grüsse
Philipp
-
Hallo Philip,
es soll hier nicht um 1-2 MB / Monat gehen, sondern um 1-10 Gigabyte.
Ein Freund betreibt eine Fanseite für Autos, mit Bildupload.Er hatte sich über o.g. Größenordnung an "Trafic-Klau" beschwert.
Nach Einbau des Skripte konnte er den Trafic-Klau unterbinden.Du hast nätürlich recht, dass man den Klau mit CPU-Zeit erkaufen muss,
diese jedoch nicht beim Webhoster bezahlt werden muß. Es geht nicht
darum die 30 Bildchen des Layouts zu schützen, sondern große Bilder
einer Gallerie.Robert ;)
-
Halihallo Robert
es soll hier nicht um 1-2 MB / Monat gehen, sondern um 1-10 Gigabyte.
Ein Freund betreibt eine Fanseite für Autos, mit Bildupload.Tja. Anscheinend wirklich andere Erfahrungen gemacht ;)
Er hatte sich über o.g. Größenordnung an "Trafic-Klau" beschwert.
Nach Einbau des Skripte konnte er den Trafic-Klau unterbinden.Du hast nätürlich recht, dass man den Klau mit CPU-Zeit erkaufen muss,
diese jedoch nicht beim Webhoster bezahlt werden muß. Es geht nicht
darum die 30 Bildchen des Layouts zu schützen, sondern große Bilder
einer Gallerie.OK. Auch wenn ich's ungern tue, aber ich geb dir recht ;-) [unter Vorbehalt natürlich :-)]
Aber nochmals zum Anfang: Du frägst dich immer noch, warum wir dein Posting als Spam klassifizieren? - Es liegt an deinem Wortlaut. Du fällst gleich mit der Türe ins Haus. Keine Frage, kein gar nix. Nur eine URL auf ein Projekt von dir. Das ist nunmal Spam! - Die Einführung eines neuen Projektes ist wirklich besser in der Signatur aufgehoben, oder sonst wo, aber es soll _nicht_ das _Zentrum_ des Postings sein. Wenn du uns dazu aufgefordert hättest, einen Kommentar abzugeben, dann wäre es schonmal _etwas_ besser. Aber gar nix; einfach nur URL und kurze Beschreibung...
Viele Grüsse
Philipp
-
Mein Betrag sollte eine Antwort auf das Thema
http://forum.de.selfhtml.org/?t=31083&m=167938
sein :)
-
Halihallo Robert
Mein Betrag sollte eine Antwort auf das Thema
http://forum.de.selfhtml.org/?t=31083&m=167938
sein :)
Und dafür, dass du nicht auch dort postest (wo es demnach hingehört), gibt's grad nochmals eine auf die Mütze!
;)
Viele Grüsse
Philipp
-
-
-
Hi,
es soll hier nicht um 1-2 MB / Monat gehen, sondern um 1-10 Gigabyte.
das ist Anlass zu einer Klage; der Urheber dürfte aufgrund der Datenmenge relativ eindeutig identifizierbar sein. Es ist _nicht_ Anlass zu einer technischen Lösung, weil eine solche nicht existiert.
Nach Einbau des Skripte konnte er den Trafic-Klau unterbinden.
Ja, und normalen Anwendern die Nutzung _seiner_ Site evtl. erheblich erschweren.
Cheatah
--
X-Will-Answer-Email: No-
Es handelt sich um mehrere BEEPWORLD-Seiten, sowie andere im
Ausland gehostete Seiten.-
Hi,
Es handelt sich um mehrere BEEPWORLD-Seiten, sowie andere im
Ausland gehostete Seiten.äh, und was bedeutet das in Bezug auf mein vorheriges Posting, auf das Du ja geantwortet hast?
Cheatah
--
X-Will-Answer-Email: No-
Halihallo Cheatah
Es handelt sich um mehrere BEEPWORLD-Seiten, sowie andere im
Ausland gehostete Seiten.äh, und was bedeutet das in Bezug auf mein vorheriges Posting, auf das Du ja geantwortet hast?
Er wollte dich darum bitten, dass du in seinem Namen Klage erhebst :-))
Viele Grüsse
Philipp
-
Hi,
äh, und was bedeutet das in Bezug auf mein vorheriges Posting, auf das Du ja geantwortet hast?
Er wollte dich darum bitten, dass du in seinem Namen Klage erhebst :-))ach so. Bin ich etwa die Klagemauer? :-)
Cheatah
--
X-Will-Answer-Email: No-
Hallo Cheatah,
ach so. Bin ich etwa die Klagemauer? :-)
Nicht? Verdammt! Dann hab ich dir ja die ganze Zeit umsonst die
Ohren vollgeheult.*scnr*
Gruesse,
CK-
Hi,
ach so. Bin ich etwa die Klagemauer? :-)
Nicht? Verdammt! Dann hab ich dir ja die ganze Zeit umsonst die
Ohren vollgeheult.naja, wenn es schon umsonst war, war es mit etwas Glück wenigstens nicht kostenlos ;-)
Cheatah
--
X-Will-Answer-Email: No-
Hallo Cheatah,
naja, wenn es schon umsonst war, war es mit etwas Glück
wenigstens nicht kostenlos ;-)Das war kein Freundschaftsdienst? Ich bin enttaeuscht.
;))
Gruesse,
CK-
Hi,
naja, wenn es schon umsonst war, war es mit etwas Glück
wenigstens nicht kostenlos ;-)
Das war kein Freundschaftsdienst? Ich bin enttaeuscht.Du bist enttäuscht? Ich bin zerknirscht.
;))
Dito ;-)
Cheatah
--
X-Will-Answer-Email: No-
Hallo Cheatah,
Das war kein Freundschaftsdienst? Ich bin enttaeuscht.
Du bist enttäuscht? Ich bin zerknirscht.
Das will ich auch hoffen! Schaem dich!
;))
Und gleich nochmal.
Gruesse,
CK
-
-
-
-
-
-
-
-
-
-
-
-
Hallo!
1.) Ich zahle bei meinem Webhoster nicht die CPU-Zeit, sondern für den Trafic
indirekt zahlst du natürlich auch die CPU Zeit!
2.) Kannst du die Bilder auf deiner Webseite nicht per Skript einbinden (ohne das interne Passwort)
Ich kann das! Was Du auf einer öffentlichen Webseite zugänglich machst kann ich mir alles holen, nicht nur per Browser, auch per Script.
3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
nö.
4.) Und das ist es, worum es geht!
Zum glück habe ich keine so tollen Bilder die alle Welt klauen will...
5.) Noch Fragen?
nein
Grüße
Andreas-
2.) Kannst du die Bilder auf deiner Webseite nicht per Skript einbinden (ohne das interne Passwort)
Ich kann das! Was Du auf einer öffentlichen Webseite zugänglich machst kann ich mir alles holen, nicht nur per Browser, auch per Script.Dann binde das Bild in Deine Homepage mit einem <IMG-TAG> ein !!!
http://webdienst.webdienst.de/bildklau/versuch_es_doch_zu_klauen/3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
nö.Beweise es...
4.) Und das ist es, worum es geht!
Zum glück habe ich keine so tollen Bilder die alle Welt klauen will...ich auch nicht (evtl. mein Personalausweisbild :-)
Gruß Robert
-
Hi,
Dann binde das Bild in Deine Homepage mit einem <IMG-TAG> ein !!!
Du begreifst immer noch nicht, worum es geht. Ob das Bild nun auf Deinem oder einem anderen Server per <img>-Tag oder sonstwie eingebunden wird ist irrelevant - es hängt vor allem vom User ab, ob er das Bild sehen kann oder nicht! Völlig legitime Request führen zu Deiner Fehlergrafik, und andere, illegitime Requests werden das Original als Ergebnis bekommen. Der Diebstahl des Bildes ist weiterhin möglich, man kann sie - selbstverständlich - ganz normal abspeichern.
Gehe gegen den Trafficklau gerichtlich vor. Eine technische Lösung existiert *nicht*.
3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
nö.
Beweise es...Es ist ein leichtes, ein Script zu schreiben, welches den Referer fälscht.
Cheatah
--
X-Will-Answer-Email: No-
Es ist ein leichtes, ein Script zu schreiben, welches den Referer fälscht.
Deine Besucher (die Clients) müßten den Referer "fälschen".
Wenn Du bei deim Server den Referer "fälschst", dann nützt das
den Besuchern reichlich wenig!Übrigens, wenn Du die Bilder auf deinem Server speicherst, dann
ist doch das Ziel erreicht, den Trafic-Klau zu verhindern...Gruß Robert
-
Moin Moin !
Übrigens, wenn Du die Bilder auf deinem Server speicherst, dann
ist doch das Ziel erreicht, den Trafic-Klau zu verhindern...So!
Jetzt wird's deutlich!
Du hast kein Script gebastelt, das den Bilder-Klau verhindert, sondern eines, das mit fragwürdigen (IP-Auswertung), aber halbwegs funktionierenden Algorithmen den Traffic-Klau eingrenzt.
Schön für dich. Bleib in deinem Thread, Troll!
Alexander
--
<!--#include file="signature.html" -->-
Schön für dich. Bleib in deinem Thread, Troll!
Alexander
Soviel zum Thema konstruktiv...
-
-
Hi,
Es ist ein leichtes, ein Script zu schreiben, welches den Referer fälscht.
Deine Besucher (die Clients) müßten den Referer "fälschen".ich kann die Requests genauso über ein Script jagen, wie Du es kannst. Das Script ist dann der Client.
Übrigens, wenn Du die Bilder auf deinem Server speicherst, dann
ist doch das Ziel erreicht, den Trafic-Klau zu verhindern...In diesem Thread wurde das Wort "Traffic" mittlerweile sicher oft genug richtig geschrieben; ich hatte gehofft, Dich nicht auf den Schreibfehler hinweisen zu müssen. Na gut, tue ich es halt: "Traffic" schreibt man mit Doppel-f.
Das Ziel des Traffic-Klaus wirst Du auf diese Weise nicht erreichen. Erstens erzeugt die Fehlergrafik ebenfalls Traffic, und zweitens, wenn Du als Argument anbringen willst, dass niemand eine Fehlergrafik einbindet, wird dies einen übelgesinnten Menschen - und mit solchen Leuten hast Du es augenscheinlich zu tun - nicht daran hindern, diese und andere Objekte Deines Servers uncachebar auf seinen Seiten einzubinden, ohne dass der Benutzer es sieht; von einem bereits erwähnten Script, welches Dein Konzept vernichtet, ganz abgesehen. Es ist und bleibt so:
Eine technische Lösung existiert *nicht*. Gehe gerichtlich gegen den Verursacher vor, sofern er einer Bitte bzw. Forderung gegenüber unaufgeschlossen ist. Du wirst Recht bekommen.
Cheatah
--
X-Will-Answer-Email: No
-
-
-
Hallo!
Dann binde das Bild in Deine Homepage mit einem <IMG-TAG> ein !!!
http://webdienst.webdienst.de/bildklau/versuch_es_doch_zu_klauen/Anfänger würden das erstmal so machen: http://knet-systems.de/temp/bilderklau.html
Aber das könntest Du verhindern indem Du die Bilder außerhalb des doc-root ablegst. Aber das können gerade die Leute die solche Scritpe haben wollen nicht. Du lönntest es hächstens etwas schwieriger zu erraten machen, halt etwas schwerer zu erratendes als "protect_".Beweise es...
OK, ich muß insofern schon sagen dass die Lösung für den beschrieben Fall gar nicht so schlecht ist wie es sich auf den ersten Blick anhört, denn gerade die Leute die auf diese Weise Traffic klauen werden kein Interesse daran haben udn schon gar nicht die Kenntnisse und techn. Möglichkeiten die Bilder z.B. mal eben mit wget auf den eigenen Server zu speiclen, an die Lösung dachte ich bisher, aber es ging ja um Traffic, wobei Du Dir bewußt sein mußt, wenn denn jemand doch auf die Idee kommt und macht bei jedem Seitenaufruf(um auf dem laufenden zu bleiben) mit wget einen Request auf Deine Scripte dann wird das Deinem Server nicht gefallen!
Die Lösung mit der IP ist wirklich nicht so Dumm. Ich kann jetzt nicht sagen ob Du User dadurch ausperrst, wenn Du die ersten 2 Teile der Ip verwendest, aber ohne die IP geht es nicht. Wenn Du nur das Passwort hättest wäre es ein Kinderspiel.
Schützen kannst Du Die Bilder so kein Stück. Du kannst nur die direkte Velinkung erschweren, und ich denke wenn Du obigen Hinweis beachtest dann wird das auch für die meisten potentiellen Täter reichen. Und wenn Dir dann der erheblich erhöhte Rechen-Aufwand nichst ausmacht, schön.
@Cheatah: Was erwartest Du für eine Erfolgswahrscheinlichkeit wenn Du gegen eine bei einem ausländischen Free-Hoster gehostete Seite vorgehst? Normalerweise würde ich Dir Recht geben, aber hier geht es wohl auf beiden Seiten nicht um Professionelle Websites, sondern irgendwelchen Tripod-Banner-Popup-Galerie-Quatsch.
Grüße
Andreas-
Hallo Andreas,
Du bist der erste, der den Sinn dieses Beitrag's erfasst hat.
Man merkt, im Gegensatz zum manch anderen, dass Du etwas von PHP
verstehst.Beim meinem Beispiel (http://webdienst.webdienst.de/bildklau/versuch_es_doch_zu_klauen/)
ist ja das Passwort und die Erweiterung für die Bilder nicht bekannt.
Daher werdet ihr auch nicht an den Path (es sei denn ihr hackt den
Webhoster) der Bilder kommen.Zum Thema IP:
Mit etwas mehr Aufwand, könnte man sich natürlich den gesamten
Adressraum (von einem WHOIS-Server) für den jeweiligen Provider
holen und per Parameter übergeben. Wie Du (als Einzigster) richtig
erkannt hast, können Besucher von anderen Providern das geklaute
Bild nicht sehen.Gruß Robert
-
Hallo,
Hallo Andreas,
Du bist der erste, der den Sinn dieses Beitrag's erfasst hat.
Man merkt, im Gegensatz zum manch anderen, dass Du etwas von PHP
verstehst.Beim meinem Beispiel (http://webdienst.webdienst.de/bildklau/versuch_es_doch_zu_klauen/)
ist ja das Passwort und die Erweiterung für die Bilder nicht bekannt.
Daher werdet ihr auch nicht an den Path (es sei denn ihr hackt den
Webhoster) der Bilder kommen.Es ist völlig unerheblich, ob das Passwort bekannt ist, da Du mir ja vorher freiwillig eine Zugangskennung schickst:
<img src="http://www.dynamic-web-development.de/cgi-bin/get_protected_image.cgi?uri_p=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fversuch_es_doch_zu_klauen%2Fprotectimage.php&uri_i=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fversuch_es_doch_zu_klauen%2F&nr=0" border="0" alt="">
Gruß Alex
-
Hallo!
Es ist völlig unerheblich, ob das Passwort bekannt ist, da Du mir ja vorher freiwillig eine Zugangskennung schickst:
<img src="http://www.dynamic-web-development.de/cgi-bin/get_protected_image.cgi?uri_p=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fversuch_es_doch_zu_klauen%2Fprotectimage.php&uri_i=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fversuch_es_doch_zu_klauen%2F&nr=0" border="0" alt="">
verstehe ich nicht?!Das Problem/der Trick an der Sache ist die IP! Wenn ich als Dieb möchte, das das Bild im Browser erscheint wenn ein VErsucher auf meien Seite kommt, aber das Bild vom Browser nicht vcon meienm eigenen, sondern von einem fremden Server geholt wird, funktioniert das ganze nur, wenn der Server des Diebs und der Browser des Besuchers dieselben beiden ersten Ziffern in Ihrer IP haben. Wenn das immer so wäre, sagen wir mal Die Server IP ist 1.2.3.4, und die IP aller Clients ist auch 1.2.x.y, dann wäre das alles kein Thema, aber da in Deinem Beispiel Dein Dieb-Server ja mit seiner eigenen IP auf das Script zugreifen _muss_ gilt der so erhaltene Link auf das Bild niemals für einen Client mir anderer IP. Wie gesagt, es steht außer Frage das man serverseitig sehr einfach an die Bilder kommt, aber die Bilder sollen ja direkt auf den Fremdserver verlinkt werden und nicht erst durch ein eigenes Script laufen, bzw. vom eigenben Server geholt werden!
Es geht nur um den Traffic!Grüße
Andreas
-
-
NaNu
<img src="http://www.dynamic-web-development.de/cgi-bin/get_protected_image.cgi?uri_p=http%3A%2F%2Fwww.coupe.de%2Fbilder%2Ftagesgirls%2Fimages%2Fgirldestages.jpg" border="0" alt="">
-
-
Halihallo Andreas
@Cheatah: Was erwartest Du für eine Erfolgswahrscheinlichkeit wenn Du gegen eine bei einem ausländischen Free-Hoster gehostete Seite vorgehst? Normalerweise würde ich Dir Recht geben, aber hier geht es wohl auf beiden Seiten nicht um Professionelle Websites, sondern irgendwelchen Tripod-Banner-Popup-Galerie-Quatsch.
Ich würde sogar noch weiter vorne einhängen: Was kostet der ganze Spass? - Ich musste schon schmerzlich selber feststellen, was die Anwälte so verschlingen (das Wort ist leider sogar richtig gewählt). Geschweige denn der Prozess; klar, die Prozesskosten müssten dann wohl vom Verlierer getragen werden, aber was, wenn nicht?...
Bevor man die Erfolgswahrscheinlichkeiten berechnet, sollte man doch lieber noch vorher ins Portemonaie ('tschuldige, Protmonä, neue Rechts... grr) schauen. Wenn man dann nicht gleich wie nach zwiebelschälen aussieht, kann man immer noch mit Schtreiten anfangen ;)Viele Grüsse
Philipp
-
-
Hallo,
2.) Kannst du die Bilder auf deiner Webseite nicht per Skript einbinden (ohne das interne Passwort)
Ich kann das! Was Du auf einer öffentlichen Webseite zugänglich machst kann ich mir alles holen, nicht nur per Browser, auch per Script.Dann binde das Bild in Deine Homepage mit einem <IMG-TAG> ein !!!
http://webdienst.webdienst.de/bildklau/versuch_es_doch_zu_klauen/Siehe weiter unten.
3.) Daher bist du gezwungen die Bilder auf deinen Webspace zu kopieren
nö.Beweise es...
http://www.dynamic-web-development.de/test/perl/get_protected_images.html zeigt Dir Deine geschützten Bilder auf meiner Seite (oder auch hier :<img src="http://www.dynamic-web-development.de/cgi-bin/get_protected_image.cgi?uri_p=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fprotectimage.php&uri_i=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fdemo.php&nr=0" border="0" alt="">).
Mit der Methode erzeuge ich allerdings "dreimal" Traffic. Einmal Bei Dir beim Ausliefern, einmal bei mir beim Empfang und zum dritten mal bei mir beim ausliefern. ;) Aber bei trafficfreiem Webspace oder bei geringen Besucherzahlen ist das unerheblich.Gruß Alex
-
Hallo!
http://www.dynamic-web-development.de/test/perl/get_protected_images.html zeigt Dir Deine geschützten Bilder auf meiner Seite (oder auch hier :<img src="http://www.dynamic-web-development.de/cgi-bin/get_protected_image.cgi?uri_p=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fprotectimage.php&uri_i=http%3A%2F%2Fwebdienst.webdienst.de%2Fbildklau%2Fdemo.php&nr=0" border="0" alt="">).
Mit der Methode erzeuge ich allerdings "dreimal" Traffic. Einmal Bei Dir beim Ausliefern, einmal bei mir beim Empfang und zum dritten mal bei mir beim ausliefern. ;) Aber bei trafficfreiem Webspace oder bei geringen Besucherzahlen ist das unerheblich.
So ist das natürlich einfach, aber darum geht es gar nicht! Es geht darum das Leute einfach Bilder auf fremden Seiten Verlinken und dadurch hohe Traffic-Kosten bei demjenigen verursachen. So wie Du das machst hat ja der "bilderdieb" doppelt so viel Traffic als wenn er die Bilder direkt auf seinen Server spielt, also warum sollte er das machen?
Die Lösung von Robert erschwert es genau diesen Leuten die Traffic(es geht hier weniger um die Bilder selbst!!) anderer Leute klauen, denn so einfach läßt sich das wirklich nicht umgehen, wenn die Bilder nicht so ohne weiteres im doc-root zugänglich sind(wie es zur Zeit ist).
Für diesen Zweck ist das Script IMHO ganz OK! Ich wüßte jetzt nicht wie ich ohne weiteres an die Bilder kommen sollte, ohne die über meinen Server zu leiten. Dazu müßte schon der Browser was unternehmen, aber das wird wohl kaum so jemand von seinen Besuchern erwarten, zumal die Bilder auch so frei zugänglich sind, er will es - ganz im Gegenteil - ja verheimlichen das das nicht seine Bilder sind!
Ich selbst brauche sowas bestimmt nicht, aber es gibt vielleicht Leute denen das was nützen könnte.Viele Grüße
Andreas-
In diesem Sinne... schönen Abend noch
Letzte Anmerkung:
Die Frage ist, was machst Ihr, wenn ich die Parameter nicht so
offensichtlich benenne und Dir auch das Verfahren zum Schutz
(Timeout, IP-Bestandteile, UserAgent oder auch nicht etc) nicht
verrate? Bei offenem Quellcode findet man natürlich leichter eine
Lösung.Aber die Diskussion hatte auch sein gutes, denn nun kenne ich
die Methode, wie man den Schutz umgehen kann.
Eine mögliche Gegenmaßnahme lautet: IP-Adresse, die ein Bild mehr als
20 mal / Tag anfordern zu sperren (außer bei Proxies). Oder
gegen die Webmaster juristisch vorgehen.Gruß Robert
-
Hallo!
Die Frage ist, was machst Ihr, wenn ich die Parameter nicht so
offensichtlich benenne und Dir auch das Verfahren zum Schutz
(Timeout, IP-Bestandteile, UserAgent oder auch nicht etc) nicht
verrate? Bei offenem Quellcode findet man natürlich leichter eine
Lösung.Ok, aber wie es sich anhörte wolltest Du doch das Scipt anderen zur vefügung stellen, also doch offener Quellcode, udn dei meisten "Webmaster" _können_ diese Parameter gar nicht groß verändern, da sie das Script nicht verstehen!
Aber die Diskussion hatte auch sein gutes, denn nun kenne ich
die Methode, wie man den Schutz umgehen kann.welche meinst Du? Meinst Du meine? Das könnte man recht wirkungsvoll verhindern. Wenn Du nicht außerhalb des doc_root kannst, kannst Du auch eine .htaccess in das image-Verzeichnis legen, darin könntest Du alle direkten HTTP-Zugriffe auf die Bilder verhindern.
Eine mögliche Gegenmaßnahme lautet: IP-Adresse, die ein Bild mehr als
20 mal / Tag anfordern zu sperren (außer bei Proxies).kennst Du alle Proxies?
Oder
gegen die Webmaster juristisch vorgehen.Das wäre sowieso die erste Variante. Wenn hier wirklich kosten entstanden sind, und derjenige mit Aussicht auf Erfolg verurteilbar ist, dann mach das so!
Grüße
Andreas
-
-
Hallo,
[...]
So ist das natürlich einfach, aber darum geht es gar nicht! Es geht darum das Leute einfach Bilder auf fremden Seiten Verlinken und dadurch hohe Traffic-Kosten bei demjenigen verursachen. So wie Du das machst hat ja der "bilderdieb" doppelt so viel Traffic als wenn er die Bilder direkt auf seinen Server spielt, also warum sollte er das machen?
Um z.B. Webspace zu sparen. Wenn man 50 MB Webspace und 5 GB Traffic incl. hat, dann kann man abschätzen, womit man besser fährt. Allerdings darf dann die Seite nicht so oft besucht sein ;) (man kann ja wenigstens Suchmaschinen und Downloader per Redirect umleiten :)
Die Lösung von Robert erschwert es genau diesen Leuten die Traffic(es geht hier weniger um die Bilder selbst!!) anderer Leute klauen, denn so einfach läßt sich das wirklich nicht umgehen, wenn die Bilder nicht so ohne weiteres im doc-root zugänglich sind(wie es zur Zeit ist).
Unter dieser "Zielgruppe" befinden sich imho auch solche User, die hinter einem DynDNS-Service über eine DSL-Flatrate einene eigenen Server betreiben. Denen ist der erzeugt Traffic letztendlich egal, außer daß er auf die Bandbreite geht.
Für diesen Zweck ist das Script IMHO ganz OK! Ich wüßte jetzt nicht wie ich ohne weiteres an die Bilder kommen sollte, ohne die über meinen Server zu leiten. Dazu müßte schon der Browser was unternehmen, aber das wird wohl kaum so jemand von seinen Besuchern erwarten, zumal die Bilder auch so frei zugänglich sind, er will es - ganz im Gegenteil - ja verheimlichen das das nicht seine Bilder sind!
Das ist auch letztendlich unerheblich. Durch das protect-Skript werden nämlich die Bilderklauer, welche die Bilder intensiv nutzen (evtl auf eigenen kommerziellen Seiten; obwohl ich nicht glaube, das diese direkt verlinken würden) nur vom schönen sauberen Platz vertrieben. Das ist so wie bei der Vertreibung von Obdachlosen, Drogenabhängigen und Prostituierten aus den Innenstädten. Aus den Augen aus dem Sinn. Es wird nur die Tat verlagert, aber nicht verhindert. Und gerade Betreiber großer Bildergalerien sollten imho eher ein Interesse daran haben, die Tat zu verhindern, als mit Kanonen auf Spatzen zu schießen. ;)
Ich würde es bei einem Referer-Check durch den Server belassen und per Rewrite-Rule gegebenenfalls auf _kein_ Bild umleiten. Den Traffic hat der Nutzer nämlich weiterhin, weil er ja ein anderes Bild schickt, was den BEEPWORLD-User nicht mal sonderlich stört, oder er es gar nicht merkt weil die Homepage vielleicht bereits verwaist ist.
Das mit der IP, den Verschlüsselungen und dem Timeout sind in dem Fall imho nur Ballaststoffe. Eine Sessionfunktion ist übrigens schon in PHP eingebaut. ;)Gruß Alex
-
Ich würde es bei einem Referer-Check durch den Server belassen und per Rewrite-Rule gegebenenfalls auf _kein_ Bild umleiten.
Leider setzt der IE 6.x keinen REFERER mehr.
Den Traffic hat der Nutzer nämlich weiterhin, weil er ja ein anderes Bild schickt,
Mein Bekannter (der mit der Galerieseite) schickt auch kein Bild,
sondern ein header("Location: nirwana.irgendwo.hin");exit(0);Das mit der IP, den Verschlüsselungen und dem Timeout sind in dem Fall imho nur Ballaststoffe. Eine Sessionfunktion ist übrigens schon in PHP eingebaut. ;)
Das ist allgemein bekannt.
Robert
-
Hallo,
Ich würde es bei einem Referer-Check durch den Server belassen und per Rewrite-Rule gegebenenfalls auf _kein_ Bild umleiten.
Leider setzt der IE 6.x keinen REFERER mehr.Hmmm, verloren. :)
Den Traffic hat der Nutzer nämlich weiterhin, weil er ja ein anderes Bild schickt,
Mein Bekannter (der mit der Galerieseite) schickt auch kein Bild,
sondern ein header("Location: nirwana.irgendwo.hin");exit(0);Das erzeugt natürlich auch noch zusätzlichen Traffic, weil der Browser jetzt erstmal einen Request an den DNS-Server des Userproviders schickt, bis er von der Nichtexistenz der Domain überzeugt wurde (so ungefähr jedenfalls).
Besser wäre es imho gar keine Umleitung, sondern eine leere Seite mit Status: 401 zu senden:<?php
header('Status: 401');
?>Dann kommt evtl. eine Warnmeldung, aber es wird kein weiterer, unnötiger Traffic erzeugt.
Das mit der IP, den Verschlüsselungen und dem Timeout sind in dem Fall imho nur Ballaststoffe. Eine Sessionfunktion ist übrigens schon in PHP eingebaut. ;)
Das ist allgemein bekannt.
Dann nutze sie. :) imho kann man Deinen Verschlüsselungsalgorithmus knacken, wenn man das Passwort errät. SessionIDs können bestenfalls nicht geraten werden, weil sie eine hinreichend zufällige Komponente enthalten.
Eine SessionID nach Deinem Muster erhalte ich aus der Zeit, dem Passwort und meiner IP. Zeit und IP sind mir - wie Dir - bekannt. Das Passwort kann ich "raten" und der MD5-Algorithmus steht mir zur Verfügung. Alles steht und fällt also mit dem Passwort.Die Verwendung einer Session hat also imho eindeutig Vorteile gegenüber Deinem verfahren. Zur Verifikation müssen keine Daten übergeben werden, da die gültige SessionID serverseitig gespeichert wird. Alle nötigen Funktionen sind schon in PHP enthalten und es kommt keine konstante Komponente (Passwort) bei der Generierung der ID ins Spiel. Zudem kann auch zwischen zwei Zugriffen die IP sogar in den ersten beiden Stellen ruhig wechseln, ohne das der User abgelehnt wird.
Ungefähr so (ungetestet):demo.php
<?php
session_start();
?>
<title>Bildausgabe</title>
<img src="image.php?src=bild.jpg&<%= SID; %>">protect.php
<?php
$imgtypes = array('','gif','jpeg','png');
$sid = $_REQUEST['PHPSESSID'];
session_start();
if ( $sid != session_id() ) {
echo "Status: 401";
die( "Forbidden for ". $_SERVER['REMOTE_HOST'] );
}
else {
$image = preg_replace("/[^\w.-]/", "", $_REQUEST['src']);
$size = getimagesize($image);
// ab PHP4.3 geht auch: "Content-Type: {$size['mime']}"
header("Content-Type: " . $imgtypes[$size[2]]);
readfile($image);
}
?>Imho ist das einfacher. :)
Gruß Alex
-
Hallo,
Das erzeugt natürlich auch noch zusätzlichen Traffic, weil der Browser jetzt erstmal einen Request an den DNS-Server des Userproviders schickt, bis er von der Nichtexistenz der Domain überzeugt wurde (so ungefähr jedenfalls).
Besser wäre es imho gar keine Umleitung, sondern eine leere Seite mit Status: 401 zu senden:<?php
header('Status: 401');
?>Uups, ich meinten natürlich 403. :)
Gruß Alex
-
demo.php
<?php
session_start();Nach meinen Informationen nutzt die eingebaute Session-Funktion
das Dateisystem. Leider kann unter Windows aber der letzte
Zugriff auf die (sessionid)Datei nicht ermittelt werden.Die Frage ist, was nun performanter ist md5()-Funktionsaufrufe oder
Zugriffe auf Dateien.Gruß Robert
-
-
-
-
-
-
-
-
-
-
Moin!
oftmals "klauen" Homepagebetreiber Bilder durch direktes Einbinden.
Dies verursacht unnötigen Trafic auf der eigenen Seite. Mit diesem
Skriptsiehe http://webdienst.webdienst.de/bildklau/
könnte Ihr dem Bilderklau ein Ende setzen.
Die Lösung ist aufwendig, kompliziert, fehlerträchtig, von PHP abhängig, performancefressend und für PNG-Bilder noch nicht geeignet.
Da empfehle ich doch viel lieber die Lösung mit URL-Rewriting, die schon fix und fertig im RewriteGuide unter http://httpd.apache.org/docs/misc/rewriteguide.html steht unter "Blocked Inline Images" (ziemlich weit unten). Allerdings reicht schon der erste der beiden Blöcke zur Verhinderung des Zugriffs aus. Man sollte vielleicht noch JPG und PNG ergänzen (gleicher Block, nur andere Dateiendung), wenn diese Bilder das Problem sind.
Vorteil: Der Server antwortet mit einem "403 Forbidden"-Statuscode, sollte ein Referrer, der nicht zur eigenen Site gehört, gesendet werden. Das spart Traffic, weil's kurz ist, und die meisten User senden korrekte Referrer - also ideal, um Traffic durch extern verlinkte Bilder zu senken.
Und in der Tat: Wenn man sowas bemerkt (und ein Bilderklau ist nun einmal eine Urheberrechtsverletzung, egal ob von extern verlinkt oder auf den eigenen Server kopiert), sollte man seinen Anwalt einschalten, wenn freundliche Mails nicht fruchten. Vor allem der Schaden durch Traffic sollte eigentlich jeden Richter überzeugen, dass es sich um keine Bagatelle handelt.
- Sven Rautenberg
--
Diese Signatur gilt nur am Freitag.-
Vorteil: Der Server antwortet mit einem "403 Forbidden"-Statuscode, sollte ein Referrer, der nicht zur eigenen Site gehört,
Wie wird das technisch umgesetzt?
a) muß die IP vor dem Bild eine HTM/PHP-Seite aufrufen
b) der Browser einen REFERER sendenDenn ...
a) funtioniert nicht bei z.B. AOL (ständig andere IPs)
b) funktioniert nicht bei z.B. IE 6.x (kein REFERER)-
Hallo!
Wie wird das technisch umgesetzt?
das steht doch unter dem Link?!
a) muß die IP vor dem Bild eine HTM/PHP-Seite aufrufen
wieso sollte sie? Wie da steht geht es nur um den Referer.
b) der Browser einen REFERER senden
ja
Denn ...
a) funtioniert nicht bei z.B. AOL (ständig andere IPs)Das Problem hast Du bei Deiner Lösung, denn zumindest bei T-Online ist es so, dass die IPs auch an 1. udn 2. Stelle anders sein können, wobei das bei T-Online egal ist, abeer ich vermute dass es bei AOL & Co genauso sein wird!
b) funktioniert nicht bei z.B. IE 6.x (kein REFERER)
Das wäre mir neu, wenn das so ist sieht es tatsächlich schlecht aus, denn der IE6 ist schon sehr verbreitet.
Grüße
Andreas-
Hallo!
b) funktioniert nicht bei z.B. IE 6.x (kein REFERER)
Das wäre mir neu, wenn das so ist sieht es tatsächlich schlecht aus, denn der IE6 ist schon sehr verbreitet.Leider habe ich keinen IE 6 zum testen, habe aber gerade mal in meinen Logs nachgeguckt, und da steht schwarz auf weiß das der IE6 einen Referer sendet! Warum auch nicht?
Also wäre diese Lösung das beste! Tja, das hat man davon wenn man die Apache doku schonmal etwas genauer gelesen hat ;-)
Aber mal was anders, in welchen Fällen wird eigentlich ein Referer gesendet und wann nicht? Irgendwie versteh ich das noch nicht ganz.
Grüße
AndreasPS: Hier macht man sich aber genauso von Apache abhängig wie sonst von PHP, nur so nebenbei ;-)
-
Moin!
Leider habe ich keinen IE 6 zum testen, habe aber gerade mal in meinen Logs nachgeguckt, und da steht schwarz auf weiß das der IE6 einen Referer sendet! Warum auch nicht?
Eben. Wäre mir auch neu, wenn der IE6 standardmäßig keinen Referrer senden würde. Außerdem ist er noch nicht zu 100% verbreitet - die Lösung würde also zumindest bei 70% der Fremdverlinker zuschlagen, würde er keinen Referrer senden. :)
Aber mal was anders, in welchen Fällen wird eigentlich ein Referer gesendet und wann nicht? Irgendwie versteh ich das noch nicht ganz.
Referrer wird keiner gesendet, wenn es keinen gibt: Eingabe der URL über Tastatur zum Beispiel. Allerdings gibt es bei Bildern eigentlich immer einen Referrer, weil sie in der Regel in einer HTML-Seite eingebunden sind. Es wird als Referrer also immer die HTML-Seite gesendet, die vorher (ob mit oder ohne Referrer spielt gar keine Rolle) aufgerufen wurde.
PS: Hier macht man sich aber genauso von Apache abhängig wie sonst von PHP, nur so nebenbei ;-)
Es gibt ein URL-Rewriting-Tool auch für den IIS. ;-))
- Sven Rautenberg
--
Diese Signatur gilt nur am Freitag.-
Hi Sven!
Referrer wird keiner gesendet, wenn es keinen gibt: Eingabe der URL über Tastatur zum Beispiel. Allerdings gibt es bei Bildern eigentlich immer einen Referrer, weil sie in der Regel in einer HTML-Seite eingebunden sind. Es wird als Referrer also immer die HTML-Seite gesendet, die vorher (ob mit oder ohne Referrer spielt gar keine Rolle) aufgerufen wurde.
Aber enn ich mir eben kurz eine Seit mit folgendem Inhalt speichere(auf meinem PC):
<a href="http://www.schroepl.net/cgi-bin/http_trace.pl">http://www.schroepl.net/cgi-bin/http_trace.pl</a>
Dann rufe ich die Datei auf und klicke auf den Link. Wieso wird dann der Referer nicht angezeigt? Weil mein PC kein HTTP-Server ist oder wieso?
Es gibt ein URL-Rewriting-Tool auch für den IIS. ;-))
Aber da gibts ja meist auch ASP oder "sogar" auch PHP ;-)))
Grüße
Andreas-
<a href="http://www.schroepl.net/cgi-bin/http_trace.pl">http://www.schroepl.net/cgi-bin/http_trace.pl</a>
Den Referer-Wert setzt der Browser
- lokale Festplatte = lokales Netz
- www.ABC.de = Internet
Ich vermute aus Sicherheitsgründen wird der Referer-Wert nicht
zwischen beiden "Zonen" transportiert.
Gruß Robert
-
-
Wenn T-Online bei jedem Zugriff die IP total ändert, dann
gibt es auch keine Konstante zur Prüfung mehr und man kann
sich den ganzen Aufwand sparen und nur auf den Referer setzen.Eine weitere Möglichkeit besteht aus Java/Flash, welches
die Bilder nachläd. Aber auch diese kann man "decompilen".Die Frage ist immer, gegen wen man was schützen will bzw
welchen Aufwand die Gegenseite in Kauf nimmt.Ich selbst nutze nicht den IE 6.0, nur ist mir in den
Log-Files aufgefallen, dass zu diesem Browser bei den Bildern
eben dieser fehlt. Daher ging ich davon aus, dass IE 6.0 den
Wert unterdrückt.Aus Gründen der Sicherheit wäre die Idee gar nicht mal schlecht,
da so keine evtl gültigen SessionIDs (man beachte kein ') an
fremde Webserver übertragen werden.Gruß Robert
---
Ich hatte es fast nicht mehr für möglich gehalten, dass hiet auch
auf sachlicher Ebene diskutiert werden kann.-
Wenn T-Online bei jedem Zugriff die IP total ändert, dann
gibt es auch keine Konstante zur Prüfung mehr und man kann
sich den ganzen Aufwand sparen und nur auf den Referer setzen.Das habe ich nicht gesagt! ich wollte damit nur klarmachen das Deine Prüfung der ersten beiden Ziffern der IP nicht gut ist, und ohne IP kannst Du Dein Script leider vergessen.
Die IP bei T-ONline bleibt solange man angewählt ist gleich. Der Vorschlag von Sven ist _die_ Lösung für Dein Problem, denn man bekommt das Bild nur angezeigt, wenn man keinen oder einen Referer von Deiner Seite sendet. Wenn 70% der User also kein Bild sehen würden, dann hat das Klauen keinen Sinn mehr.Eine weitere Möglichkeit besteht aus Java/Flash, welches
die Bilder nachläd. Aber auch diese kann man "decompilen".Bloß nicht!
Die Frage ist immer, gegen wen man was schützen will bzw
welchen Aufwand die Gegenseite in Kauf nimmt.Die Gegenseit kann sich auf den Kopf stellen, den Referer der Beowser können sie nicht beeinflussen.
Ich selbst nutze nicht den IE 6.0, nur ist mir in den
Log-Files aufgefallen, dass zu diesem Browser bei den Bildern
eben dieser fehlt. Daher ging ich davon aus, dass IE 6.0 den
Wert unterdrückt.Ich weiß es auch nicht.
Aus Gründen der Sicherheit wäre die Idee gar nicht mal schlecht,
da so keine evtl gültigen SessionIDs (man beachte kein ') an
fremde Webserver übertragen werden.das auch!
Ich hatte es fast nicht mehr für möglich gehalten, dass hiet auch
auf sachlicher Ebene diskutiert werden kann.;-) So ist das nunmal hier, aber woanders hättest Du eine Lobeshymne bekommen und nichts dazu gelernt!
Grüße
Andreas
-
-
-
-
-
-
Hallo!
Da empfehle ich doch viel lieber die Lösung mit URL-Rewriting, die schon fix und fertig im RewriteGuide unter http://httpd.apache.org/docs/misc/rewriteguide.html steht unter "Blocked Inline Images" (ziemlich weit unten). Allerdings reicht schon der erste der beiden Blöcke zur Verhinderung des Zugriffs aus.
Habe das aus eigenem Interesse mal probiert - aber es klappt nicht.
Meine .htaccess:RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.knet-systems.de/temp/.*$ [NC]
RewriteRule .*.gif$ - [F]dann habe ich in das Verzeichnis /temp/images die Datei bild3.gif gelegt.
Wenn ich dann eine html-Datei mit folgendem Inhalt hhochlade:
<img src="http://www.knet-systems.de/temp/images/bild3.gif">
dann wird das Bild angezeigt. Wenn ich diese Datei auf einem anderen Server hochlade - dann wird das Bild _auch_ angezeigt - wieso?
Getestet habe ich mit Mozilla 1.1 und IE 5.0
Besser testen kann man das auch mit:
http://www.schroepl.net/cgi-bin/http_trace.pl?url=http%3A%2F%2Fwww.knet-systems.de%2Ftemp%2Fimages%2Fbild3.gif&method=HEAD&version=HTTP%2F1.0obige .htaccess liegt im Verzeichnis /temp
Viele Grüße
Andreas
-
