Authorisierung nach Aufruf aus Javascript prüfen

[Ralf]

Hallo!

Ich habe eine in Javascript geschriebene Anwendung, welche dynamisch Javascript Code nachlädt - per document.createElement("script") und anschließendem appendChild().
Nun möchte ich den nachgeladenen Javascript Code mit PHP erzeugen - aber nur unter bestimmten Bedingungen. Es soll nur Code geliefert werden, wenn der Aufrufer entsprechend berechtigt ist.

Welche Möglichkeiten habe ich dafür? Bisher habe ich einen zweistufigen Prozess. Die erste Routine erzeugt Javascript, welches die im Browser geladene Seite (document.) überprüft und einen Wert (account) an eine zweite Routine übermittelt, welche dann nach einer Prüfung des Accounts den endgültigen Code liefert. Die Übergabe des Accountnamens erfolgt per search-Argument (HTTP GET).

Meine PHP-Kenntnisse sind noch sehr oberflächlich, aber Dateiverarbeitung und das Erzeugen von Headern bekomme ich schon hin.

Gibt es vielleicht noch andere Möglichkeiten? Der Ausgangspunkt muss Javascript sein und die PHP-Routinen liegen in einer anderen Domain als die Browser-Seite mit dem Javascript. Bisher bekommt man auch den  Javascript Code angezeigt, wenn man die zweite Routine direkt aufruft. Das möchte ich vermeiden.

Mir steht PHP 4.1.0 zur Verfügung.

Ralf

P.S. Warum bekommt man eigentlich für die erste Antwort nach einem Posting keine Mail? Fehler in der Forensoftware?

[wahsaga]

hi,

Nun möchte ich den nachgeladenen Javascript Code mit PHP erzeugen - aber nur unter bestimmten Bedingungen. Es soll nur Code geliefert werden, wenn der Aufrufer entsprechend berechtigt ist.

Welche Möglichkeiten habe ich dafür?

Bspw. HTTP Auth oder Sessions.

Der Ausgangspunkt muss Javascript sein und die PHP-Routinen liegen in einer anderen Domain als die Browser-Seite mit dem Javascript.

Gut, dann sind Sessions eher ungünstig.

gruß,
wahsaga

[Ralf]

Hallo,

Bspw. HTTP Auth oder Sessions.

Der Ausgangspunkt muss Javascript sein und die PHP-Routinen liegen in einer anderen Domain als die Browser-Seite mit dem Javascript.

Gut, dann sind Sessions eher ungünstig.

Und wie sollte ich mit HTTP Auth mehr erreichen, als ich jetzt schon habe?

Mir ist schon klar, dass ich keine besonders hohe Sicherheit erreichen kann, wenn der auszuführende Code auf den Client geschickt werden muss.

Vielleicht hole ich mal etwas weiter aus:

In der HTML-Seite mit Javascript wird ein neues SCRIPT Element erzeugt. Dessen Adresse ist http://meinedomain.de/1.php und liefert Javascript Code zurück, um aus der HTML-Seite einen Account-Namen zu extrahieren. Dieser Code erzeugt eine weiteres SCRIPT Element und ruft dieses mit http://meinedomain.de/2.php?id=accountname auf.
In der 2.php wird der Accountname geprüft und ggf. der Code geliefert, um die gewünschte Funktion auszuführen.

Nun könnte aber jemand diese Logik umgehen und mit dem Accountnamen "abc" den Aufruf 2.php?id=xyz machen, weil sein Account "abc" nicht authorisiert ist, er aber weiss, dass es für xyz ist.
Da die Accountinhaber abc und xyz sich ggf. kennen, würden auch weitere Informationen wie User/Password nichts bringen - das wäre doch HTTP Auth?

Bevor ich nun versuche, die DOM-Struktur der geladenen (und ggf. wieder gelöschten) Scripte zu prüfen, wollte ich wissen, ob ich aus PHP noch Möglichkeiten habe.

Da die Routinen 1.php und 2.php sehr schnell nacheinander aufgerufen werden - kann man da nicht was machen? Leider kann es durchaus sein, dass die beiden Aufrufe nicht von der gleichen IP ausgehen (z.B. AOL).

Ralf

[Peter]

Da die Accountinhaber abc und xyz sich ggf. kennen, würden auch weitere Informationen wie User/Password nichts bringen - das wäre doch HTTP Auth?

Wenn anzunehmen ist, dass Accountinhaber abc seine Anmeldedaten an xyz weitergibt, also auch das Passwort, kannst du eigentlich nur mit Sperren der beiden Accounts reagieren.

Eine elektronische Sicherung ist dann jedenfalls unmöglich.

[Ralf]

Wenn anzunehmen ist, dass Accountinhaber abc seine Anmeldedaten an xyz weitergibt, also auch das Passwort, kannst du eigentlich nur mit Sperren der beiden Accounts reagieren.

Ich würde dann den ursprünglich berechtigten Nutzer sperren, der für den Service bezahlt hat. Ich möchte eigentlich erreichen, dass auch der unberechtigte Nutzer für den Service bezahlt.

Eine elektronische Sicherung ist dann jedenfalls unmöglich.

Wie erwähnt, ist in der HTML-Seite eine für den Account eindeutige Kennung enthalten. Die kann der unberechtigte Benutzer nicht ändern. Er ist also eindeutig identifizierbar. Genau dieses Merkmal extrahiere ich mit der ersten Routine und gebe es dann an die zweite weiter.

Ich habe schon dafür gesorgt, dass die Routinen nicht im Cache sind und auch sofort nach Verwendung wieder gelöscht werden (im DOM). Mit dem DOM Inspector des Firefox lässt sich aber trotzdem der Aufruf der zweiten Routine unter bestimmten Bedingungen erkennen.

Zwar reicht auch das noch nicht aus, weil der unberechtigte Benutzer auch noch die ursprüngliche Aufruflogik ändern müsste, aber das wäre auf jeden Fall einfacher, als den Code selbst zu entwickeln.

Ralf

[Peter]

Wenn anzunehmen ist, dass Accountinhaber abc seine Anmeldedaten an xyz weitergibt, also auch das Passwort, kannst du eigentlich nur mit Sperren der beiden Accounts reagieren.

Ich würde dann den ursprünglich berechtigten Nutzer sperren, der für den Service bezahlt hat. Ich möchte eigentlich erreichen, dass auch der unberechtigte Nutzer für den Service bezahlt.

Wie soll das gehen? Dass ein Nutzer erst die eigene Kennung verwendet und dann per Reverse Engineering in die Kennung eines anderen, ihm bekannten Nutzers, wechselt, dürfte ein extrem unwahrscheinliches Vorgehen sein. Wenn ich eine eigene Kennung eines Dienstes habe, und eine alternative Kennung, die mehr anbietet, dann melde ich mich, wenn ich diese Mehrleistung erreichen will, nicht unter meiner eigenen Kennung an, sondern unter der anderen.

Du kriegst also gar nicht mit, dass ich nicht für die Leistung bezahlt habe. Du versuchst etwas, wogegen es kein automatisierbares Mittel gibt: Multiaccountnutzung zu verhindern. Und das auch noch mit extrem eingeschränkten Mitteln, nämlich ausschließlich mit Javascript und PHP von einem Drittserver.

Ich habe schon dafür gesorgt, dass die Routinen nicht im Cache sind und auch sofort nach Verwendung wieder gelöscht werden (im DOM).

Du machst dir etwas vor. Wenn ein Server Inhalte per HTTP ausliefert, kann man diese Inhalte auch speichern. Man benutzt einfach nur keinen Browser, sondern Tools wie cURL.

Und da du die Freundlichkeit hast, Javascript zu verwenden, ist es problemlos möglich, zu erkennen, was genau du da machst, um die "geheimen Inhalte" nachzuladen. Das nachzukonstruieren dürfte ebenfalls problemlos machbar sein. Im Prinzip braucht man nur an der Netzwerkleitung zu lauschen, welche HTTP-Requests denn ausgeführt werden - dein wie auch immer kompliziertes Javascript interessiert da nicht die Bohne, man wartet einfach ab, bis der Request nach der zweiten Ressource kommt.

Zwar reicht auch das noch nicht aus, weil der unberechtigte Benutzer auch noch die ursprüngliche Aufruflogik ändern müsste, aber das wäre auf jeden Fall einfacher, als den Code selbst zu entwickeln.

Sorry, aber ich habe für deine Situation kein Verständnis. Es geht um bezahlte Dienste - aber niemand ist bereit, vernünftige technische Voraussetzungen bereitzustellen (aktuelles PHP, alles auf einer Domain). Und dann willst du noch sowas wie "Sicherheit" herstellen - hahaha!

[Ralf]

Wie soll das gehen? Dass ein Nutzer erst die eigene Kennung verwendet und dann per Reverse Engineering in die Kennung eines anderen, ihm bekannten Nutzers, wechselt, dürfte ein extrem unwahrscheinliches Vorgehen sein. Wenn ich eine eigene Kennung eines Dienstes habe, und eine alternative Kennung, die mehr anbietet, dann melde ich mich, wenn ich diese Mehrleistung erreichen will, nicht unter meiner eigenen Kennung an, sondern unter der anderen.

Du hast nicht verstanden, was das Problem ist. Vielleicht habe ich es aber noch nicht gut genug beschrieben. Im anderen Zweig habe ich nochmals versucht, es deutlicher zu erklären. Vielleicht hilft es ja.

Reverse Engineering ist in der Tat Voraussetzung, um mit einem falschen Accountnamen den Service in Anspruch zu nehmen.

Du kriegst also gar nicht mit, dass ich nicht für die Leistung bezahlt habe. Du versuchst etwas, wogegen es kein automatisierbares Mittel gibt: Multiaccountnutzung zu verhindern. Und das auch noch mit extrem eingeschränkten Mitteln, nämlich ausschließlich mit Javascript und PHP von einem Drittserver.

Da ich die Zugriffe mitlogge, würden Unregelmäßigkeiten auffallen. Dabei würde auch der verwendete Accountname auftauchen.
Ich wäre also gewarnt - wobei dann letztlich der "korrekt" gefakte Aufruf nicht mehr auffallen würde. Jedenfalls nicht in der jetzigen Ausführung. Daher suche ich nach Alternativen.

Du machst dir etwas vor. Wenn ein Server Inhalte per HTTP ausliefert, kann man diese Inhalte auch speichern. Man benutzt einfach nur keinen Browser, sondern Tools wie cURL.

Ich mache mir nichts vor - ich setze nur die Schwelle für den Benutzer höher.

Und da du die Freundlichkeit hast, Javascript zu verwenden, ist es problemlos möglich, zu erkennen, was genau du da machst, um die "geheimen Inhalte" nachzuladen. Das nachzukonstruieren dürfte ebenfalls problemlos machbar sein. Im Prinzip braucht man nur an der Netzwerkleitung zu lauschen, welche HTTP-Requests denn ausgeführt werden - dein wie auch immer kompliziertes Javascript interessiert da nicht die Bohne, man wartet einfach ab, bis der Request nach der zweiten Ressource kommt.

Ich komme nicht umhin, Javascript zu verwenden - jedenfalls sehe ich bisher keine andere Möglichkeit, wenn ich die Ausgangsbasis betrachte - du vielleicht?
Auf jeden Fall müsste der Benutzer entweder sehr gute Kenntnisse haben oder jemanden dafür beauftragen. Beides zwar nicht ausgeschlossen, aber extrem unwahrscheinlich. Meine Zielgruppe ist nicht das Hacker-Umfeld ;)

Sorry, aber ich habe für deine Situation kein Verständnis. Es geht um bezahlte Dienste - aber niemand ist bereit, vernünftige technische Voraussetzungen bereitzustellen (aktuelles PHP, alles auf einer Domain). Und dann willst du noch sowas wie "Sicherheit" herstellen - hahaha!

Darf ich mitlachen? Du hast kein Verständnis, weil du es nicht verstanden hast. Und du wirst mir auch kaum erklären können, was die PHP-Version für einen Einfluss auf mein aktuelles Problem hat - oder liege ich da falsch?

Ja - ich biete einen kostenpflichtigen Service an und muss mich leider an die Gegebenheiten halten. Wenn ich dafür schon die bestmögliche Lösung gefunden habe, kann ich es auch nicht ändern.

Ralf

[wahsaga]

hi,

Du hast kein Verständnis, weil du es nicht verstanden hast.

Nun, mit deinen weiteren Erklärungen macht sich bei mir auch langsam mehr Verwirrung breit, als Erleuchtung.

Wer welche Dienstleistung anbietet, wo du einsteigst und was genau du jetzt wirklich machst und wie, welche Daten du von wo ausliest und an wen weitergibst - ich blicke nicht durch.

gruß,
wahsaga

[Ralf]

Hallo,

Nun, mit deinen weiteren Erklärungen macht sich bei mir auch langsam mehr Verwirrung breit, als Erleuchtung.

Wer welche Dienstleistung anbietet, wo du einsteigst und was genau du jetzt wirklich machst und wie, welche Daten du von wo ausliest und an wen weitergibst - ich blicke nicht durch.

Aus deinem Beitrag von 16:32 hatte ich schon den Eindruck, dass es dir klar war. Ich hatte ja extra den Grobablauf mit den Beteiligten dargestellt. Aber gern noch einmal - vielleicht gibt es ja noch eine bessere "Lösung".

1. Dienstleister ABC bietet "Datenverarbeitung" an. Kunde 1 hat dort einen Account. Die Seiten von ABC werden dynamisch erzeugt (ASP) und enthalten den Accountnamen von Kunde 1.

2. Kunde 1 ruft bei ABC eine Funktion auf, um sich Daten formatiert anzeigen zu lassen. Die Anzeige erfolgt in einem Popup und kann Daten enthalten, die Kunde 1 dort eingegeben hat, um meinen Service zu nutzen.

3. Popup führt Javascript aus, welches via 1.php von meinem Server geliefert wird. Javascript liest per opener den Accountnamen von Kunde 1 aus.

4. Javascript ruft 2.php?id=accountname auf. 2.php prüft den Accountnamen und gibt Javascript zurück, um den Service auszuführen (oder eben nicht, wenn nicht authorisiert).

Nun kommt Kunde 2 ins Spiel. Der möchte den Service auch nutzen und weiss, dass es mit dem Accountnamen von Kunde 1 möglich ist. Oder die beiden kennen sich sogar und teilen sich die Kosten oder was weiss ich ...

Nun möchte ich es verhindern bzw. möglichst schwer machen, dass unter dem Accountnamen von Kunde 2 mein Service aufgerufen werden kann, wenn der bei mir nicht registriert ist.

Alees klar?

Ralf

[wahsaga]

hi,

1. Dienstleister ABC bietet "Datenverarbeitung" an. Kunde 1 hat dort einen Account. Die Seiten von ABC werden dynamisch erzeugt (ASP) und enthalten den Accountnamen von Kunde 1.

2. Kunde 1 ruft bei ABC eine Funktion auf, um sich Daten formatiert anzeigen zu lassen. Die Anzeige erfolgt in einem Popup und kann Daten enthalten, die Kunde 1 dort eingegeben hat, um meinen Service zu nutzen.

3. Popup führt Javascript aus, welches via 1.php von meinem Server geliefert wird. Javascript liest per opener den Accountnamen von Kunde 1 aus.

4. Javascript ruft 2.php?id=accountname auf. 2.php prüft den Accountnamen und gibt Javascript zurück, um den Service auszuführen (oder eben nicht, wenn nicht authorisiert).

Nun kommt Kunde 2 ins Spiel. Der möchte den Service auch nutzen und weiss, dass es mit dem Accountnamen von Kunde 1 möglich ist. Oder die beiden kennen sich sogar und teilen sich die Kosten oder was weiss ich ...

Nun möchte ich es verhindern bzw. möglichst schwer machen, dass unter dem Accountnamen von Kunde 2 mein Service aufgerufen werden kann, wenn der bei mir nicht registriert ist.

Gut, Kunde 2 ersetzt jetzt in seiner Seite, noch bevor er deine Funktionalität aufruft, seinen Accountnamen durch den von Kunde 1.
Das kann er z.B. mit einem popligen Bookmarklet machen, welches den Inhalt im DOM austauscht. Anschließend findet deine Funkionalität den Accountnamen von Kunde 1 vor - wie soll sie jetzt feststellen, dass daran manipuliert wurde?

Das könnte ich mir höchstens noch vorstellen, wenn der URL, unter dem Dienstleister ABC seine Datenausgabe bereitstellt, parametrisiert ist - und dein Script diesen Parameter ausliest und vergleicht.

gruß,
wahsaga

[Peter]

Nun möchte ich den nachgeladenen Javascript Code mit PHP erzeugen - aber nur unter bestimmten Bedingungen. Es soll nur Code geliefert werden, wenn der Aufrufer entsprechend berechtigt ist.

Also Username und Passwort beim Request mitschicken.

Welche Möglichkeiten habe ich dafür? Bisher habe ich einen zweistufigen Prozess. Die erste Routine erzeugt Javascript, welches die im Browser geladene Seite (document.) überprüft und einen Wert (account) an eine zweite Routine übermittelt, welche dann nach einer Prüfung des Accounts den endgültigen Code liefert. Die Übergabe des Accountnamens erfolgt per search-Argument (HTTP GET).

Ich hoffe, du glaubst nicht daran, dass du irgendwelche Sicherheit produzierst.

Der Ausgangspunkt muss Javascript sein und die PHP-Routinen liegen in einer anderen Domain als die Browser-Seite mit dem Javascript.

Das ist tendentiell ungünstig, weil dich wahrscheinlich irgendwann einmal die Same-Origin-Policy kneift und dir lapidar meldet "Zugriff verweigert". Sorge immer dafür, dass Seite und Javascript von der gleichen Domain kommen, um das sicher zu vermeiden.

Mir steht PHP 4.1.0 zur Verfügung.

Sorge insbesondere dafür, dass hier von deinem Hoster mal ganz dringend ein Sicherheitsupdate gemacht wird. Die 4er-Serie von PHP ist derzeit bei Version 4.4.4 und hat eine ellenlange Liste von Sicherheitsproblemen gelöst, die nicht nur deine Applikation, sondern auch die Serversicherheit gefährden können.

[Ralf]

Also Username und Passwort beim Request mitschicken.

Wenn ich einem Anwender solche Daten mitteile, könnten die an einen anderen unberechtigten Anwender weitergegeben werden. Als eindeutige Kennung hat die ausgehende HTML-Seite einen Accountnamen im Text. Ich bin nicht "Erzeuger" dieser Seite, kann aber den Anwender dazu bringen, dass er den Inhalt so erzeugen lässt, dass ein von mir vorgegebenes SCRIPT aufgerufen wird.

Ich hoffe, du glaubst nicht daran, dass du irgendwelche Sicherheit produzierst.

Absolut sicherlich nicht - aber ich will die Hürde möglichst hoch ansetzen.

Das ist tendentiell ungünstig, weil dich wahrscheinlich irgendwann einmal die Same-Origin-Policy kneift und dir lapidar meldet "Zugriff verweigert". Sorge immer dafür, dass Seite und Javascript von der gleichen Domain kommen, um das sicher zu vermeiden.

Wenn das Javascript von einer anderen Domain nachgeladen wird, erfolgt die Ausführung trotzdem in der gleichen Domain - ist also kein Problem. Ist auch hier nicht das Thema.

Sorge insbesondere dafür, dass hier von deinem Hoster mal ganz dringend ein Sicherheitsupdate gemacht wird. Die 4er-Serie von PHP ist derzeit bei Version 4.4.4 und hat eine ellenlange Liste von Sicherheitsproblemen gelöst, die nicht nur deine Applikation, sondern auch die Serversicherheit gefährden können.

Darauf dränge ich schon seit längerer Zeit. Das mit der Serversicherheit wäre vielleicht ein Argument ;)

Hättest du eine Idee, wie ich beim Aufruf der zweiten Routine (/2.php?id=xxx) prüfen könnte, ob kurz zuvor vom gleichen Client die erste Routine (/1.php) aufgerufen wurde? Das wäre für _mich_ aktuell schon Sicherheit genug.

Ralf

[Peter]

Hättest du eine Idee, wie ich beim Aufruf der zweiten Routine (/2.php?id=xxx) prüfen könnte, ob kurz zuvor vom gleichen Client die erste Routine (/1.php) aufgerufen wurde? Das wäre für _mich_ aktuell schon Sicherheit genug.

Was bringt dir das?

Wenn ich der "echte" Accountinhaber bin, passiert das automatisch. Und wenn ich der falsche Accountinhaber bin, ebenso - weil ich ja die richtigen Anmeldedaten des echten Accounts kenne.

[Ralf]

Hättest du eine Idee, wie ich beim Aufruf der zweiten Routine (/2.php?id=xxx) prüfen könnte, ob kurz zuvor vom gleichen Client die erste Routine (/1.php) aufgerufen wurde? Das wäre für _mich_ aktuell schon Sicherheit genug.

Was bringt dir das?

Wenn ich der "echte" Accountinhaber bin, passiert das automatisch. Und wenn ich der falsche Accountinhaber bin, ebenso - weil ich ja die richtigen Anmeldedaten des echten Accounts kenne.

Nein - es passiert nur beim korrekten Aufruf. Weil ja die 1.php den Accountnamen aus der Seite extrahiert und and die 2.php übergibt, die dann den Code liefert.

Der unberechtigte Nutzer müsste die 2.php direkt mit dem Accountnamen des berechtigten Nutzers aufrufen und hätte zuvor nicht die 1.php aufgerufen.

Wenn ich jetzt nochmals darüber nachdenke, kann der unberechtigte natürlich zuvor zum Schein zuvor auch die 1.php aufrufen - hmmm...

Gibt es denn keine Chance, den berechtigten Aufruf der 2.php vom unberechtigten zu unterscheiden? Mit HTTP POST wäre das einfacher, weil der Accountname nicht sichtbar wird, aber das geht nicht für das Nachladen von Javascript...

Ralf

[wahsaga]

hi,

Wenn ich der "echte" Accountinhaber bin, passiert das automatisch. Und wenn ich der falsche Accountinhaber bin, ebenso - weil ich ja die richtigen Anmeldedaten des echten Accounts kenne.

Nein - es passiert nur beim korrekten Aufruf. Weil ja die 1.php den Accountnamen aus der Seite extrahiert und and die 2.php übergibt, die dann den Code liefert.

Der unberechtigte Nutzer müsste die 2.php direkt mit dem Accountnamen des berechtigten Nutzers aufrufen und hätte zuvor nicht die 1.php aufgerufen.

Wenn ich jetzt nochmals darüber nachdenke, kann der unberechtigte natürlich zuvor zum Schein zuvor auch die 1.php aufrufen - hmmm...

Wenn die 1.php nur dazu da sein soll, einen Accountnamen aus dem HTML zu extrahieren - dann kann ich doch auch als unberechtigter Nutzer diesen Accountnamen in meinem HTML unterbringen - oder wie willst du das verhindern?

Gibt es denn keine Chance, den berechtigten Aufruf der 2.php vom unberechtigten zu unterscheiden? Mit HTTP POST wäre das einfacher, weil der Accountname nicht sichtbar wird, aber das geht nicht für das Nachladen von Javascript...

Auch POST bringt dir nichts, wenn berechtigter Nutzer Zugangsdaten an unberechtigten Nutzer weitergibt.

Dein Problem ist, dass die Zugangsdaten über den Client gehen sollen/müssen - und damit sind sie dort auch beliebig kopier- und manipulierbar.

Du versuchst etwas zu schützen, dass auf Grund seiner quelloffenen Konzeptionierung nicht zu schützen ist.

gruß,
wahsaga

[Ralf]

Wenn die 1.php nur dazu da sein soll, einen Accountnamen aus dem HTML zu extrahieren - dann kann ich doch auch als unberechtigter Nutzer diesen Accountnamen in meinem HTML unterbringen - oder wie willst du das verhindern?

Kann er nicht, da er keinen Einfluss auf die Seite hat, wo der Accountname steht. Er hat Einfluss auf eine Seite, dies von dieser geöffnet wird und kann dort u.a. den Aufruf für meinen Service unterbringen.
Den Accountnamen bekomme ich via opener aus der öffnenden Seite. Das ist zuverlässig.
Der Nutzer könnte aber den Code auf der geöffneten Seite so abändern, dass gleich die 2.php mit dem "falschen" Accountnamen aufgerufen wird. Er müsste zwar auch noch ein paar weitere Zeilen hinzufügen, was aber im Vergleich zum gelieferten Code trivial ist.

Dein Problem ist, dass die Zugangsdaten über den Client gehen sollen/müssen - und damit sind sie dort auch beliebig kopier- und manipulierbar.

Es sind ja im eigentlichen Sinne keine Zugangsdaten, sondern eine Information, die aus einer HTML-Seite extrahiert wird.

Vielleicht beschreibe ich das Problem mal anders:

1. Ein Dienstleister (das bin nicht ich) stellt eine Anwendung zur Verfügung, mit der Daten des Benutzers angezeigt werden können. Dafür hat der Benutzer einen Accountnamen, welcher auf den Seiten des Dienstleisters zu finden ist.

2. Der Benutzer fordert eine Datenanzeige an. Diese wird in einem Popup geöffnet. Der Benutzer kann durch Einstellungen Einfluss auf die Daten nehmen. U.a. kann dort HTML "injiziert" werden (ungeprüft - und damit auch Javascript).

3. Dieses Javascript liegt auf meinem Server und wird von einer PHP-Routine geliefert (1.php).

4. Die 1.php sendet Javascript. Dieses extrahiert den Accountnamen aus dem öffnenden Fenster und ruft eine 2.php mit dem Accountnamen als Parameter auf.

5. Die 2.php prüft den Accountnamen und liefert in Javascript geschriebene Service-Routinen zurück, wenn der Benutzer als berechtigt erkannt wird.

Bis zu 3) gibt es keine Änderungsmöglichkeit. 4+5 sind mein Lösungsansatz und ich habe hier gefragt, welche Möglichkeiten es gibt. Ich habe auch bereits geprüft, den gesamten Inhalt der geöffneten Seite per HTTP POST an meinen Server zu schicken, um dort das Ergebnis zu erzeugen. Das ist aber bei der möglichen Datenmenge nicht besonders effektiv und wurde daher verworfen.
Die Verarbeitung der Daten _muss_ auf dem Client erfolgen und daher _muss_ ich Javascript zurückgegeben.

Du versuchst etwas zu schützen, dass auf Grund seiner quelloffenen Konzeptionierung nicht zu schützen ist.

Ich will ja auch nur versuchen, die Barriere möglichst hoch anzusetzen.

Wie ich bereits in meinem ersten Posting geschrieben habe, bin ich bzgl. PHP noch Anfänger und habe vielleicht eine Möglichkeit übersehen, weil ich sie noch gar nicht kenne.

Ralf

[wahsaga]

hi,

Wenn die 1.php nur dazu da sein soll, einen Accountnamen aus dem HTML zu extrahieren - dann kann ich doch auch als unberechtigter Nutzer diesen Accountnamen in meinem HTML unterbringen - oder wie willst du das verhindern?

Kann er nicht, da er keinen Einfluss auf die Seite hat, wo der Accountname steht. Er hat Einfluss auf eine Seite, dies von dieser geöffnet wird und kann dort u.a. den Aufruf für meinen Service unterbringen.
Den Accountnamen bekomme ich via opener aus der öffnenden Seite. Das ist zuverlässig.

Nicht, wenn der opener nicht das ist, was du erwartest.

Dein Problem ist, dass die Zugangsdaten über den Client gehen sollen/müssen - und damit sind sie dort auch beliebig kopier- und manipulierbar.

Es sind ja im eigentlichen Sinne keine Zugangsdaten, sondern eine Information, die aus einer HTML-Seite extrahiert wird.

Ob du diese frei verfügbare Information jetzt Zugangsdatum nennen willst oder nicht, ist doch wurscht - Fakt ist: Du willst den Zugriff davon abhängig machen.

Vielleicht beschreibe ich das Problem mal anders:

1. Ein Dienstleister (das bin nicht ich) stellt eine Anwendung zur Verfügung, mit der Daten des Benutzers angezeigt werden können. Dafür hat der Benutzer einen Accountnamen, welcher auf den Seiten des Dienstleisters zu finden ist.

Gut. Den kann dort (mindestens) der Benutzer lesen, weitergeben kann er ihn auch.

2. Der Benutzer fordert eine Datenanzeige an. Diese wird in einem Popup geöffnet. Der Benutzer kann durch Einstellungen Einfluss auf die Daten nehmen. U.a. kann dort HTML "injiziert" werden (ungeprüft - und damit auch Javascript).

3. Dieses Javascript liegt auf meinem Server und wird von einer PHP-Routine geliefert (1.php).

4. Die 1.php sendet Javascript. Dieses extrahiert den Accountnamen aus dem öffnenden Fenster und ruft eine 2.php mit dem Accountnamen als Parameter auf.

5. Die 2.php prüft den Accountnamen und liefert in Javascript geschriebene Service-Routinen zurück, wenn der Benutzer als berechtigt erkannt wird.

Gut, bis hier keinerlei "Sicherheit" vorhanden.
Lediglich ein beliebig manipulierbarer Parameter wird ausgewertet.

Bis zu 3) gibt es keine Änderungsmöglichkeit. 4+5 sind mein Lösungsansatz und ich habe hier gefragt, welche Möglichkeiten es gibt.

Keine realistischen, m.E.

Die Verarbeitung der Daten _muss_ auf dem Client erfolgen und daher _muss_ ich Javascript zurückgegeben.

Was willst du denn nun eigentlich schützen - die Daten, oder deinen Javascript-Code?

gruß,
wahsaga

[Ralf]

Hallo,

Nicht, wenn der opener nicht das ist, was du erwartest.

Wie schon in der Antwort zu Peter geschrieben, kann ich das m.E. voraussetzen.

Gut. Den kann dort (mindestens) der Benutzer lesen, weitergeben kann er ihn auch.

Ack.

Gut, bis hier keinerlei "Sicherheit" vorhanden.
Lediglich ein beliebig manipulierbarer Parameter wird ausgewertet.

Die Manipulation ist entweder nicht möglich oder nicht sinnvoll - da kommt wieder der Aufwand ins Spiel.

Was willst du denn nun eigentlich schützen - die Daten, oder deinen Javascript-Code?

Ich möchte verhindern, dass jemand meinen Service unberechtigt benutzt. Da sind keine Daten - nur Code.

Ich will es mal so ausdrücken: Es sollte schwieriger sein, den Aufruf zu manipulieren, als den Code selbst zu entwickeln - dann wäre mein Ziel erreicht. Denn dann stünde der Aufwand in keinem Verhältnis zum Ergebnis.

Der Code ist weder besonders umfangreich noch besonders herausragend.  Ein kleine Reise durchs DOM und Ausgabe einer Tabelle. Na ja - selektieren, summieren, sortieren, formatieren ist auch noch dabei. Und eine Reportsprache (eigene HTML Tags) für den Anwender, damit dieser definieren kann, welche Daten wie ausgewertet und dargestellt werden sollen.

Ralf

[Peter]

Ich will es mal so ausdrücken: Es sollte schwieriger sein, den Aufruf zu manipulieren, als den Code selbst zu entwickeln - dann wäre mein Ziel erreicht. Denn dann stünde der Aufwand in keinem Verhältnis zum Ergebnis.

Der Aufruf der Daten ist exakt EIN HTTP-Request:

http://deinserver/2.php?id=accountname

Und schon spuckt dein Server das Javascript aus.

Und dagegen gibt es keinen Schutz.

[Ralf]

Ich will es mal so ausdrücken: Es sollte schwieriger sein, den Aufruf zu manipulieren, als den Code selbst zu entwickeln - dann wäre mein Ziel erreicht. Denn dann stünde der Aufwand in keinem Verhältnis zum Ergebnis.

Der Aufruf der Daten ist exakt EIN HTTP-Request:

http://deinserver/2.php?id=accountname

Und schon spuckt dein Server das Javascript aus.

Und dagegen gibt es keinen Schutz.

Natürlich nicht. Soweit war ich schon, bevor ich hier den Thread eröffnet habe und wissen wollte, was ich anders/besser machen kann - unter den gegebenen Voraussetzungen.

Vielleicht kann ich meine 2.php ja so gestalten, dass sie weitere Dinge überprüft? Danach habe ich gefragt.

Im Übrigen würde es dem unberechtigten Nutzer nichts bringen, nur die 2.php aufzurufen. Er müsste diesen Aufruf auch noch unter den Bedingungen ausführen, welche die 1.php vorbereitet (die liest nicht nur den Accountnamen aus).
Er müsste also die ganze Aufruflogik analysieren und entsprechend modifzieren.
Wenn der Aufwand dafür so groß ist, dass er in den Bereich kommt, wo er auch gleich den von mir angebotenenen Service programmieren könnte, habe ich mein Ziel schon erreicht. Mehr ist kaum drin.

Was könnte ich in dieser Umgebung mit PHP an Hindernissen aufbauen, war daher meine Frage ...

Ralf

[Peter]

Im Übrigen würde es dem unberechtigten Nutzer nichts bringen, nur die 2.php aufzurufen. Er müsste diesen Aufruf auch noch unter den Bedingungen ausführen, welche die 1.php vorbereitet (die liest nicht nur den Accountnamen aus).
Er müsste also die ganze Aufruflogik analysieren und entsprechend modifzieren.

Am Ende jeglicher Logik steht genau 1 Request mit einer URL, die man abfangen und wiederholen kann. Oder noch passend manipulieren. Vollkommen ohne Analyse deines Codes.

Was könnte ich in dieser Umgebung mit PHP an Hindernissen aufbauen, war daher meine Frage ...

Und "Nichts" war unsere Antwort.

[Ralf]

Am Ende jeglicher Logik steht genau 1 Request mit einer URL, die man abfangen und wiederholen kann. Oder noch passend manipulieren. Vollkommen ohne Analyse deines Codes.

Falsch. Ohne die Analyse würde der Aufruf der 2.php auch mit dem berechtigten Accountnamen nur den Code liefern - nicht aber die Umgebung bereitstellen, die dieser Code erwartet.

Was könnte ich in dieser Umgebung mit PHP an Hindernissen aufbauen, war daher meine Frage ...

Und "Nichts" war unsere Antwort.

Wenn du nur die simple Rückgabe des Codes als Problem ansiehst, kann natürlich *deine* Antwort nicht anders lauten. Danach hatte ich aber auch nicht gefragt. Die Rückgabe des Codes soll eben nicht nur von der Übergabe des Accountnamens abhängen.

Ich weiss auch, dass es die absolut sichere Lösung in diesem Umfeld nicht geben kann.

Meine Hoffnung war (bzw. ist immer noch, da ich auf die diesbezügliche Frage noch keine Antwort erhalten habe), dass ich auf der Server-Seite den Aufruf der 1.php und der 2.php miteinander in Beziehung setzen kann, ich also in der 2.php überprüfen kann, dass die 1.php gerade unmittelbar zuvor von dem gleichen Client aufgerufen wurde. Mit der IP-Adresse bekomme ich es jedenfalls nicht hin. Gibt es da wirklich nichts, was auch in dem beschriebenen Umfeld funktioniert (von mir aus auch mit einer höheren PHP Version ...)?

Oder ein völlig anderer Ansatz, der den Gegebenheiten gerecht wird.

Manchmal muss man sich auch mit weniger als 100% zufrieden geben ...

Ralf

[Peter]

Am Ende jeglicher Logik steht genau 1 Request mit einer URL, die man abfangen und wiederholen kann. Oder noch passend manipulieren. Vollkommen ohne Analyse deines Codes.

Falsch. Ohne die Analyse würde der Aufruf der 2.php auch mit dem berechtigten Accountnamen nur den Code liefern - nicht aber die Umgebung bereitstellen, die dieser Code erwartet.

Und im Code sind die "geheimen" Informationen, die du nur dem richtigen User gegen Geld rausrücken willst, und können ggf. auch anderweitig passend "verarbeitet" werden. Javascript ist ja auch nur Text, den man parsen und zerpflücken kann.

Was könnte ich in dieser Umgebung mit PHP an Hindernissen aufbauen, war daher meine Frage ...

Und "Nichts" war unsere Antwort.

Wenn du nur die simple Rückgabe des Codes als Problem ansiehst, kann natürlich *deine* Antwort nicht anders lauten. Danach hatte ich aber auch nicht gefragt. Die Rückgabe des Codes soll eben nicht nur von der Übergabe des Accountnamens abhängen.

Wir drehen uns im Kreis. Und sowas wird auf Dauer langweilig. Ich klinke mich hier aus.

[wahsaga]

hi,

Meine Hoffnung war (bzw. ist immer noch, da ich auf die diesbezügliche Frage noch keine Antwort erhalten habe), dass ich auf der Server-Seite den Aufruf der 1.php und der 2.php miteinander in Beziehung setzen kann, ich also in der 2.php überprüfen kann, dass die 1.php gerade unmittelbar zuvor von dem gleichen Client aufgerufen wurde. Mit der IP-Adresse bekomme ich es jedenfalls nicht hin. Gibt es da wirklich nichts, was auch in dem beschriebenen Umfeld funktioniert (von mir aus auch mit einer höheren PHP Version ...)?

Na ja, wie gesagt - Sessions können das halbwegs zuverlässig sicherstellen helfen.

Aber damit machst du aus dem Problem, dass eine Ressource über HTTP frei abgerufen werden kann nur das Problem, dass jetzt zwei Ressourcen hintereinander abgerufen werden müssen ...

Und damit stehst du m.E. wieder an genau der gleichen Stelle an - habe ich einmal beobachtet, mit welchen Parametern 1.php aufgerufen wird, kann ich auch das in einer anderen Umgebung beliebig reproduzieren.

1.php soll etwas am DOM des HTML-Dokumentes ändern, was die Voraussetzung für korrekte Funktion von 2.php bereitstellt? Auch schön und gut, dann sorge ich eben ein mal dafür, dass das HTML in dieser Form vorliegt.

gruß,
wahsaga

[Ralf]

Hallo,

Na ja, wie gesagt - Sessions können das halbwegs zuverlässig sicherstellen helfen.

Hast aber auch geschrieben, dass es in der von mir beschriebenen Umgebung nicht geeignet wäre.

Aber damit machst du aus dem Problem, dass eine Ressource über HTTP frei abgerufen werden kann nur das Problem, dass jetzt zwei Ressourcen hintereinander abgerufen werden müssen ...

Und in dem Fall wäre wohl der Aufwand für mich zu hoch.

1.php soll etwas am DOM des HTML-Dokumentes ändern, was die Voraussetzung für korrekte Funktion von 2.php bereitstellt? Auch schön und gut, dann sorge ich eben ein mal dafür, dass das HTML in dieser Form vorliegt.

1.php (und ggf. weitere) machen jedenfalls Dinge, ohne die 2.php nicht funktioniert. Es bedeutet Aufwand, die Umgebung zu analysieren und es nachzubilden.
Und natürlich wird in den Javascript Routinen auch nochmals der Accountname überprüft (es wird der an die 2.php übergebene Wert verschlüsselt in das Javascript eingesetzt und dann mit dem Wert verglichen, der durch die gleiche Verschlüsselung des Accountnamens aus der HTML-Seite erzeugt wird).
Wer es umgehen möchte, muss nicht nur die Umgebung, sondern auch die Funktionsweise des Codes analysieren und verstehen.
Wer das schafft, kann auch gleich das Coding selbst erstellen.

Trotzdem vielen Dank!

Ralf

[wahsaga]

hi,

Na ja, wie gesagt - Sessions können das halbwegs zuverlässig sicherstellen helfen.

Hast aber auch geschrieben, dass es in der von mir beschriebenen Umgebung nicht geeignet wäre.

Na ja, da war mir der Aufbau noch nicht so klar.

Aber wenn sich alle deine Aktionen auf dem selben Server abspielen (1.php, 2.php) - dann könnte man durchaus Sessions verwenden.

Wer es umgehen möchte, muss nicht nur die Umgebung, sondern auch die Funktionsweise des Codes analysieren und verstehen.
Wer das schafft, kann auch gleich das Coding selbst erstellen.

Na ja, wenn das, was du vorher beschrieben hast -

Der Code ist weder besonders umfangreich noch besonders herausragend.  Ein kleine Reise durchs DOM und Ausgabe einer Tabelle. Na ja - selektieren, summieren, sortieren, formatieren ist auch noch dabei.

• schon "alles" ist, dann ist man mit einer Eigenentwicklung vermutlich schneller am Ziel.
  (Wobei ich mich da aber auch frage, wo du die Schöpfungshöhe deines Codes siehst, bzw. wo den Grund, eher Triviales als Dienstleistung "verkaufen" zu wollen.)

gruß,
wahsaga

[Ralf]

hi,

Hallo,

Aber wenn sich alle deine Aktionen auf dem selben Server abspielen (1.php, 2.php) - dann könnte man durchaus Sessions verwenden.

Was aber wohl ziemlichen Aufwand bedeutet, wenn man zuvor noch nie damit gearbeitet hat. Oder gibt es da eine simple Anleitung?

Ich bin jetzt auf die Idee verfallen, die an 2.php übergebene ID zu verschlüsseln und im erzeugten Javascript als Konstante zu definieren. Im Code wird dann erneut die ID aus der opener Seite geholt, ebenfalls verschlüsselt und verglichen.

Na ja, wenn das, was du vorher beschrieben hast -

Der Code ist weder besonders umfangreich noch besonders herausragend.  Ein kleine Reise durchs DOM und Ausgabe einer Tabelle. Na ja - selektieren, summieren, sortieren, formatieren ist auch noch dabei.

• schon "alles" ist, dann ist man mit einer Eigenentwicklung vermutlich schneller am Ziel.

Das setzt aber voraus, dass der interessierte Benutzer programmieren kann. Selbst wenn er das kann, würde die Entwicklung doch einige Zeit benötigen. Und da Zeit bekanntlich Geld ist, wird er das ab einem bestimmten Aufwand unterlassen.
Wenn es dagegen zu einfach ist, den Aufruf so hinzubekommen, dass von einem unberechtigten Benutzer die ID eines berechtigen Benutzers mitgegeben werden kann, sieht die Sache schon anders aus.

(Wobei ich mich da aber auch frage, wo du die Schöpfungshöhe deines Codes siehst, bzw. wo den Grund, eher Triviales als Dienstleistung "verkaufen" zu wollen.)

Das Ergebnis zählt. Es besteht Bedarf für die Auswertungen, die mein Code vornimmt. Wie einfach oder komplex dieser Code ist, spielt dabei keine Rolle.
Es ist halt nicht jeder in der Lage, Daten in eine auswertbare Form zu bringen und das Ergebnis dann auch noch in einer Form zu präsentieren, die durch den Benutzer mit einfachen Mitteln angepasst werden kann.
Meine Zielgruppe sind halt Anwender und die sind meistens keine Programmierer.

Ralf

[wahsaga]

hi,

Aber wenn sich alle deine Aktionen auf dem selben Server abspielen (1.php, 2.php) - dann könnte man durchaus Sessions verwenden.

Was aber wohl ziemlichen Aufwand bedeutet, wenn man zuvor noch nie damit gearbeitet hat. Oder gibt es da eine simple Anleitung?

Siehe Manual :-)

Im Grunde gehören Sessions zum simpelsten von der (EDV-)Welt - sie bieten lediglich eine Möglichkeit, Daten beim Zugriff über ein zustandsloses Protokoll wie HTTP nun mal eines ist über mehrere Anfragen hinweg einem Client (hinreichend) eindeutig zuzuordnen. "Voodoo" ist das wirklich nicht.

In PHP ist die Datenbereitstellung im Script über das globale Array $_SESSION implementiert - man muss nur noch am Anfang jedes Scripts die Session über session_start() wieder aufnehmen.
Um die Übergabe der Session-ID kümmert sich PHP normalerweise selbstständig (im aktuellen Szenario, wie nur JS-Ressourcen in eine Fremdseite eingebunden wären, müsste man sich darum aber ggf. selber kümmern).

Ich bin jetzt auf die Idee verfallen, die an 2.php übergebene ID zu verschlüsseln und im erzeugten Javascript als Konstante zu definieren. Im Code wird dann erneut die ID aus der opener Seite geholt, ebenfalls verschlüsselt und verglichen.

Also sind der Verschlüsselungsagorithmus und auch der Key dem Client bekannt.

Das setzt aber voraus, dass der interessierte Benutzer programmieren kann. Selbst wenn er das kann, würde die Entwicklung doch einige Zeit benötigen. Und da Zeit bekanntlich Geld ist, wird er das ab einem bestimmten Aufwand unterlassen. [...]
Meine Zielgruppe sind halt Anwender und die sind meistens keine Programmierer.

Es reicht einer mit Programmiererfahrung, der deine Pseudo-Sicherheit durchschaut, und seinen "Hack" im WWW veröffentlicht. Dass ein "Markt" für sowas vorhanden ist, sieht man ja an den zahlreichen "Cracks & Serialz"-Seiten.

gruß,
wahsaga

[Ralf]

Hallo,

Siehe Manual :-)

Mach ich. Mir fehlte nur der Ausgangspunkt.

In PHP ist die Datenbereitstellung im Script über das globale Array $_SESSION implementiert - man muss nur noch am Anfang jedes Scripts die Session über session_start() wieder aufnehmen.

Dann werde ich mich mal damit befassen.

Um die Übergabe der Session-ID kümmert sich PHP normalerweise selbstständig (im aktuellen Szenario, wie nur JS-Ressourcen in eine Fremdseite eingebunden wären, müsste man sich darum aber ggf. selber kümmern).

Wenn ich das richtig verstanden habe, müsste ich in der 1.php eine Session starten und in das erzeugte Javascript die ID packen, welche dann beim Aufruf der 2.php übergeben wird. Und hätte dann eine eindeutige Verbindung, ohne die die 2.php den Code nicht sendet (den natürlich ein berechtigter Benutzer mit den schon hinreichend diskutierten Methoden ohnehin bekommt).
Da der von der 1.php erzeugte Javascript-Code mit hinreichender Sicherheit den Accountnamen übermittelt bekommt, erfolgt der Aufruf der 2.php mit dem Accountnamen und der Session-ID. Die 2.php kann dann also feststellen, ob die Session-ID gültig ist und nur dann den Code senden (nachdem natürlich auch der Accountname geprüft wurde).

Wenn das so funktioniert, werde ich mal versuchen, das einzubauen.

Also sind der Verschlüsselungsagorithmus und auch der Key dem Client bekannt.

Natürlich - es wäre nur eine weitere Verschleierung.

Es reicht einer mit Programmiererfahrung, der deine Pseudo-Sicherheit durchschaut, und seinen "Hack" im WWW veröffentlicht. Dass ein "Markt" für sowas vorhanden ist, sieht man ja an den zahlreichen "Cracks & Serialz"-Seiten.

So etwas kann ich zwar nicht ausschließen, ist aber bei meiner Zielgruppe doch extrem unwahrscheinlich. Dafür ist sie auch viel zu klein.

Vielen Dank schon mal für dein Interesse und die Hilfen!

Ralf

[Peter]

Wenn die 1.php nur dazu da sein soll, einen Accountnamen aus dem HTML zu extrahieren - dann kann ich doch auch als unberechtigter Nutzer diesen Accountnamen in meinem HTML unterbringen - oder wie willst du das verhindern?

Kann er nicht, da er keinen Einfluss auf die Seite hat, wo der Accountname steht.

Seite aufrufen, "Speichern unter..." im Browser (oder aus dem Cache fischen), Accountnamen manipulieren, Javascriptaufrufe anpassen (ggf. ebenfalls lokal speichern), und neu im Browser laden.

Ist so einfach, wie nur irgendwas.

Denke bitte nicht, dass etwas nicht geht, nur weil du bislang noch nicht weißt, dass es doch geht. Ich habe so meine Erfahrungen gesammelt - und alles, was du dem User auf seinen Browser lieferst, kann und wird dieser manipulieren, wenn es der Aufwand rechtfertigt, weil dort aller Code offen und bearbeitbar ist.

Dein Problem ist, dass die Zugangsdaten über den Client gehen sollen/müssen - und damit sind sie dort auch beliebig kopier- und manipulierbar.

Es sind ja im eigentlichen Sinne keine Zugangsdaten, sondern eine Information, die aus einer HTML-Seite extrahiert wird.

Macht aber nichts, der Effekt ist der gleiche: Es gibt mal die "richtige" Information in der Seite, mal die "falsche".

2. Der Benutzer fordert eine Datenanzeige an. Diese wird in einem Popup geöffnet. Der Benutzer kann durch Einstellungen Einfluss auf die Daten nehmen. U.a. kann dort HTML "injiziert" werden (ungeprüft - und damit auch Javascript).

Wäre ich dieser Dienstleister, würde ich diese Lücke schnellstmöglich schließen. Es sieht ja nicht so aus, als ob deine "Sondernutzung" wirklich beabsichtigt ist.

Du versuchst etwas zu schützen, dass auf Grund seiner quelloffenen Konzeptionierung nicht zu schützen ist.

Ich will ja auch nur versuchen, die Barriere möglichst hoch anzusetzen.

Die Barriere ist keine. Deine 2.php liefert Daten aus, wenn der Accountname stimmt.

Das bedeutet, man muß nur eine einzige Information korrekt "raten" oder "wissen", schon kommt man an deine Daten ran.

Wenn du das nicht willst, führe eine Authentifizierung ein, von der du sichergehen kannst, dass der wahre Inhaber des Accounts sie niemand Unberechtigtem weitergibt.

Und wenn das doch geschieht, dann gibt es dagegen keinerlei technischen Schutz für dich.

[Ralf]

Seite aufrufen, "Speichern unter..." im Browser (oder aus dem Cache fischen), Accountnamen manipulieren, Javascriptaufrufe anpassen (ggf. ebenfalls lokal speichern), und neu im Browser laden.

Ist so einfach, wie nur irgendwas.

Klar ist das einfach - funktioniert aber in dem konkreten Fall nicht.  Wäre auch viel zu aufwändig, weil die angezeigten Seiten ständig neu generiert werden.

Denke bitte nicht, dass etwas nicht geht, nur weil du bislang noch nicht weißt, dass es doch geht. Ich habe so meine Erfahrungen gesammelt - und alles, was du dem User auf seinen Browser lieferst, kann und wird dieser manipulieren, wenn es der Aufwand rechtfertigt, weil dort aller Code offen und bearbeitbar ist.

Ich habe schon verstanden, dass du mich für ziemlich naiv hältst. Du kannst aber beruhigt sein - bisher hast du mir nichts erzählt, was mir unbekannt war.
Und das richtige Stichwort hast du auch gegeben: "wenn es der Aufwand rechtfertigt,". Also muss der Aufwand möglichst hoch angesetzt werden.

Macht aber nichts, der Effekt ist der gleiche: Es gibt mal die "richtige" Information in der Seite, mal die "falsche".

Genau das funktioniert eben nicht - und daher ist zumindest die Extraktion des Accountnamens ziemlich verlässlich.

Wäre ich dieser Dienstleister, würde ich diese Lücke schnellstmöglich schließen. Es sieht ja nicht so aus, als ob deine "Sondernutzung" wirklich beabsichtigt ist.

Sie ist dem Dienstleister sogar bekannt. Gehört aber hier nicht zum Thema.

Die Barriere ist keine. Deine 2.php liefert Daten aus, wenn der Accountname stimmt.

Das bedeutet, man muß nur eine einzige Information korrekt "raten" oder "wissen", schon kommt man an deine Daten ran.

Also muss es weitere Kriterien geben, wenn man das technisch lösen will.

Es ist ja nun auch nicht so, dass der Benutzer einfach nur die 2.php mit dem "richtigen" Parameter aufrufen müsste. Er muss auch das Umfeld dafür bereitstellen, was zuvor zwei andere Routinen machen. Dies müsste er nachbilden. Natürlich nicht unmöglich, aber schon ziemlicher Aufwand.

Wenn du das nicht willst, führe eine Authentifizierung ein, von der du sichergehen kannst, dass der wahre Inhaber des Accounts sie niemand Unberechtigtem weitergibt.

Und wenn das doch geschieht, dann gibt es dagegen keinerlei technischen Schutz für dich.

Ich weiss - dagegen gibt es andere Möglichkeiten.

Ralf