Enrico: Wie JavaScript-Variable an eingebundene PHP-Datei übergeben?

Hallo,

ich grüble gerade darüber, wie ich den Wert einer JavaScript-Variablen an eine PHP-Session übergeben kann.

Ich binde in die Datei "index.php" die Datei "PHP/Session.php" ein.

Die Session.php enthält ein eigenes Session-Handling, das u.a. die Variable $_SESSION['_fingerprint'] als Kombination aus dem User-Agent und der IP-Adresse definiert.

Da der User-Agent recht leicht manipuliert werden kann und IP-Adressen, meines Wissensstandes nach, nie 100% eindeutig sind, habe ich einen JavaScript-Mechanismus zusammengestellt, der u.a. verschiedene Werte des Browsers ausliest, unterstützte Mime-Typen ermittelt und einen eigenen Fingerabdruck über Canvas erzeugt. Aus den ermittelten Werten wird der finale SHA512-verschlüsselter Fingerabdruck generiert.

Mein Problem ist nun, wie ich es anstelle, dass der JavaScript-Fingerabdruck an die Variable $_SESSION['_fingerprint'] in der Session.php übergeben wird.

Habt ihr eine Idee, wie ich das anstellen könnte?

Vielen Dank für eure Hilfe und Gruß,
Enrico

  1. Aloha ;)

    Mein Problem ist nun, wie ich es anstelle, dass der JavaScript-Fingerabdruck an die Variable $_SESSION['_fingerprint'] in der Session.php übergeben wird.

    Habt ihr eine Idee, wie ich das anstellen könnte?

    Hm, per AJAX (XML-HTTP-Request) zum Beispiel? Die Zuordnung der gesendeten Daten zu einer bestimmten Person kannst du über die Session realisieren. Imho müsste die Session bei XML-HTTP-Request verfügbar sein.

    Grüße,

    RIDER

    --
    Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
    ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
    1. Servus RIDER,

      danke für Deine Antwort.

      Vielleicht bin ich ja bzgl. meiner Denkweise noch auf irgendeinem Holzweg, aber AJAX selber läuft ja wieder über JavaScript ab, ich brauche aber eine Möglichkeit, aus der Session.php heraus den JavaScript-Fingerprint zu bekommen.

      Gruß,
      Enrico

      1. Aloha ;)

        Vielleicht bin ich ja bzgl. meiner Denkweise noch auf irgendeinem Holzweg, aber AJAX selber läuft ja wieder über JavaScript ab, ich brauche aber eine Möglichkeit, aus der Session.php heraus den JavaScript-Fingerprint zu bekommen.

        Bin mir auch nicht ganz sicher ob ich was das Problem angeht vollends durchgestiegen bin. Du solltest in der Lage sein, den Fingerprint, der per AJAX an den Server geht, eindeutig der Session-ID zuzuordnen und dann abzuspeichern. Dann kannst du später in der Session.php darauf zugreifen.

        Falls das nicht geht (wie gesagt, mir ist das Problem nur grob klar): Vielleicht kannst du ja Cookies verwenden? Die lassen sich von JavaScript und PHP lesenSetzensetzen.

        Grüße,

        RIDER

        --
        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
        ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
        1. Die lassen sich von JavaScript und PHP lesenSetzensetzen.

          Lesen und setzen. Fuck off, Android...

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
      2. Vielleicht bin ich ja bzgl. meiner Denkweise noch auf irgendeinem Holzweg, aber AJAX selber läuft ja wieder über JavaScript ab, ich brauche aber eine Möglichkeit, aus der Session.php heraus den JavaScript-Fingerprint zu bekommen.

        Ob AJAX oder nicht sei jetzt mal dahin gestellt, die üblichen Wege Daten vom Client zum Server zu übermitteln sind GET und POST, in PHP erreichst du diese dann per $_GET- oder $_POST-Array.

        Dein PHP-Script muss dann den generierten Fingerprint nur noch in die Session stopfen.

        Ob du mit Javascript den Browser die Seite komplett neu laden lässt und den Fingerprint in den Querystring einbaust, ein Formular mit dem Fingerprint abschickst (was auch zum neuladen der Seite führt), oder du per AJAX den Fingerprint erstellst, sei dann dir überlassen, wobei AJAX wohl die benutzerfreundlichste Variante wäre.

        Wenn du den Fingerprint bei jedem Seitenaufruf dann überprüfen willst, wird die Sache noch ein wenig komplizierter, da du bei jedem Link und jedem Formular den Fingerprint mit unterbringen musst.

        Allerdings hast du mit deinem Fingerprint generell ein Problem wenn Javascript ausgeschalten ist, ich kenn allerdings die Zielgruppe/den Anwendungsfall nicht.

        PS: Den UA-String zu ändern ist eigentlich ziemlich leicht.

        MfG
        bubble

        --
        If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
  2. Hi there,

    Die Session.php enthält ein eigenes Session-Handling, das u.a. die Variable $_SESSION['_fingerprint'] als Kombination aus dem User-Agent und der IP-Adresse definiert.

    Gibts einen (sehr) guten Grund für ein "eigenes" Session-Handling? Im Grunde genommen erledigt das alles PHP für Dich, und es ist keine wirklich gute Idee, ein serverseitiges "Problem" mit Javascript lösen zu wollen.

    Da der User-Agent recht leicht manipuliert werden kann und IP-Adressen, meines Wissensstandes nach, nie 100% eindeutig sind, habe ich einen JavaScript-Mechanismus zusammengestellt, der u.a. verschiedene Werte des Browsers ausliest, unterstützte Mime-Typen ermittelt und einen eigenen Fingerabdruck über Canvas erzeugt. Aus den ermittelten Werten wird der finale SHA512-verschlüsselter Fingerabdruck generiert.

    Ich gratuliere, Du hast gerade das Cookie neu erfunden...!

  3. hi,

    von JS zum Server, das gibt es untenstehende Möglichkeiten:

    1. Ajax-Request,
    2. Formularelemente werden verändert,
    3. Links im Dokument werden verändert.

    (1) kann infolge beliebiger Events erfolgen, bei (2) muß der Benutzer ein Submit machen und bei (3) musser auf einen Link klicken.

    MfG

  4. Habt ihr eine Idee, wie ich das anstellen könnte?

    Du könntest einfach eine Pseudografik laden und den Fingerprint an die URL anhängen und in PHP per GET abfragen:

    pseudografik.src = "session.php?fingerprint=" + fingerprint;

    Viel Erfolg

    1. Aloha ;)

      Die Idee gefällt mir. Ist auch etwas unauffälliger als ein AJAX dient also der Verschleierung interner Mechanismen. Und kann dank Javascript dynamisch eingesetzt werden, bei einer 1px Pseudografik ist das Ding sofort geladen und kann danach fast spurlos wieder entfernt werden, während AJAXe in den meisten Entwicklertools viel prominenter gelistet werden als Aufrufe von Ressourcen wie Bilddateien...

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
      1. […] während AJAXe in den meisten Entwicklertools viel prominenter gelistet werden als Aufrufe von Ressourcen wie Bilddateien...

        Das macht keinen Unterschied zu geladenen Grafiken. Im Gegenteil, wen du nicht wirklich eine Grafik auslieferst, wird das ganze noch aufälliger für jemanden der dahinter steigen will.

        Und wenn jemand wirklich hinter dein System dahinter steigen will ...  Im Endeffekt läuft ein Script auf Serverseite ab ... ob da num als Antwort ein Bild rauskommt oder nichts oder irgendein Text, das auffälligste wird sein, dass du den Fingerprint generierst. Und was mit dem geschieht ist mit dem guten alten Debugging nicht schwer.

        Die eigentliche Frage stellt sich doch, was du mit diesem Fingerprint erreichen willst?

        Mit (wahrscheinlich) jedem Browser kann man alle Anfragen/Antworten sehen, also ist dein Fingerprint auch nicht wirklich hilfreich, einmal rausgefunden, dass dieser Fingerprint existiert und er nur anhand der Fähigkeiten des Browsers generiert wird, lässt einen ganz schnell mal nen Bot oder vor was auch immer du den Server damit schützen willst sabotieren.

        Clientseitige "Ermittungen" sind genause zu handhaben wie sämtliche Forulardaten, etc. Sie sind böse, bedürfen einer Validierung und einer kontextgerechtem Maskierung im Sinne der Weiterverarbeitung.

        MfG
        bubble

        --
        If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
        1. Ich bin grad recht betrunken, ich werd falls Antworten darauf Fragen aufwerfen diverse Teile noch mal neu formulieren >.<

          MfG
          bubble

          --
          If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
        2. Aloha ;)

          Und wenn jemand wirklich hinter dein System dahinter steigen will ...  Im Endeffekt läuft ein Script auf Serverseite ab ... ob da num als Antwort ein Bild rauskommt oder nichts oder irgendein Text, das auffälligste wird sein, dass du den Fingerprint generierst. Und was mit dem geschieht ist mit dem guten alten Debugging nicht schwer.

          Ich gebe dir recht. Ich wollte damit auch nicht suggerieren, dass eine tatsächliche Sicherheit entsteht. Ich spreche schließlich nur von einer Verschleierung. Z.B. listet der Firebug imho AJAX standardmäßig in der Konsole, das Nachladen von Grafiken aber nicht. Ich zumindest stehe dazu genauso wie neulich. Auch Verschleierung, sei sie auch noch so klein, ist nützlich.

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
          1. ... Ich spreche schließlich nur von einer Verschleierung. Z.B. listet der Firebug imho AJAX standardmäßig in der Konsole, das Nachladen von Grafiken aber nicht.

            Hmm, Firebug hab ich nicht mal mehr installiert.
            Aber die Konosole von Firefox 36.01a liefert mir auf jeden Fall die Bilder und sämtliche andere Requests:
            Firefox - Requestliste in der Konsole

            Ich zumindest stehe dazu genauso wie neulich. Auch Verschleierung, sei sie auch noch so klein, ist nützlich.

            Ich stimme dir zu das es nützlich sein kann, aber ohne Anwendungsfall ist das schwer zu beurteilen.

            MfG
            bubble

            --
            If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
  5. Hallo,

    ich gehe jetzt einen anderen Weg und setze mein Vorhaben über AJAX um.

    Und hier tut sich ein neues Problem auf:
    Zerstört location.replace $_POST-oder/und Session-Variablen?

    Wenn ja, dann muss ich einen neuen Weg finden, das Zurücknavigieren zu unterbinden und wenn ja, dann steht eine Fehlersuche an ^^

    Gruß,
    Enrico

    1. Hi,

      Zerstört location.replace $_POST-oder/und Session-Variablen?

      denke logisch: location.replace() ist Javascript, läuft clientseitig. Die Folge dieser Anweisung ist, dass ein neues Dokument vom Server angefordert wird. Also ein neuer Request. Und zwar per GET.

      In diesem neuen Request gibt es also keine $_POST-Daten. Die Session-Daten sollte der serverseitige Prozess aber noch zur Verfügung haben,denn die Session ID wird meistens per Cookie übertragen, und das Cookie wird beim Folgerequest automatisch wieder zum Server übermittelt.

      Wenn ja, dann muss ich einen neuen Weg finden, das Zurücknavigieren zu unterbinden

      Das ist der falsche Weg. Du solltest eher ein Konzept finden, bei dem das Zurück-Navigieren ohne Probleme möglich ist.

      So long,
       Martin

      --
      Chef:         Zum vierten Mal in dieser Woche erwische ich Sie nun schon beim Zuspätkommen. Was haben Sie dazu zu sagen?
      Angestellter: Dann muss heute Donnerstag sein.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Servus Martin,

        ok, danke schon mal.

        Dann werde ich mich später um die Umsetzung Deiner Tipps kümmern und es mit "get" probieren und auch bzgl. des Zurücknavigierens umdenken.

        Gruß,
        Enrico

    2. Hallo,

      jetzt klappt's! Dummerweise zusätzlich ein session_start() vergessen.

      Danke euch allen! :-)

      Gruß,
      Enrico

  6. Tach!

    So ein Browser-Fingerabdruck ist rechtlich nicht unbedenklich.

    Aktuelle Heise-News: EU-Datenschützer warnen vor Tracking mit "digitalem Fingerabdruck"

    Einleitungstext: Wer Cookie-Ersatztechniken wie "digitales Fingerprinting" zum Verfolgen von Nutzern im Web einsetzt, muss dazu in der Regel die Erlaubnis der Betroffenen einholen. Dies hat die Artikel-29-Datenschutzgruppe klargestellt.

    dedlfix.

    1. Hallo dedlfix,

      muss dazu in der Regel die Erlaubnis der Betroffenen einholen

      Oha. Hmm, dann werde ich da lieber einen so zufälligen String wie möglich erzeugen, bevor ich da in rechtlich unsicheren Gewässern fische.

      Danke für den Hinweis!

      Gruß,
      Enrico