Ankündigung

Einklappen
Keine Ankündigung bisher.

Ganz allgemeine Sicherheitsfrage(n)

Einklappen

Neue Werbung 2019

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

  • Ganz allgemeine Sicherheitsfrage(n)

    Hi zusammen.

    Ich versuche hier mal den Sicherheitsaspekt einer Webanwendung von einer anderen Seite zu hinterfragen und hoffe sehr auf ein paar brauchbare Vorschläge, vor allem von unseren erfahrenen Usern...

    Mich interessieren vor allem die Schlagworte zu dem jeweiligen Sicherheitsrisiko und weniger die Techniken dahinter, die kann man ja relativ einfach durch dieses Forum oder über google in Erfahrung bringen.

    1. Ein Inputfeld absichern, wenn der Inhalt danach wieder als HTML ausgegeben wird.

    2. Ein Inputfeld absichern, wenn der Inhalt danach in eine DB geschrieben wird.

    3. Eine Selectabfrage an eine DB, das zu suchende Schlüsselwort kommt von einem Inputfeld.

    4. Eine Selectabfrage an eine DB, das zu suchende Schlüsselwort kommt aus dem eigenen Script.

    5. Ein Insertbefehl an eine DB, die/der einzutragende(n) Wert(e) kommen aus einem Inputfeld.

    6. Ein Insertbefehl an eine DB, die/der einzutragende(n) Wert(e) kommen aus dem eigenen Script.

    7. Die HTML-Ausgabe einer Selectabfrage an eine DB.

    8. Absicherung per GET übertragener Werte.

    Bin sehr gespannt, was für Begriffe fallen.

    Danke und Grüße

  • #2
    Allgemein sind das alles Kontextwechsel.

    - http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel

    1, 7) htmlspecialchars, XSS (Cross-Site-Scripting) → http://php-de.github.io/jumpto/cross-site-scripting/
    2, 3, 4, 5, 6) mysqli_real_escape_string/PDO::quote/Prepared Statements/…, SQL-Injections → http://php-de.github.io/jumpto/sql-injection/
    8) Allgemein gibt es da nichts. Wichtig ist, dass du die Werte bei der Weiterverarbeitung dem jeweiligen Kontext entsprechend behandelst.

    Wenn du verstanden hast, was bei einem Kontextwechsel warum zu beachten ist, werden viele konkrete Umsetzungen glaube ich sehr einfach logisch nachvollziehbar.

    Kommentar


    • #3
      Uhm jo...
      Generelle Regeln zum Umgang mit Userinput:
      Ausgabe: htmlentities / htmlspecialchars
      Speichern in die Datenbank: API-Funktionen zum Escapen / Prepared Statements

      4. Eine Selectabfrage an eine DB, das zu suchende Schlüsselwort kommt aus dem eigenen Script.
      6. Ein Insertbefehl an eine DB, die/der einzutragende(n) Wert(e) kommen aus dem eigenen Script.
      Z.B. wenn du einen Timestamp speicherst?
      Wenn du wirklich nur 'eigene' Daten speicherst, solltest du dir um Sicherheit eh keine Gedanken machen*, die Daten kommen ja nicht von draußen..
      Sobald User-Input mit in der Query steckt greif ich zu Prepared Statements -> Escapes, Quotes

      8. Absicherung per GET übertragener Werte.
      Wie meinst du das?
      Evtl. Validierung? Prüfen ob die Werte realistisch sind, ob sie den Erwartungen von Typ und Wert entsprechen. Evtl. eine Whitelist führen.

      Stichworte: Escaping, Validation, Quoting

      edit: dayumn, hab mir ja richtig Zeit gelassen beim Schreiben :<

      * Will niemandem seine Mündigkeit absprechen seine eigene Applikation zu killen.
      [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


      • #4
        Hier noch allgemeiner Lesestoff dazu - Teilseiten davon hat mermshaus oben ja schon verlinkt. Die kannst du dir ja auch mal durchlesen:

        Themen-Überblick: http://php-de.github.io/#security
        Formularsicherheit: http://php-de.github.io/jumpto/sicherheit/

        LG
        The string "()()" is not palindrom but the String "())(" is.

        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
        PHP.de Wissenssammlung | Kein Support per PN

        Kommentar


        • #5
          Zitat von VPh Beitrag anzeigen
          Wenn du wirklich nur 'eigene' Daten speicherst, solltest du dir um Sicherheit eh keine Gedanken machen*, die Daten kommen ja nicht von draußen..
          Nur, um es noch mal betont zu haben: Kontextwechsel einfach immer korrekt durchführen – egal, woher die Daten kommen. „Hier kann ja nichts passieren, denn ich weiß ja, was ich da mache“ ist eine viel zu komplizierte Überlegung. Es ist viel einfacher und zukunftssicherer und flexibler, trotzdem schnell eine entsprechende Funktion auf den Inhalt anzuwenden.

          Kommentar


          • #6
            @alle vielen Dank für die tollen Links, die Seite kannte ich noch nicht und macht echt Spaß

            @VPh ja, ich dachte an eine Art Plausibilitätsprüfung.

            Einen wichtigen Punkt habe ich noch vergessen oben:

            Was macht ihr beispielsweise mit einem Passwort, dass aus einem Inputfeld stammt, um den Login zu prüfen. Dieses gelangt weder in die DB, noch wird es irgendwie als HTML ausgegeben, es findet nur ein Vergleich mit dem Passwort aus der DB statt und gibt mir den entsprechenden Boolean zurück.

            Escapen muss ich es ja eigentlich nicht, da es nie Teil einer Query wird und nicht in die DB kommt und XSS-Schutz ist doch dann auch nicht nötig, da es ja auch nicht angezeigt wird. Versteh ich das so richtig?

            Danke und Grüße

            Kommentar


            • #7
              Ja.

              Kommentar


              • #8
                Wenn du wirklich nur 'eigene' Daten speicherst, solltest du dir um Sicherheit eh keine Gedanken machen*, die Daten kommen ja nicht von draußen..
                Das ist falsch.

                Die Frage Kontextwechsel adressiert nicht primär eine Sicherheitsfrage, sondern die Problematik von Syntaxüberschneidungen. SQL-Injection ist nur ein Symptom davon.

                Habe ich in meiner Datenbank ein "O'Neill" stehen, lese es aus und packe es wieder in ein INSERT, entsteht trotzdem ein Fehler innerhalb der "falschen" Stringbegrenzer. Escaping/Prepared Statements sind also immer unabdingbar, genau das selbe gilt für HTML-Maskierung und Co.
                [COLOR="#F5F5FF"]--[/COLOR]
                [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                [COLOR="#F5F5FF"]
                --[/COLOR]

                Kommentar


                • #9
                  @nikosch, klingt sehr logisch, aber wie verhält es sich denn dann bei meiner unter #6 ergänzten Frage. mermhaus bestätigt, man müsste in diesem Fall nicht weiter escapen/maskieren, du schreibst aber, es ist immer unabdingbar. Bin verwirrt^^

                  Kommentar


                  • #10
                    Immer, wenn du einen Kontextwechsel hast, muss der mit entsprechendem Escaping beachtet werden.[1]

                    Immer, wenn du keinen Kontextwechsel hast, muss der nicht beachtet werden.



                    1: Es gibt dann so Überlegungen wie: „Diese Variable hier symbolisiert ein Alter. Weil ich die Daten selbst in die DB eintrage, weiß ich sicher, dass das immer eine Zahl ist. Also brauche ich an der Stelle bei Ausgabe in einem HTML-Dokument nicht zu escapen, denn da kann ja nichts passieren. Das sind ja alles Ziffern.“ Und das ist genau kritisch zu sehen, weil das viel zu kompliziert ist und weil Anwendungen auch manchmal umgeschrieben werden und dann nicht mehr die Daten aus der DB beziehen oder so. Deshalb: Bei einem Kontextwechsel immer korrektes Escaping durchführen und sich nicht damit aufhalten, Gründe zu suchen, warum man es jetzt an der einen Stelle unter bestimmten Bedingungen mal nicht tun muss.

                    Kommentar


                    • #11
                      Wenn du vollautomatisch arbeiten willst, kannst du eine Template Engine wie Twig verwenden, bei der Autoescaping von Haus aus aktiviert ist. Dann musst du dich nicht ständig wiederholen.

                      Kommentar


                      • #12
                        vielen Dank @alle!

                        Kommentar


                        • #13
                          Zitat von michiman Beitrag anzeigen
                          @alle vielen Dank für die tollen Links, die Seite kannte ich noch nicht und macht echt Spaß

                          @VPh ja, ich dachte an eine Art Plausibilitätsprüfung.

                          Einen wichtigen Punkt habe ich noch vergessen oben:

                          Was macht ihr beispielsweise mit einem Passwort, dass aus einem Inputfeld stammt, um den Login zu prüfen. Dieses gelangt weder in die DB, noch wird es irgendwie als HTML ausgegeben, es findet nur ein Vergleich mit dem Passwort aus der DB statt und gibt mir den entsprechenden Boolean zurück.

                          Escapen muss ich es ja eigentlich nicht, da es nie Teil einer Query wird und nicht in die DB kommt und XSS-Schutz ist doch dann auch nicht nötig, da es ja auch nicht angezeigt wird. Versteh ich das so richtig?

                          Danke und Grüße
                          Passwörter sollten allerdings gehasht werden. php bietet da 2 ganz tolle Funktionen

                          http://php.net/manual/de/function.password-hash.php
                          http://php.net/manual/de/function.password-verify.php

                          den hash speicherst du in der Datenbank
                          Fatal Error: Windows wird gestartet

                          Wie administriert man ein Netzwerk: Beispiel

                          Kommentar


                          • #14
                            Dazu der Vollständigkeit halber noch etwas ganz interessanten Lesestoff:
                            Sicheres Passwort-Hashing: http://php.net/manual/de/faq.passwords.php

                            LG
                            The string "()()" is not palindrom but the String "())(" is.

                            Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                            PHP.de Wissenssammlung | Kein Support per PN

                            Kommentar

                            Lädt...
                            X