j0Shi: Javascript einbinden aber http access verhindern

Hey,

ich möchte im HTML-Code eine Javascript-Datei bzw. Javascript-Code einfügen ohne dass Zugriff per http auf diese Datei möglich ist.

Also Beispielsweise eine .js-Datei per <script type="text/javascript" src="any.js"> einbinden, selbige soll aber nicht im Browser durch http://www.domain.de/any.js abruf- und einsehbar sein.
Geht das?

Als Lösung hatte ich mir überlegt, statt der .js-Datei z.B. eine .php-Datei einzubinden:

<script type="text/javascript" src="js.php">
In der js.php wird dann der Javascript-Code mit echo ausgegeben. Vorher wird in der index.php eine Konstante definiert, die in der js.php auf Existenz überprüft wird, ansonsten wird kein Javascript-Code ausgegeben. Das ganze funktioniert leider so nicht. Muss ich in der js.php den Javascript - Code anders ausgeben als mit echo?

Ein anderes Problem was ich habe betrifft Firefox-Extensions. Auch dort können in den .xul-Dateien Javascript-Dateien eingebunden werden. Auch hier würde ich gerne erreichen, dass die Dateien zwar eingebunden, aber nicht per http eingesehen werden können. Bei der Firefox - Extension kommt erschwerend hinzu, dass ich dort nicht mit php arbeiten kann, das Sicherungssystem also komplett aus Javascript bestehen muss. Dazu fällt mir momentan überhaupt keine Lösung ein.

Bin für jede Hilfe dankbar.
lg
j0Shi

  1. Hi,

    ich möchte im HTML-Code eine Javascript-Datei bzw. Javascript-Code einfügen ohne dass Zugriff per http auf diese Datei möglich ist.

    Also Beispielsweise eine .js-Datei per <script type="text/javascript" src="any.js"> einbinden, selbige soll aber nicht im Browser durch http://www.domain.de/any.js abruf- und einsehbar sein.
    Geht das?

    Nein.

    Als Lösung hatte ich mir überlegt, statt der .js-Datei z.B. eine .php-Datei einzubinden:

    <script type="text/javascript" src="js.php">
    In der js.php wird dann der Javascript-Code mit echo ausgegeben. Vorher wird in der index.php eine Konstante definiert, die in der js.php auf Existenz überprüft wird, ansonsten wird kein Javascript-Code ausgegeben. Das ganze funktioniert leider so nicht.

    Natuerlich nicht. Woher soll ein Script Kenntnis davon haben, ob in irgendeiner anderen, vollkommen unabhaengigen Scriptinstanz irgendwelche Konstanten definiert sind? (_So etwas_ koennte man ueber Sessions machen - aber fuer das, was du vorhast, taugt auch das nichts.)

    Es ist reichlich unsinnig Javascript-Code, der per HTTP abgerufen werden soll, vor dem Abruf durch HTTP schuetzen zu wollen - also tu dir selbst einen Gefallen, und vergiss diesen Unfug.

    [...] Bei der Firefox - Extension kommt erschwerend hinzu, dass ich dort nicht mit php arbeiten kann, das Sicherungssystem also komplett aus Javascript bestehen muss.

    Wenn du mal kurz ein wenig logisch nachdenkst, merkst du schnell, dass sich diese Katze selbst in den Schwanz beisst: Du willst Javascript-Code schuetzen - wenn du dafuer Javascript verwenden wuerdest, muesstest du dieses aber ebenfalls schuetzen (da sonst die Art des Schutzes erkenn- und damit aushebelbar waere) - und dieses dan wiederum, und wiederum ...

    Dazu fällt mir momentan überhaupt keine Lösung ein.

    Es gibt keine.

    MfG ChrisB

    1. Okay, kann ich wohl vergessen ...

      Ich finde das Problem allerdings relativ massiv. Ich habe eine Extension gecoded, die einfach gesprochen die URLs der besuchten Seiten in einer Datenbank speichert (Selbige werden mit Ajax an ein .php-Script weitergegeben, welches diese Aufgabe übernimmt). Da man Firefox-Extensions bzw. deren Quellcode in keinster Weise vor fremden Augen schützen kann, ist also mit wenigen Kenntnissen in JS, AJAX und XUL relativ schnell ermittelt, in welcher Form die URL an welches php-script weitergegeben wird. In diesem Beispiel wird einfach document.location.href weitergegeben. Überschreibt man diese Anweisung beispielsweise mit www.anypage.de wird statt der besuchten Seite immer www.anypage.de in die Datenbank geschrieben. Mit einer schönen for-Schleife ist es also auch möglich hunderte falscher Datensätze zu produzieren. Dieser Sicherheitslücke in Firefox-Extension bzw. Javascript finde ich immens, weil das defakto bedeutet, dass man Datenbanken in diesem Kontext garnicht benutzen oder die Extension zumindest nicht öffentlich bereitstellen kann.

      lg
      j0Shi

      1. Hallo,

        Ich finde das Problem allerdings relativ massiv.

        ich habe darin noch nie ein Problem gesehen, ganz im Gegenteil.
        Ich kann Deine Argumentation weder nachvollziehen noch verstehen.

        Ich habe eine Extension gecoded, die einfach gesprochen die URLs der besuchten Seiten in einer Datenbank speichert (Selbige werden mit Ajax an ein .php-Script weitergegeben, welches diese Aufgabe übernimmt). Da man Firefox-Extensions bzw. deren Quellcode in keinster Weise vor fremden Augen schützen kann, ist also mit wenigen Kenntnissen in JS, AJAX und XUL relativ schnell ermittelt, in welcher Form die URL an welches php-script weitergegeben wird.

        Wo ist nun das Problem?
        Ich installiere also eine Extension, die ich selbst konfigurieren kann,
        damit sie mein "Surfverhalten" aufzeichnet. Ich verstehe zwar nicht,
        welches Interesse man an einer solchen Extension haben könnte, aber das ist
        ja nicht das Thema ...

        In diesem Beispiel wird einfach document.location.href weitergegeben. Überschreibt man diese Anweisung beispielsweise mit www.anypage.de wird statt der besuchten Seite immer www.anypage.de in die Datenbank geschrieben.

        Nun, wo ist da das Problem?
        Wenn ich meine eigenen Aufzeichnungen manipulieren will, dann ist das meine Angelegenheit ...

        Mit einer schönen for-Schleife ist es also auch möglich hunderte falscher Datensätze zu produzieren. Dieser Sicherheitslücke in Firefox-Extension

        ... und keine Sicherheitslücke.

        bzw. Javascript finde ich immens, weil das defakto bedeutet, dass man Datenbanken in diesem Kontext garnicht benutzen oder die Extension zumindest nicht öffentlich bereitstellen kann.

        In welchem Kontext? Wozu ist das gut? Wenn ich es aufzeichnen will, dann
        nutze ich richtige Daten, wenn ich nicht aufzeichnen will, dann nutze ich
        keinesfalls eine mehr als zweifelhafte Extension.

        Könntest Du Dein Problem und Deine Sichtweise etwas besser erläutern, so
        dass auch ich das verstehen kann.

        Freundliche Grüße

        Vinzenz

        1. Ich glaube wir laufen hier grade in ein Mißverständnis ... Das Beispiel mit den URLs war auch nur ein solches. Meine Extension ist nicht dafür gedacht Surfverhalten für den Eigenbedarf aufzuzeichnen, funktioniert aber in einer ähnlichen Weise. Konkret geht es darum, von sog. Browsergames informationen zu extrahieren. Das ganze detailiert zu beschreiben würde etwas ausarten, aber es geht im Kern darum, von diesen Browsergame-Internetseiten Informationen in eine Datenbank zu schreiben, und diese der Allgemeinheit bereitzustellen. D.h. jeder der die Extension installiert hat und das Browsergame spielt, fügt automatisch Daten in eine zentrale Datenbank ein und kann auf diese zugreifen. Das wäre nicht weiter schlimm, denn es kann jeder nur auf die von ihm oder seiner Benutzergruppe eingefügten Daten zugreifen, d.h. wenn Manipulation erfolgt hat das nur Nachteile für ihn oder seine Benutzergruppe. Es ist aber so, dass jedes Browsergame eine "Landkarte" hat, die für alle Spieler gleich ist. Es empfiehlt sich daher, selbige in einer großen Datenbank zu speichern und die Zugriffsberechtigungen (nicht jeder kann auf alle Datensätze zugreifen, sondern nur auf selbige die er selber eingefügt hat) in einer zweiten Datenbank festzuhalten. Diese Landkarten-DB ist also für alle gleich, und alle greifen darauf zu, egal in welcher Benutzergruppe sie sind und welche Teile dieser Landkarte alle sehen dürfen. Mit den oben genannten Manipulationsmöglichkeiten ist es aber möglich diese Landkarte gewissermaßen zu zerschießen, also falsche Datensätze einzufügen. Da die Zugriffsberechtigungstabelle nur Verweise auf die Datensätze der Landkartentabelle enthällt, sind dann gleich für alle Benutzer die Datensätze falsch.

          Abhilfe würde hier nur schaffen, wenn man für jede Benutzergruppe eine eigene Landkarte erstellt, was aber eigentlich nicht sinnig ist, da diese Landkarte eh für alle gleich ist und sich nur in den Berechtigungen unterscheidet, auf welche Datensätze der Landkarte man zugreifen darf. Da so eine Landkarte zigtausend Datensätze vereint würde die Datenbank sehr schnell sehr gross und damit auch langsamer. Wenn das allerdings der einzig "sichere" Weg ist, müsste man es wohl so machen. Wobei sicher hier relativ ist, manipulieren kann man immer noch, aber man schadet damit nicht allen Usern, sondern nur der eigenen Benutzergruppe.

          lg
          j0Shi

          1. Hallo,

            Ich glaube wir laufen hier grade in ein Mißverständnis ...

            eh ja. Dennoch ist die von Dir vermutete Sicherheitslücke nicht existent.

            Du hast ein Problem nicht realisiert: "Jede Eingabe ist prinzipiell böse."
            Ob diese aus einer Extension oder sonstwie von einer Clienteingabe im
            Browsergame resultiert, das ist gleichgültig. Es ist Aufgabe der
            serverseitigen Prüfung, solche Daten, insbesondere solche, die "die Karte
            zerschießen können" auszusortieren.

            Freundliche Grüße

            Vinzenz

            1. Eine zufriedenstellende serverseitige Prüfung ist leider unmöglich. Sagen wir die "Landkarte" besteht aus einem Spielernamen in dem Browsergame, den Koordinaten auf der Landkarte, ggf. noch den Punkten im Browsergame usw. Es ist unmöglich festzustellen, ob z.B. der Spielername oder die Koordinaten überhaupt stimmen, weil diese Landkarte ständigen Veränderungen unterliegt, so dass man keine statische Vergleichstabelle erstellen kann. Stimmt der Spielername z.B. nicht mit den vorhandenen Datensätzen überein, könnte es auch einfach sein, dass der Spieler seinen Namen im Browsergame geändert hat usw.

              Evtl. gibt es für dieses Problem auch keine Lösung ...

              1. Hi,

                Eine zufriedenstellende serverseitige Prüfung ist leider unmöglich.

                das kommt darauf an, gegen was Du prüfen willst. Es ist mit entsprechender Vorbereitung beispielsweise alles andere als unmöglich, gegen den Faktor "legitimierter User" zu prüfen. Dazu muss sich der User lediglich legitimieren können.

                Cheatah

                --
                X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
                X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
                X-Will-Answer-Email: No
                X-Please-Search-Archive-First: Absolutely Yes
                1. Achso ... ja das wird gemacht. Man kann nur Daten in die Datenbank einfügen wenn man im System angemeldet ist. Das Problem ist, wenn man das System öffentlich zugänglich machen will, das heisst keine Prüfung mehr stattfindet wer sich anmelden darf, hilft die ganze Sache nichts mehr. Das artet dann evtl. nur dahingehend aus, dass man pausenlos Accounts löschen muss, die falsche Daten einfügen. Da wäre es doch besser, das von vornerein auszuschließen.

                  lg
                  j0Shi

                  1. Hi,

                    Achso ... ja das wird gemacht. Man kann nur Daten in die Datenbank einfügen wenn man im System angemeldet ist. Das Problem ist, wenn man das System öffentlich zugänglich machen will, das heisst keine Prüfung mehr stattfindet wer sich anmelden darf, hilft die ganze Sache nichts mehr.

                    so wie beispielsweise in einem anmeldepflichtigen Forum jeder Angemeldete stundenlang rumspammen kann.

                    Das artet dann evtl. nur dahingehend aus, dass man pausenlos Accounts löschen muss, die falsche Daten einfügen. Da wäre es doch besser, das von vornerein auszuschließen.

                    Auf welche Weise würdest Du obige Spam-Attacken verhindern?

                    Cheatah

                    --
                    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
                    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
                    X-Will-Answer-Email: No
                    X-Please-Search-Archive-First: Absolutely Yes
      2. Hi,

        Dieser Sicherheitslücke in Firefox-Extension bzw. Javascript finde ich immens,

        es ist keine Sicherheitslücke in Firefox oder JavaScript, sondern höchstens eine in HTTP. Da dieses Protokoll aber auf genau dem basiert, dass jeder jeden Request durchführen kann, den er durchführen will, ist ganz klar, dass der Empfänger zum Schutz verpflichtet ist. Wenn Du also eine Sicherheitslücke witterst, dann liegt sie zu 100% bei Dir.

        weil das defakto bedeutet, dass man Datenbanken in diesem Kontext garnicht benutzen oder die Extension zumindest nicht öffentlich bereitstellen kann.

        Wenn Du Deine Datenbasis nicht vor unlauteren Zugriffen schützen kannst, ist das richtig.

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
  2. Mahlzeit,

    Geht das?

    Nicht so einfach.

    Als Lösung hatte ich mir überlegt, statt der .js-Datei z.B. eine .php-Datei einzubinden:

    <script type="text/javascript" src="js.php">
    In der js.php wird dann der Javascript-Code mit echo ausgegeben. Vorher wird in der index.php eine Konstante definiert, die in der js.php auf Existenz überprüft wird, ansonsten wird kein Javascript-Code ausgegeben. Das ganze funktioniert leider so nicht. Muss ich in der js.php den Javascript - Code anders ausgeben als mit echo?

    Das funktioniert SO nicht. Schließlich wird die js.php vom Browser ganz normal per http abgerufen und weiß von irgendwelchen Variablen, die in irgendeiner anderen Datei definiert wurden, nichts. Eventuell könntest Du in der js.php den HTTP_REFERER überprüfen und den JavaScript-Code nur bei bei gültigen Werten für den Referrer ausgeben. Problem hierbei ist, dass nicht alle Browser einen (gültigen) HTTP_REFERER übergeben.

    Grundsätzlich gibt es für Dein Problem keine allgemeingültige, zufriedenstellende Lösung - eine Datei, die ein Browser per http abrufen können MUSS, kann genauso von jedem anderen Programm oder per Hand ("telnet foobar.example.org 80") per http angerufen werden.

    MfG,
    EKKi

    --
    sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|