Ankündigung

Einklappen
Keine Ankündigung bisher.

PHPSESSID über URL ist ein sch**** Sicherheitsproblem!

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHPSESSID über URL ist ein sch**** Sicherheitsproblem!

    hi leute,

    also folgendes problem bei mir, wenn ich mich bei meinem script einlogge schicke ich an jede weitere datei die PHPSESSID über die url mit.

    damit identifiziere ich den user in der datenbank, die PHPSESSID wird temporär mitgespeichert und alles funktioniert einwandfrei.

    so weit so gut, aber wenn ich den link jemand schicke und er sich auch einloggt mit seinen daten kann er mit meinem link (in dem ja meine PHPSESSID ist) auf mein profil zugreifen und z.b. daten löschen, vorrausgesetzt er ist auch angemeldet.

    wie kann ich dieses problem umgehen?

  • #2
    Re: PHPSESSID über URL ist ein sch**** Sicherheitsproblem!

    Zitat von unknownsoul
    wie kann ich dieses problem umgehen?
    a. solche Links nicht weitergeben,
    b. Cookies verwenden

    Kommentar


    • #3
      c) an die IP-Adresse binden <- nicht immer zu empfehlen, stichwort Proxies
      d) mit zusätzlichen Informationen binden -> also User-Agent, accept_languages etc.
      e) mit referern arbeiten -> link ohne referer == neue session

      ...nur so als Ideen

      Kommentar


      • #4
        ich hab das problem mit sessions gelöst. ich glaub das ist nicht die schlechteste lösung.

        mfg
        topec

        Kommentar


        • #5
          Zitat von RealNexus
          c) an die IP-Adresse binden <- nicht immer zu empfehlen, stichwort Proxies
          d) mit zusätzlichen Informationen binden -> also User-Agent, accept_languages etc.
          e) mit referern arbeiten -> link ohne referer == neue session

          ...nur so als Ideen
          c) Problematisch
          d) Kann vom Client manipuliert werden
          e) Stichtwort Proxy Gibt auch Clients die das nicht sauber können

          Möglichkeit:

          ChallengeKeys, welche nur 1x gültig sind.

          Kommentar


          • #6
            > c) Problematisch
            problematisch nur bei AOL - der Load-Balancer bedient sich mehrerer Proxies
            amsonsten ist die Gefahr aus den "eigenen Reihen" natürlich sehr gross.

            > d) Kann vom Client manipuliert werden
            ja, klar. aber diese Informationen muss der "Angreifer" ebenfalls mitbekommen.

            > e) Stichtwort Proxy Gibt auch Clients die das nicht sauber können
            was? Proxy?

            > f) ChallengeKeys, welche nur 1x gültig sind.
            jaein... es gilt nur für Links die angeklickt wurden. Aber was ist mit den Links die Übertragen wurden (also in einer HTML-Seite) aber noch nicht angeklickt? die haben doch Ihre Gültigkeit. Was machst du, wenn jemand den Back-Button betätigt? Ausserdem würde es einen enormen Aufwand bedeuten, die Session-session-Keys zu verwalten.

            Kommentar


            • #7
              Maximale Sicherheit ohne SSL

              Code:
              session.use_cookies = 1, 
              session.use_only_cookies = 1, (<= keine Kekse - keine Arme)  
              session.use_trans_sid = 0, (<= keine Kekse - keine Arme)
              Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie in einer Session speichern, nur vom Benutzer gesehen werden können, der die Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die Integrität der Session ihrer Wichtigkeit entsprechend angemessen aktiv zu schützen.

              Schätzen Sie die Wichtigkeit der Daten ab, die in Ihren Sessions transportiert werden und treffen Sie zusätzliche Schutzmaßnahmen -- in der Regel bezahlen Sie dafür mit einer geringeren Benutzerfreundlichkeit. Wenn Sie z.B. Benutzer vor einfachen Social Engineering Tactics (Anm. des Übersetzers: Techniken der Ausnutzung menschlicher Schwächen) schützen wollen, müssen Sie session.use_only_cookies aktivieren. Cookies müssen dann benutzerseitig auf jeden Fall aktiviert sein, weil Sessions sonst nicht funktionieren.

              Es gibt mehrere Wege, über die eine Sessio-ID an Dritte gelangen kann. Eine entführte Session-ID ermöglicht diesen, auf alle Daten zuzugreifen, die mit dieser Session-ID verbunden sind. Erstens sind das URLs, die Session-IDs enthalten. Wenn Sie auf eine externe Site verweisen, könnte die URL inklusive Session-ID in den Referrer-Logs der externen Site gespeichert werden. Zweitens kann ein aktiverer Angreifer Ihren Netzwerkverkehr abhören. Falls Ihr Netzwerkverkehr nicht verschlüsselt ist, werden Session-IDs im Klartext über das Netzwerk übertragen. Hier ist die Lösung, auf Ihrem Server SSL zu implementieren und die Verwendung für Ihre Benutzer obligatorisch zu machen.

              Quelle: http://www.php.net/manual/de/ref.session.php
              Wenn man den Zugriff über Session-Cookie begrenzt
              sollte auch für eine 'client'seitige Fehlermeldung bei gesperrten Cookies gesorgt sein.

              Wie sowas geht http://www.dclp-faq.de/q/q-sessions-cookie.html

              Kommentar


              • #8
                > Maximale Sicherheit ohne SSL
                Nein, leider falsch. Cookies schützen zwar vor Kopieren der URLs - sie schützen jedoch nicht davor, eine Session zu übernehmen wenn jemand in der Lage ist, den Verkehr abzuhören oder zugriff auf den Proxy besitzt. In beiden Fällen werden Cookies in Plaintext übertragen - der Schutz gegen Wiedereinspielen ist also hier auch nicht vorhanden. Du musst also gezwungenermassen, mit dem Arbeiten was du hast. Also die Informationen die du von dem Client bekommst.
                Das einzige was hilft, ist tatsächlich nur SSL mit Cookie-Session-Handling...

                Kommentar


                • #9
                  > Maximale Sicherheit ohne SSL
                  Nein, leider falsch.
                  Ähm

                  Nichts ist ohne SSL sicher im WEB

                  Da hast Du mich wohl mißverstanden, ich wollte nicht sagen dass man sich mit oben gezeigtem Vorgehen einen SSL erspart.

                  Steht ja auch deutlich im TEXT

                  Kommentar


                  • #10
                    Ok. SSL ist eigentlich die einzigste Sinnvolle Möglichkeit. Alles andere sind Klimmzüge, welche auch nur wenig Erfolg haben.

                    Am besten zu einem Anbieter wie HostEurope wechseln, die selbst bei den billigen Webspaces schon SSL-Proxys anbieten.

                    Kommentar


                    • #11
                      hi, danke erstmal für alle antworten.

                      an cookies hab ich schon gedacht, aber die seite soll ja auch ohne cookies einwandfrei laufen und da muss ich die session_id ja über die url übertragen.

                      ssl wäre ne lösung, dachte aber auch an eine ohne ssl

                      ich hab aber mal noch eine frage zu sessions, wenn ich eine variable registriere z.b die ID des users

                      Code:
                      <?php
                        session_register("user_id");
                      ?>
                      wie wird dieser wert übertragen? über die session_id doch nicht, wie funktioniert diese übertragung.

                      beschäftige mich erst seit kurzem mit sessions

                      Kommentar


                      • #12
                        ...wie wird dieser wert übertragen? über die session_id doch nicht, wie funktioniert diese übertragung...
                        session_register http://de.php.net/manual/de/function...n-register.php

                        Keine Session-Variable wird übertragen es wird lediglich die SessionID übertragen. D.h. der Server empfängt die SessionID entweder als $_COOKIE oder $_REQUEST -Variable.

                        http://www.dclp-faq.de/q/q-sessions-dateisystem.html

                        Kommentar


                        • #13
                          BOAR

                          was habt ihr alles für krass geheime infos :wink:
                          in realnexus sig stehts schon:
                          Es gibt keine Sicherheit,
                          nur verschiedene Grade der Unsicherheit


                          wenn ihr internet banking anbieten würdet dann währe das schon doof aber dann würdet ihr nicht in diesem forum eure fragen stellen!
                          klar sind sessions nicht 100%ig sicher aber was will man machen?
                          die sessid muss irgentwie mitgesendet werden d.h. der user muss die sessid an den host schicken!

                          das beste ist wenn man die sessid an die ip bindet, sollte jemand irgentwelche sicherheitsmassnahmen haben wodurch dies nicht funktioniert dann hat er eben pech gehabt, oder sind die seiten die ihr macht auf 50 browser abgestimmt? bestimmt nicht! man kann nicht jeden fall abdecken, man kann nur die breite masse abdecken und das ist mit sessions sehr gut möglich! außerdem ist jeder der cookies dekativiert selber schuld! wenn alles genauso gut ohne cooklies möglich währe wie mit dann bräuchte man keine cookies! wenn das dem user nicht klar ist hätte er sich lieber erstma über cookies informieren sollen bevor er sie deaktiviert!

                          Kommentar


                          • #14
                            das beste ist wenn man die sessid an die ip bindet
                            Das würde ich mal lassen

                            http://www.dclp-faq.de/q/q-sessions-ip.html

                            Kommentar


                            • #15
                              Zitat von ulle
                              das beste ist wenn man die sessid an die ip bindet
                              Das würde ich mal lassen

                              http://www.dclp-faq.de/q/q-sessions-ip.html
                              Ich versteh irgendwie das Problem nicht. Man macht ja nicht aus oder mit der IP die SESSID, sondern fragt nur zusätzlich die IP ab.
                              Somit ist das Problem mit dem weitergeben von Links keins mehr, weil ja nicht gleichzeitig 2 Benutzer am PC arbeiten können (?).

                              Sollte die IP tatsächlich während einer Sitzung wecheseln, muss sich der Benutzer neu einloggen, was ja kein Problem darstellen sollte (es sei denn die IP wecheselt alle 2min ).

                              Kommentar

                              Lädt...
                              X