Unerwünschten Aufruf von Request-Dateien verhindern.

K

koli.bri

Hallo Programmierersvolk.

Eine "Sicherheitsfrage":
Da ich zur Zeit an einem Spielsystem arbeite, was recht viel mit HTTP-Requests arbeitet, stellt sich mittlerweile auch folgende Frage: Wie kann ich sicherstellen, dass die URLs, die in den Requests aufgerufen werden, auch nur von meinen JavaScript-Funktionen aufgerufen werden, und nicht von einem Anwender, der ein wengi von der Materie kennt und sich die URL einfach raussucht und von Hand aufruft, um sich einen Spielvorteil zu schaffen...
(Man stelle sich vor, mal so eben 100 Unverwundbarkeitstränke in 10 Sekunden, das selbe mit der Ultimativen Waffe :eek: :D)

Nach meinen Überlegungen gib es zwei Möglichkeiten, das ganze anzugehen:
Einmal die URL so gut wie möglich zu verstecken, verschleiern. Mach ich allein aus Faulheit schon, da ich eine JS-Funktion habe, die mir die URL zusammenbaut.
Ist aber auch nicht gerade das gelbe vom Ei.
Die andere Möglichkeit besteht darin, eine Abfrage zu machen, woher die URL aufgerufen worden ist. Aber wie stelle ich das an?
Hatte schon überlegt, dass ich via JavaScript einen Zufallswert generiere, den dem Request mitgebe, der Schreibt den beim RückgabeText in die erste Zeile, die dann wieder in JS überprüft wird, obs der Wert ist, den ich vohrer generiert habe.
Aber das lässt sich ja auch recht leicht aushebeln.

Ideal wäre also etwas, was auf der Serverseite funktioniert, sowas wie "Welche Datei hat gerade diesen Request gestartet?"
Steht diese Info vielleicht im HTTP-Header? Wenn ja, wie komme ich da dran?

Also, kurz: Wie stelle ich sicher, dass nur meine Scripte Zugriff auf meine Requestdatei haben?

(Und kommt mir nicht mit dem Kram, den die bei phpMyAdmin gebracht haben, auch wenns funktioniert. Aber wie, das rafft ja niemand :D)

gruß
Lukas
 
Die Geschichte mit dem Referer-Header würde auch nichts
bringen, da man diesen ja auch fälschen könnte.

Ohne mich aus dem Fenster lehnen zu wollen: Was du willst,
ist nicht möglich.
 
Lass dir von deinem Server eine verschlüsselte Transaktions-ID geben, deren Antwort-ID du mit einem (geheimen) Key errechnen kannst. Diese schickst Du dann mit... oder mach das ganze mit https
 
Das sollte relativ einfach lösbar sein. Dir richtige Lösung wäre ein Token. Beim Abruf einer Seite wird in alle Verweise dieses Token eingebettet. Dieses Token ist genau für einen Aufruf gültig. Für die Folgeseiten wird jeweils ein neues Token generiert. Da die Verfolgung relativ kompliziert ist, könnte man es mit der normalen Session-Verwaltung kombinieren. Da könnte man in einer Session-Variablen alle gültigen Tokens verwalten.
 
Das sollte relativ einfach lösbar sein. Dir richtige Lösung wäre ein Token. Beim Abruf einer Seite wird in alle Verweise dieses Token eingebettet. Dieses Token ist genau für einen Aufruf gültig. Für die Folgeseiten wird jeweils ein neues Token generiert. Da die Verfolgung relativ kompliziert ist, könnte man es mit der normalen Session-Verwaltung kombinieren. Da könnte man in einer Session-Variablen alle gültigen Tokens verwalten.

Das klingt recht interessant.
Aber wie sähe das in der Realität aus?
Will Dir jetzt nicht einen fertigen Quelltext abquatschen, sondern eher eine Erklärung, wie man das ganze realisieren kann....


Wie ich das verstehe:
Jeder Link in dem Projekt verursacht einen Request (bitte nicht über den Sinn und Unsinn von Http-Requests diskutieren :) ).
Ich würde also beim ersten Laden der gesammten Seite auf PHP-Seite einen Schlüssel, den ich in der Session ablege. Was weiß ich, MD5-Challenge auf aktuellen Timestamp, oder so.

Den Wert leg ich in einer JS-Variable ab, und geb den allen HTTP-Requests als Parameter mit. PHP prüft dann "Ist das der Wert, den ich erzeugt habe", und handelt entpsprechend.
Nachdem alles ganz normal abgelaufen (oder weggehauen :suspect: ) ist, muss ich dann auf der PHP-Seite wieder einen neuen Schlüssel generieren, wohl mit einem zweiten Request, der direkt nachgeschubst wird, und den Zurückgegebenen Schlüssel wieder in der JS-Variablen speichert.

Und dann fängt das ganze wieder von vorne an...


Ist ein guter Ansatz, wär ich so nicht drauf gekommen.
"Verschleiert" man den Schlüssel noch als was anderes (UserID oder so), wär das auf jeden Fall mal was... (womit ich den Open-Source Gedanken freillich vergessen sollte :D )

Oder gibts noch nen anderen Ansatz, der sich nicht durch ein "alert(token)" in der FireFox-Fehlerkonsole aushebeln lässt? :D

mfg
Lukas
 
Meiner Meinung nach brauchst du keine Token und Zeug. Du musst sicherstellen, dass die gesamte Regellogik nicht auf dem Client im JS, sondern nur auf dem Server ausgeführt wird. That's it.

Solange das JS "Tränke erzeugen" kann oder "Waffenschläge" ausführt, kann immer jemand das JS reverse engineeren und bescheißen - ist dann nur eine Frage des Aufwands.
 
Meiner Meinung nach brauchst du keine Token und Zeug. Du musst sicherstellen, dass die gesamte Regellogik nicht auf dem Client im JS, sondern nur auf dem Server ausgeführt wird. That's it.

Solange das JS "Tränke erzeugen" kann oder "Waffenschläge" ausführt, kann immer jemand das JS reverse engineeren und bescheißen - ist dann nur eine Frage des Aufwands.

Was dann bedeuten würde, dass ich komplett auf HTTP-Requests verzichte.
Aber gut, wenn es nicht geht, sollte es zumindest doch erschwert werden können. So dass man denen, die es dann geschafft haben, auch gönnen kann. :)

Denn alles komplett auf den Server zu legen ist bei einigen Sachen nur schwer möglich, bzw, mit vermehrt Aufwand und, was für mich ziemlich wichtig ist, mit enormen Geschwindigkeitseinbußen verbunden (so läuft zum Beispiel der Großteil des Kampfsystems auf dem Clienten, damits halt schneller ist.)

Aber Ihr habt recht. Wenn sich auf HTTP-Ebene nicht nachvollziehen lässt, woher die Datei/URL aufgerufen wird, lässt sich nichts machen... Ist halt so...


mfg
Lukas
 
Zurück
Oben Unten