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

  • #16
    Zitat von monolith Beitrag anzeigen
    Dann sollte man z. B. diese mit htmlentities behandeln bevor sie gespeichert (oder angezeigt) werden.
    Das ist exakt zu separieren. Wenn das ein reines Textfeld ist (was man beispielweise mit nl2br als HTML ausgibt) dürfen dort keine htmlentities rein, erst bei der Ausgabe in HTML werden die entsprechenden Zeichen gegen die Entities ersetzt. Wenn du nicht machst hast du kein reines Textfeld, sondern HTML oder gar eine Mischform. Das fällt dir dann auf die Füße wenn du die Daten anderes ausgeben willst, z.B. als Bild, PDF, CSV, Excel, über eine Schnittstelle usw...


    Zitat von mermshaus Beitrag anzeigen
    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. )
    Das ist sehr scharf von einander getrennt.
    XSS = Eingaben werden im Kontext der Seite ausgeführt
    PHP-Code:
    <script>alert('blub')</script> 
    = alert geht auf der Seite auf

    CSRF = Aktionen werden ungewollt ausgeführt
    PHP-Code:
    http://www.php.de/usercp.php?action=close_account 
    = wenn du den Link aufrufst ist dein Account gelöscht (könnt ich dir z.B. per Mail schicken)

    XSS + CSRF
    PHP-Code:
    <script>window.open('http://www.php.de/usercp.php?action=close_account')</script> 
    = dein Account ist automatisch weg

    Kommentar


    • #17
      hi Leute,

      für mich gibt es nur zwei Arten Userdaten zu behandeln.

      1. Userdaten in und aus der Datenbank (PDO/mySQLi): bindParam();
      2. Userdaten bei der Ausgabe/Anzeige: htmlspecialchars();

      3. html-mail, ftp-upload etc erstmal außen vor.

      Also behaupte ich jetzt mal als Anfänger, das eine $_REQUEST['Usereingabe'] die nichts mit einer Datenbank zu tun hat keine besondere Behandlung benötigt.

      Kommentar


      • #18
        Du widersprichst die gleich 2 mal

        für mich gibt es nur zwei Arten Userdaten zu behandeln.
        1.
        2.
        3.
        Also behaupte ich jetzt mal als Anfänger, das eine $_REQUEST['Usereingabe'] die nichts mit einer Datenbank zu tun hat keine besondere Behandlung benötigt.
        2. Userdaten bei der Ausgabe/Anzeige: htmlspecialchars();
        [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
        [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

        Kommentar


        • #19
          nö, 1 & 2 wenn es um Daten in und aus der Datenbank geht.

          eine $_REQUEST['Usereingabe'] die nichts mit einer Datenbank zu tun hat...
          Hier kommen die Daten nicht in oder aus der Datenbank, sondern werden in irgendeinem Formular hin und her geschubst

          Kommentar


          • #20
            Zitat von erc Beitrag anzeigen
            Das ist exakt zu separieren. Wenn das ein reines Textfeld ist (was man beispielweise mit nl2br als HTML ausgibt) dürfen dort keine htmlentities rein, erst bei der Ausgabe in HTML werden die entsprechenden Zeichen gegen die Entities ersetzt. Wenn du nicht machst hast du kein reines Textfeld, sondern HTML oder gar eine Mischform. Das fällt dir dann auf die Füße wenn du die Daten anderes ausgeben willst, z.B. als Bild, PDF, CSV, Excel, über eine Schnittstelle usw...
            Naja du kannst durchaus alles mit HTML-Entities speichern. Aber ja du hast natürlich recht, wenn man das dann anders als auf einer Webseite ausgeben will, muss man ggf. html_entity_decode benutzen oder sich sonstwie umd die HTML-Entities kümmern. Ich habe das mal so gemacht, inzwischen bin ich aber davon abgewichen.

            Kommentar


            • #21
              @erc: Vielleicht kann man sagen, dass der Code, der per XSS eingeschleust wird, Zeilen enthalten kann, die CSRF betreiben. Die Unschärfe in einer Abgrenzung auf gleicher Ebene besteht für mich dann darin, dass XSS eher eine allgemeine Technik benennt (sicher auch als „Synonym“ zu Code-Injection in HTML gebraucht), während CSRF eher einen Effekt benennt. Eine klare Zuordnung „JavaScript-Injection ist entweder XSS oder CSRF“ funktioniert für mich jedenfalls nicht.

              Edit: Ich denke, die beiden Begriffe sind sowieso schon unscharf definiert oder sagen wir: schwierig exakt zu definieren. Siehe etwa den Klammerzusatz oben zu „XSS“ oder auch die Tatsache, dass CSRF wohl auch für den trivialen Fall gebraucht wird, dass einfach Linkziele nicht zum verlinkten Text passen. Da passt dann auch die Beschreibung nicht mehr wirklich, dass eine Third-Party-Seite dem Browser des Nutzers vertraut, denn der Nutzer klickt das in dem Fall ja aktiv an. Da passt wohl besser die Aussage zu XSS, dass der Nutzer der Seite vertraut, auf der sich gerade befindet.

              Kommentar


              • #22
                Zitat von monolith Beitrag anzeigen
                Naja du kannst durchaus alles mit HTML-Entities speichern.
                Ja, man kann viel falsch machen. Daten die Weiterverabeitet werden, werden im Rohformat bzw. verarbeitbarer Form gespeichert. Da weder PHP noch die Datenbank HTML sprechen, ist HTML kein geeignetes Format dafür. Das Problem wird offensichterlich wenn du die Daten z.B. als Bild, als FlatDecode (PDF), Quotable-print oder irgendwas anderen exotischen speicherst. HTML kannst du auch so lesen und schreiben, die Probleme die sich bei der Weiterverarbeitung ergeben werden gar nicht wahrgenommen oder anderesseitig "gelöst". Würden deine Daten als Bild vorliegen (z.B. eine Mail-Adresse, ein Benutzername, eine Straßenname usw.) wären die Problem glasklar.
                -Lesen ohne die Anwendung nicht möglich (HTML kannst du auch als Text lesen und schreiben, ein Bild als Text/Hexadezimal dargestellt wird problematisch)
                -Sortierung (Bei Bildern wird das Problem sofort aufallen, die Sortierung ist "zufällig". Bei HTML fällt es erst bei Entities (z.B. Umlaute) auf, die stehen oben)
                -längen Begrenzungen der Felder stimmen nicht mehr
                -die Anwendungslogik muss auf das Datenformat ausgelegt werden


                @mermshaus irgendwie kann ich dir da nicht ganz folgen. XSS ist eingeschleuster Code (egal ob persistent oder flüchtig). Was der Code dabei macht, wie z.B. Inhalte modifizieren, Daten abgreifen (z.B. Formular eingaben), User weiterleiten, Browser Exploits ausführen, oder ebend Aktionen ausführen, ist irrelevant. Also: Eingeschleuster Code der im Browser ausgeführt/dargestellt wird = XSS.

                CSRF ist ein Angriff der darauf abzielt bestimmte Aktionen auf einer Website auszuführen. Im Idealfall ist das sowas eine Banküberweisung auf Konto XYZ . In der Praxis ist es dann aber eher sowas wie eine tweet bomb, die sich beim Aufruf über den Account des Aufrufser selbst weiter tweetet. Wie dieser Angriff technisch erfolgt ist aber nicht definiert, es geht nur darum das eine Aktion ausgeführt wird, die nicht vom User gewollt ist. Das geht z.B.
                -über XSS auf einer fremden Seite
                -über XSS auf der betreffenen Seite (gefährlich, da CSFR-Schutz ausgeheblet werden kann)
                -über ein "manipulierten" Link per Mail, Twitter, Facebook, ICQ, Skype usw.l
                -über Seiten die ein "manipulierten" Link als Bild einbinden. (<img src="http://www.php.de/usercp.php?action=close_account">)
                -über keine Ahnung, sei kreativ

                Kommentar


                • #23
                  Ich bezog mich halt auf den letzten Absatz in #14, bei dem ich das Gefühl hatte, dass da ein Gegensatz aufgemacht wird (siehe die Wikipedia-Zitate darin). Vielleicht habe ich das aber auch falsch interpretiert. Mein letzter Beitrag war dann auch noch so die „übliche“ Feststellung, dass solche „Allerweltsbegriffe“ nicht immer die klarste Semantik haben oder zumindest ein größeres Feld benennen oder dass im Gebrauch viel impliziert wird. Na ja, stating the obvious…

                  Kommentar


                  • #24
                    Zitat von erc Beitrag anzeigen
                    Ja, man kann viel falsch machen. Daten die Weiterverabeitet werden, werden im Rohformat bzw. verarbeitbarer Form gespeichert. Da weder PHP noch die Datenbank HTML sprechen, ist HTML kein geeignetes Format dafür. Das Problem wird offensichterlich wenn du die Daten z.B. als Bild, als FlatDecode (PDF), Quotable-print oder irgendwas anderen exotischen speicherst. HTML kannst du auch so lesen und schreiben, die Probleme die sich bei der Weiterverarbeitung ergeben werden gar nicht wahrgenommen oder anderesseitig "gelöst". Würden deine Daten als Bild vorliegen (z.B. eine Mail-Adresse, ein Benutzername, eine Straßenname usw.) wären die Problem glasklar.
                    Ja natürlich, du würdest das so machen:
                    PHP-Code:
                    $name htmlentities($_POST['name']);
                    $rawData$_POST['rawData']; 
                    Also nur Texteingaben entsprechend behandeln - aber wie gesagt ich bin davon inzwischen selber auch von abgewichen.

                    Kommentar


                    • #25
                      Danke allen für die Erläuterungen ... war wirklich sehr aufschlussreich

                      Kommentar

                      Lädt...
                      X