IDs schützen
1 
Felix Riesterer
3 1 2
IDs schützen
Hallo,
an die Seite soll eine Aufforderung geschickt werden eine bestimmte Information anzuzeigen. Zb.: /index.php?id=423
Aber um zu verhindern das von aussen der gesamte content maschinell ausgelesen wird, möchte ich die ID vercrypten. Eingehende cyrpts werden wieder entschlüsselt und die enthaltenen ID aufrufen.
Der normale Weg über Session ist nicht möglich da die Links im Web verteilt werden sollen (addthis, twitter etc.) und user sich nicht einloggen sollen, sondern nur die Info sehen sollen die hinter der ID steckt.
Ist dafür die crypt-idee der richtige Ansatz oder sollte man es anders machen?
Merci und viele Grüße,
Rob
-
Lieber RobRobson,
Aber um zu verhindern das von aussen der gesamte content maschinell ausgelesen wird,
... solltest Du von einer Veröffentlichung im Internet Abstand nehmen. Ansonsten ist Dein Ansinnen ein Widerspruch in sich selbst.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hi und Danke,
Aber um zu verhindern das von aussen der gesamte content maschinell ausgelesen wird,
... solltest Du von einer Veröffentlichung im Internet Abstand nehmen. Ansonsten ist Dein Ansinnen ein Widerspruch in sich selbst.
-
Warum ist es ein Wiederspruch eine einzelne Information raus geben zu wollen aber damit nicht gleich den Zugiff auf alle restlichen Einträge der Tabelle zu ermöglichen?
-
also sollte man eine authentifizierung (zB. via capcha) zwischenschalten?
Viele Grüße,
Rob-
Hello,
- also sollte man eine authentifizierung (zB. via capcha) zwischenschalten?
Nein, die Wahl eines breit gestreuten Nummernkreises mit schwacher Belegung ist schon der richtige Ansatz. Die Lücken solltest Du aber für die Robots mit Futter füllen; also Zufallscontent auf die Lücken legen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
- also sollte man eine authentifizierung (zB. via capcha) zwischenschalten?
Nein, die Wahl eines breit gestreuten Nummernkreises mit schwacher Belegung ist schon der richtige Ansatz. Die Lücken solltest Du aber für die Robots mit Futter füllen; also Zufallscontent auf die Lücken legen.
Ist den Status 404 nicht zufällig genug?
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hello,
Nein, die Wahl eines breit gestreuten Nummernkreises mit schwacher Belegung ist schon der richtige Ansatz. Die Lücken solltest Du aber für die Robots mit Futter füllen; also Zufallscontent auf die Lücken legen.
Ist den Status 404 nicht zufällig genug?
Nein, wenn er die "bösen Robots" beschäftigen will, muss er ihnen Futter liefern und keine ehrlichen Antworten. Die sollen ja eine Weile damit zu tun haben, den Zufallskontent zu parsen und ggf. auch "nette URLs" darin zu finden...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hall Tom,
Nein, wenn er die "bösen Robots" beschäftigen will, muss er ihnen Futter liefern und keine ehrlichen Antworten. Die sollen ja eine Weile damit zu tun haben, den Zufallskontent zu parsen und ggf. auch "nette URLs" darin zu finden...
Du hast ja lustige Ideen. :) (meine ich absolut positiv)
Naja mal sehen obs eine zukünftige Variante geben die bei nicht existenten Schlüsseln ein AJAX request bei Google oder Twitter macht und nach vorn übergibt. ^^
Viele Grüße,
Rob -
Ist den Status 404 nicht zufällig genug?
Nein, wenn er die "bösen Robots" beschäftigen will, ...Ich dachte eher, er will nicht Bots beschäftigt werden
muss er ihnen Futter liefern und keine ehrlichen Antworten.
nein, er sollte seiner Absicht treu bleiben, statt den neurotischen Vorschlägen anderer zu folgen.
Eine ID, die nicht vorhersagbar ist, ist alles, was er braucht.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hello,
Nein, wenn er die "bösen Robots" beschäftigen will, ...
Ich dachte eher, er will nicht Bots beschäftigt werden
muss er ihnen Futter liefern und keine ehrlichen Antworten.
nein, er sollte seiner Absicht treu bleiben, statt den neurotischen Vorschlägen anderer zu folgen.
*bah* bist Du humorlos. Nun gönn doch den Bots auch ein bisschen Spaß.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
Du suchst praktisch IDs die nicht fortlaufend sind.
Das heißt bilde dir eine Zufallszahl oder eine zufällige Zeichenkette, prüfe ob die schon mal verwendet wurde und speicher die zum Content, damit der richtige Content zur Zahl gefunden werden kann.
Je länger die Zahlen, umso schwerer sind existierende Zahlen zu erraten.-
Hallo Encoder
Du suchst praktisch IDs die nicht fortlaufend sind.
Das heißt bilde dir eine Zufallszahl oder eine zufällige Zeichenkette, prüfe ob die schon mal verwendet wurde und speicher die zum Content, damit der richtige Content zur Zahl gefunden werden kann.
Je länger die Zahlen, umso schwerer sind existierende Zahlen zu erraten.Gute Idee, an die Überschneidungen beim decrypt-Ergebniss hab ich noch nicht gedacht, zwar sehr gering aber möglich. Und die Aufrufzufälligkeit ist auch abgedeckt.
Danke und viele Grüße,
Rob-
Also im Prinzip brauchst du ja wirklich nur eine Zeichenfolge die zum einen lang genug ist und zum anderen eindeutig.
Wie du die erstellt ist völlig egal. Eine fortlaufende ID wirst du ja trotzdem vergeben? Dann bastel dir einen Hash aus deiner ID oder dem Erstelldatum oder so plus irgendwas zusätzliches damit man den nicht rückverfolgen kann (z.B. id + "slvjernrh") und nimm den als Link.
Wenns den zufälligerweise schon gibt, veränder solange das Anhängsel bis der Wert eindeutig ist.Ich würde da schon vom Aufwand her nichts nehmen das du wieder entschlüsseln musst.
-
-
-
Hello,
wähle nicht den GET-Request, lasse den Besucher erst über Los laufen, lasse ihn dann einen POST-Request absetzen auf einen zeitlich limitierten Zugang zur Ressource, der ihm auf der "Los-Seite" angeboten wird.
Das ist im Prinzip das, was Du willst, läuft ohne Sessions und ein "Collect by Increment" ist nicht möglich.
Das Verfahren wird allerdings keinen Client (Roboter) davon abhalten, die Einstiegsseite genügend oft aufzurufen, um dann die Ressourcenkennungen in der Response zu erhalten.
Allerdings sind ja in jeder Response wieder dieselben Ressourcen hinter neuen Kennungen "versteckt", sodass es dem Robot, sollte er nicht den Kontext ebenfalls auswerten können, bald langweilig werden wird...
Eine gute Methode ist es auchm einen zirkulären Verlauf einzubauen. Jeder Mensch wird den sofort bemerken. Dumme Robots hängen sich dabei gerne auf.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi nochmal :)
wähle nicht den GET-Request, lasse den Besucher erst über Los laufen, lasse ihn dann einen POST-Request absetzen auf einen zeitlich limitierten Zugang zur Ressource, der ihm auf der "Los-Seite" angeboten wird.
Schön und gut, aber einzige Schnittstelle ganz am Anfang ist und bleibt ein link. Was anderes als GET ist da nicht möglich.
Das ist im Prinzip das, was Du willst, läuft ohne Sessions und ein "Collect by Increment" ist nicht möglich.
Zeitlich limitiert wäre ja dann auch wieder sessionbound, was aber an sich nicht schlimm ist. Ich hab nichts gegen Sessions. Nur ist der Einstigspunkt zur Seite eben nur ein Link (von einer anderen Seite) der etwas bestimmtes aus meiner DB holen soll. Dazu kommt das ich drinnen nicht weiß das da daußen noch was rumschwirrt das irgendwann mal auf einen Inhalt zu greifen möchte. Also ich möchte keinen hash ablegen der wiederum ein Zeiger auf eine Id in einer wichtigen Tabelle ist. Ich denke auch das die zufälligen-einmalschlüssel von 'encoder' der beste Kompromiss ATM für mich ist.
Das Verfahren wird allerdings keinen Client (Roboter) davon abhalten, die Einstiegsseite genügend oft aufzurufen, um dann die Ressourcenkennungen in der Response zu erhalten.
Wenn, sagmal 10k oder 100k Datensätze vorliegen und als id ein md5 ähnlichen string hinterlegt ist (varchar 32), sollte die Chance gering sein das ein robot viel sinvolles rausbekommt. Zumal nach einigen versuchen iptables den Hahn abdreht.
Eine gute Methode ist es auchm einen zirkulären Verlauf einzubauen. Jeder Mensch wird den sofort bemerken. Dumme Robots hängen sich dabei gerne auf.
zirkuläre response meinst Du?
Viel Dank in die Nacht hinaus,
Rob
-
-
Mal noch ein anderer Ansatz.
Wie wärs denn mit sprechenden Namen statt IDs? Beim ?id=kochrezepte kommt doch auch keiner auf die Idee, alle Buchstabenkombinationen durchzusuchen, ob es vielleicht noch was anderes gibt.
Kannst du den Inhalten keinen Namen verpassen? Damit hättest du den ganzen Aufwand abgeschafft.