Haben manche SEOs eigentl. nur -zensiert- im Kopf?

Beitrag von **AnjaK** » 12.02.2005, 17:52

das automatisierte Script schützt dich aber nicht vor spammern, denn vielen machen das auch von Hand wenn es sich beim PR lohnt!
Und ein gescheiter spammer macht das unauffällig und dezent so, dass dus erst merkst, wenn er von deinem PR schon längst profitiert hat, denn wenn du einen hohen PR hast, wird deine Seite von G schneller gespidert als du den Link rausnehmen kannst

von **Anzeige von ABAKUS** »

Hochwertiger Linkaufbau bei ABAKUS:

Google-konformer Linkaufbau
nachhaltiges Ranking
Linkbuilding Angebote zu fairen Preisen
internationale Backlinks

Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

Beitrag von **Airport1** » 12.02.2005, 19:17

Beim "Script durch Script aufrufen" war die Intention nicht vor Link Spammern zu schuetzen, sondern den automatisierten Aufruf von Online Tools zu unterbinden.

Wir kennen das ja, man konnte z.B. frueher uebers Web mit ICQ Teilnehmern ueber eine kleine Eingabemaske chatten (ich meine jetzt nicht ICQ2GO).

Nachdem dies dann automatisiert missbraucht wurde, wurde ein "Um uns vor automatisierten Aufrufen zu schuetzen... bla... Bitte geben Sie den Code aus dem Bild ein um sich als menschliches Wesen zu outen... blubb" eingebaut.

Das kann man immer brauchen, und es wird immer mehr der Trend werden, da der Missbrauch stetig zunimmt, egal ob Kommentar-Spam bei Blogs, Gaestebuch-Spam oder eben automatisierter Missbrauch von Online Tools.

Beitrag von **AnjaK** » 12.02.2005, 21:42

Ach so, ok, jetzt versteh ich

von **Anzeige von ABAKUS** »

Beitrag von **Graccem** » 13.02.2005, 11:25

$inhalt=implode(file($PHP_SELF));
preg_replace("/<a href.*</a>/","", $inhalt);
$inhalt=str_replace("a#href","a href",$inhalt);
echo $inhalt;

Au backe. Ihr lasst HTML als Eingabe zu? Hoffentlich parsed ihr dann die gefährlichen Stellen(<script>) raus.
Und wenn die Spammer das rausbekommen, hast ihr das selbe Problem wieder.

Die Links die dort gesetzt werden sind in der Regel "interne", also zu weiteren Themen innerhalb des WIKIs. Ich und andere nutzen das WIKI teilweise fuer Gedanken-Erguesse/Ideenfaenger, wie auch als kleiner Bugtracker, und manchmal als eine Art "oeffentlicher Chat". Links auf externe Seiten sind selten, und wenn dann kommen sie meist von diesen Drecks-Tools. Es reicht wohl nicht den Google Index mit

Schon mal bei PHP von file_exists gehört?
https://de.php.net/manual/de/function.file-exists.php
Damit kannst du ermitteln, ob eine Datei auf dem Server existiert (interner Link). Bei externen Links wird immer false zurück gegeben. Vielleicht solltest du sowas in der Art einbauen.
Wenn du deinen Inhalt aus der DB ausliest, musst du selbstverständlich sowas selber implementieren, aber das sollte kein Problem darstellen. Dafür müsstest du eine neue Datei/Funktion anlegen, die die DB abfragt und entsprechend true oder false zurück gibt. Und diese Datei/Funktion sprichst du dann einfach an.

Beitrag von **Airport1** » 13.02.2005, 13:46

Das geht aber wieder am eigentlichen Problem vorbei. Es kommt schon vor dass man ab und zu mal SELBER einen externen Link setzt, das soll dann schon gehen, und die Loesung von Anja reicht dann alle mal.

Was jetzt noch fehlt ist ein Script was das "automatisierte Missbrauchen" von Online Tools unterbindet, indem es eine

Bild (zufaellig erzeugt) -Code-Abfrage

abfraegt, was dann hoffentlich nur ein Mensch lesen kann, also z.B. schraeg dargestellte Buchstaben auf wechselndem Hintergrund... ich seh schon, ich muss das Rad neu erfinden, da wohl niemand einen Beispiel-Code hat

Andere Frage: ist die an fuer sich eigentlich nervige Bild-Code-Abfrage derzeit der Weisheit letzter Schluss, oder gibt es DOCH NOCH andere Moeglichkeiten automatisierten Missbrauch zu verhindern?

Beitrag von **ts77** » 13.02.2005, 14:02

du suchst sicher das hier ...
https://pear.php.net/package/Text_CAPTCHA

Beitrag von **AnjaK** » 13.02.2005, 15:10

Das script dafür ist im Prinzip ganz einfach:

header ("Content-type: image/png");
$im = @ImageCreate (50, 100);
$background_color = ImageColorAllocate ($im, 255, 255, 255);
$text_color = ImageColorAllocate ($im, 255, 0, 0);

srand ((double)microtime()*1000000);
$code = rand(10000,99999);

ImageString ($im, 1, 5, 5, $code, $text_color);
ImagePNG ($im);

Dieses Schnippel erzeugt ein weißes Bild mit roter Schrift und einer Zahl zwischen 10000 und 999999, die du anschließend mitpostest und quervergleichst. Das ist auch schon alles.

Beitrag von **ff-webdesigner** » 13.02.2005, 15:48

au ja...das mit dem fertigen code für "bitte tippen sie die zahlen ab": schon lange gesucht, ausser mods für phpbb nix solitäres gefunden. wenn jemand was weiss: pm me!

thanks!

Beitrag von **ts77** » 13.02.2005, 15:57

> die du anschließend mitpostest und quervergleichst.

ähm ... und das mitgepostete kann ein Script gar nicht auslesen, neeeeein

.
Ich würd es nur kodiert mitschicken, irgndein Hash-Codec oder so drüber. Besser noch gar nicht mitschicken und nur in der Session halten oder sowas.

Beitrag von **AnjaK** » 13.02.2005, 21:06

@TS77

Nein, wenn du es richtig machst im "Empfangsscript" kann das Script es zwar auslesen so viel es will, aber nicht nutzen, wenn du natürlich den Datenstrom 1:1 verarbeitest dann bist du selber schuld...

Zur Not halt einfach geringfügig verschlüsseln mit einem einfachen Code und fertig ist die Marie.

z.b. würde $code*=12345 und auf der Zielseite $code=$_request["code"]/12345 schon ausreichen um sich vor Atomatismen zu schützen.

Beitrag von **Graccem** » 13.02.2005, 23:41

AnjaK hat geschrieben:@TS77

Nein, wenn du es richtig machst im "Empfangsscript" kann das Script es zwar auslesen so viel es will, aber nicht nutzen, wenn du natürlich den Datenstrom 1:1 verarbeitest dann bist du selber schuld...

Zur Not halt einfach geringfügig verschlüsseln mit einem einfachen Code und fertig ist die Marie.

z.b. würde $code*=12345 und auf der Zielseite $code=$_request["code"]/12345 schon ausreichen um sich vor Atomatismen zu schützen.

Öhm, das ist aber verdammt schwer zu erraten... Wenn du die Zahl per POST rüberschickst und nur einen Faktor einbaust, kann das jeder herausbekommen. Insofern kannst du dir das dann auch sparen. Sinnvoller wäre, wenn du die Zahl in der DB als Vergleichswert speicherst und nur diesen mit der POST-Variablen vergleichst.

Beitrag von **AnjaK** » 14.02.2005, 00:14

@Graccem

Das war ja auch nur ein ganz billiges Beispiel. Es gibt ganz simple aber extrem effektive Algos, mit denen man verschlüsseln kann, die garantiert niemand knacken kann, ohne Supercomputer. Wenn ich mit dem Schlüssel:
"Hans hat in die Hose geschissen" x Datum x Schuhgröße deiner Frau x "Thomas ist der beste Seifenprophet den die Unterwelt je geschmeckt hat"
... da wil ich sehn, wie du DEN Code knackst

)

Beitrag von **AnjaK** » 14.02.2005, 00:16

Nachtrag:

Auf der ganz sicheren Seite ist man, wenn man:

a) Den Code verschlüsselt
b) die Variable nicht aus dem Cache liest sondern aus dem $_request
c) den Referer mit einbezieht

Der Aufwand, das zu umgehn ist so extrem, dass das sicher kein Spammer machen wird, es sei denn die Seite hat PR10

Beitrag von **LinkPop** » 14.02.2005, 04:35

Beitrag von **Graccem** » 14.02.2005, 08:10

AnjaK hat geschrieben:Nachtrag:

Auf der ganz sicheren Seite ist man, wenn man:

a) Den Code verschlüsselt

Nicht, wenn du die falsche Verschlüsselung wählst. Wenn, dann nur irreversible Verfahren.

b) die Variable nicht aus dem Cache liest sondern aus dem $_request

$_REQUEST sollte man aber auch nicht nutzen

https://www.php.net/manual/de/language. ... efined.php

c) den Referer mit einbezieht

Als wäre der Referer nicht fälschbar. Es gibt auch User, die keine Referer-Info übermitteln. Die können dann dein Script nicht nutzen...