Ankündigung

Einklappen
Keine Ankündigung bisher.

$_POST trotzdem escapen, wenn ich keinen Connect zur DB durchführe?

Einklappen

Neue Werbung 2019

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

  • $_POST trotzdem escapen, wenn ich keinen Connect zur DB durchführe?

    Hallo,

    muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?


  • #2
    Ja: CSRF. Und: Kommt drauf an, was du mit den Daten sonst so vor hast. Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.
    Standards - Best Practices - AwesomePHP - Guideline für WebApps

    Kommentar


    • #3
      Zitat von rkr Beitrag anzeigen
      Ja: CSRF. Und: Kommt drauf an, was du mit den Daten sonst so vor hast. Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.
      Danke.

      Kommentar


      • #4
        Zitat von Fuerst Rainer Beitrag anzeigen
        Hallo,

        muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?
        Definitiv nein!
        Escapen macht immer nur da Sinn, wo es gebraucht wird, was in Zeiten von prepared-Statements wohl nicht mehr viel sein wird.

        Escapen schadet wenn es um die Ausgabe von Daten geht sogar, da man dann die ganzen überflüssigen Slashes wieder entfernen muss und die für HTML relevaten Zeichen austauschen muss.
        mysql ist veraltet Mails senden: Ohne Probleme und ohne mail()
        PHP-Code:
        echo 'PS: <b>Meine Antwort ist keine Lösung, sondern nur eine Hilfe zur Lösung.</b>'

        Kommentar


        • #5
          Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.
          Irgendwie eine NULL-Aussage. Könnte man auch über ungeprüftes Trinkwasser sagen.

          Definitiv nein!
          Sehe ich auch so. Selbst wenn mit Escaping hier nicht addslashes gemein sein sollte - der Kontext bestimmt die Art der notwendigen Filterung, ergo kann man pauschal sowieso keine Sicherheit erzeugen.
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            Wie kann man das denn falsch verstehen?
            "Abhängig vom Nutzungskontext" heisst:
            - will ich damit eine Datenbankabfrage formulieren: Entsprechend escapen
            - will ich die Daten in HTML ausgeben: Entsprechend kodieren, damit kein XSS/CSRF möglich ist.
            - will ich die Daten in JSON-Form ausgeben...
            usw.

            Und nein, pauschal die $_POST-Daten zu escapen ohne zu wissen, was damit passieren soll, macht natürlich keinen Sinn.
            Standards - Best Practices - AwesomePHP - Guideline für WebApps

            Kommentar


            • #7
              Wie kann man dann auf:
              muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?
              mit Ja antworten?
              --

              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


              --

              Kommentar


              • #8
                Habs mehr als Metapher für zu verarbeitenden Userinput gesehen. Das gleiche gilt natürlich auch für alles, was via $_GET in den Kreislauf gelangt.
                An ein Vorgehen nach Vorbild von magic_quotes habe ich gar nicht gedacht
                Standards - Best Practices - AwesomePHP - Guideline für WebApps

                Kommentar


                • #9
                  Danke für die Kommentare, es hat mir weitergeholfen

                  Kommentar


                  • #10
                    Zitat von Fuerst Rainer Beitrag anzeigen
                    muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?
                    Die Antwort lautet: Du kannst es gar nicht ohne Verbindung.

                    (Sofern, wie schon angemerkt, ein Escaping im Sinne einer SQL Injection gemeint war)
                    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                    Kommentar


                    • #11
                      Zitat von rkr Beitrag anzeigen
                      Ja: CSRF
                      Kannst du das erläutern? Der Zusammenhang ist mir unbekannt.

                      Kommentar


                      • #12
                        Zitat von ChrisvA Beitrag anzeigen
                        Escapen macht immer nur da Sinn, wo es gebraucht wird, was in Zeiten von prepared-Statements wohl nicht mehr viel sein wird.
                        In Zeiten von prepared statements? Prepared statements sind nicht dazu gedacht dir das escapen zu ersparen, das ist ein Nebeneffekt davon das Query und Daten getrennt übertragen werden.

                        Kommentar


                        • #13
                          @monolith:

                          Wenn du als Angreifer Seiten HTML-/JS-Code hinzufügen kannst, weil deine Eingaben nicht passend escapet werden, kannst du im Namen der ahnungslosen Nutzer, die dann auf die präparierte Seite klicken, GET- und POST-Requests zu beliebigen Webseiten absetzen.

                          Wenn diese Webseiten zum Beispiel irgendwelche Dienste sind, bei denen ein Nutzer zufällig angemeldet und gerade eingeloggt ist, kannst du ihn durch passendes Gestalten des Requests dazu bringen, in seinem Namen unbewusst irgendeine Funktion auf der Zielseite auszulösen.

                          Beispiele finden sich etwa im Wikipedia-Artikel dazu: https://de.wikipedia.org/wiki/CSRF

                          Kommentar


                          • #14
                            Ok, danke für die Erläuterung. Mir war nicht klar, dass mit "escapen" in dem Fall auch der Umgang mit Benutzereingaben gemeint war. Klar, wenn mit denen nicht entsprechend umgegangen wird und ein <script>...</script> einfach so gespeichert und dann ausgegeben wird, kann man JS-Code einschleusen und dann scheinbar als ein User, der die entsprechende Seite aufruft, agieren.

                            Also auch nochmal für Fuerst Rainer, falls er hier nochmal hereinschaut: Angenommen auf einer Webseite können angemeldete User Kommentare schreiben. Dann sollte man z. B. diese mit htmlentities behandeln bevor sie gespeichert (oder angezeigt) werden. Denn wenn man das nicht macht und ein User als Kommentar angibt <script>alert(123)</script>, dann baut er damit JavaScript in seinen Kommentar ein. Ruft nun ein anderer User die Seite mit dem Kommentar auf, liest dessen Browser den JS-Code aus und führt ihn anschließend aus, sprich der User bekommt die 123-Message angezeigt. Das lässt sich natürlich noch weiter treiben, z. B. könnte man dann mit JS auch Aktionen ausführen wie dass der fremde User neue Kommentare postet oder noch schlimmer in einem Shop etwas kauft.

                            Allerdings: Das wäre dann ein XSS-Angriff und kein CSRF-Angriff. Das deutsche Wiki ist da irritierend, aber auf der englischen Seite heißt es: " Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser." (https://en.wikipedia.org/wiki/Cross-...equest_forgery) und außerdem "Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS" (https://en.wikipedia.org/wiki/Cross-site_scripting)

                            Kommentar


                            • #15
                              Ich weiß nicht genau, auf welches Beispiel du dich in deinem letzten Absatz beziehst, aber ich würde mich da glaube ich nicht zu sehr auf die Begriffe versteifen. Je länger ich darüber nachdenke, desto weniger trennscharf kommen die mir vor. (Vielleicht ändert sich das wieder, falls ich noch länger darüber nachdenken würde. ) Der zuletzt von dir zitierten Satz geht ja zum Beispiel auch noch weiter:

                              Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.
                              Aus Sicht der Kontextwechselproblematik ist der dort angesprochene Aspekt meines Erachtens ziemlich unbedeutend. Da kann man verallgemeinern und sagen, dass XSS und CSRF beides Angriffsarten sind, die durch unzureichendes Escaping ermöglicht werden können, indem JavaScript-Code eingeschleust wird.

                              Kommentar

                              Lädt...
                              X