Ankündigung

Einklappen
Keine Ankündigung bisher.

Sicherheit in PHP

Einklappen

Neue Werbung 2019

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

  • Sicherheit in PHP

    Hallo

    mal ne allgemeine Frage. Was sollte alles unternommen werden um PHP Sicherheitslücken zu schliessen. Wie zb SQL Injection.
    Ich denke es wäre für viele Anfänger sinnvoll wenn wir hier so ein Sicherheitsthema hätten wo alle wichtigen Sachen zum Thema Sicherheit steht. Ich hab versucht über die Suche was zu finden. Aber nicht viel gefunden. Auch über Google nicht gross.

    Einzigste was ich weiss ich SQL Injection. Aber wie genau sollte das angewendet werden.

    Zb bei den $_GET und $_POST
    mysql_real_escape_string(strip_tags($_GET['id']));
    mysql_real_escape_string(strip_tags($_POST['id']));

    Ist das so richtig?
    Was ist mit?

    = trim($_POST["provider"]);
    = (int) trim($_GET["id"]);

    Was sollte man sonst noch alles unternehmen für die Sicherheit?

    Wäre sicherlich für viele hier hilfreich

  • #2
    Oje, das ist ein sehr weit gefächertes Thema. Ich denke mal, dass man dazu ganze Foren vollschreiben könnte.
    An dieser Stelle empfehle ich dir einfach mal ein Buch darüber und hoffe, dass das nicht als Werbung gewertet wird.
    dpunkt.verlag | Bücher
    Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

    Kommentar


    • #3
      Ob das Thema nun lang oder Kurz ist ich denke das wichtigste könnte hier doch zusammengetragen werden so dass gerade wir Anfänger von Anfang an die wichtigsten Sachen mit einbauen können. Mir gehts gerade so dass ich ein script komplett fertig gebaut habe und nun werde ich wohl einiges abändern müssen

      Kommentar


      • #4
        Grundsätzlich gilt: alles, was als Eingabe kommt, ist Schadcode, bis das Gegenteil angenommen werden kann

        ALLE zu verarbeitenden Variablen prüfen

        bereits geprüfte Variablen müssen nach einem Include (o.ä.) erneut geprüft werden, wenn sie dort verwendet werden

        direkte Verwendung von durch $_GET und Konsorten übergebenen Variablen immer vermeiden, also NICHT einfach:
        PHP-Code:
         include($_GET['includefile']); 

        Kommentar


        • #5
          Mit dem folgenden kleinen Script am Anfang deiner Datei stellst du sehr gute "Säuberer" zur Verfügung.

          PHP-Code:
          function array_htmlentities( &$var )
          {
            if( 
          is_string$var ) )
            {
              
          $var htmlentitiesstrip_tags$var ) );
            }
            else
            {
              if( 
          is_array$var ) )
              {
                foreach( 
          $var as $key => $value )
                  
          array_htmlentities$var[$key] );
              }
            }

          Dort wo du die Funktion brauchst kannst du sie dann aufrufen. Bsp.:
          PHP-Code:
          array_htmlentities($_GET
          Wenn du natürlich auch Quellcode oder formatierte Texte durchlassen willst brauchst du weitreichendere Prüfungsfunktionen.

          Kommentar


          • #6
            Zitat von robydog Beitrag anzeigen
            PHP-Code:
            mysql_real_escape_string(strip_tags($_GET['id'])); 
            mysql_real_escape_string(strip_tags($_POST['id'])); 
            der teil sollte eigentlich alles enfternen was direkt auf deine db wirkt, oder html-befehle in z.b eine ausgabe gibt...

            meiner meinung nach sollte das reichen... zumindest bei strings. wenns um zahlen geht solltest du das z.b per preg_match überrüfen ob nur zahlen drin vorkommen...

            dann sollten eingaben erstmal "grob" sicher sein... natürlich immer darauf achten das der user das was er amcht auch darf... im bezug auf z.b cookie-faking, etc.

            ich selbst benutze für strings auch diese 2 befehle.... zu überprüfen wäre noch auf z.b ein subselect o.ä... das mach ich per foreach und schau nach der syntax... klar musst du aufpassen, falls du sql-befehle übergibst, wirst du immer fehler bekommen, weil du sie ja filterst
            das so mein grobes wissen dazu...
            Under Construktion

            Kommentar


            • #7
              Hallo also generell gilt alles was jemand schreibt oder einträgt ist alles nicht vertrauenswürdig zu sehen und genereller Schadfaktor!
              Zum Beispiel bei Sachen wie $_POST,$_COOCKIE,$_GET,$_SESSION,$_REQUEST,$_FILES also alles was unter register globals zählt.

              mysql_real_escape_string reicht schon völlig zu um sich vor SQL Injektions zu schützen. Als weitere Sicherheitsmasnahme um z.B. bösen Links vor zu beugen sollte man auf jede Variable egal ob das eine zahl oder ein string ist (auch zahlen können strings sein) sollte man ein regex zum Beispiel mit preg_match machen,da ist eigentlich alles mit getan. Denn da lässt man nur die gewünschten Zeichen zu,alles andere wird als Fehler gewertet!

              Man muss natürlich auch darauf achten sich vor Client Seitigen _Angriffen zu schützen z.B. bei einem action Atribut im Formular. Das mache ich zum Beispiel so!

              PHP-Code:
              <form action="<?php echo htmlentities($_SERVER['ÜPHP_SELF']) ?>"
               method="post">
              Da lässt sich z.B. ein Javascript nicht mehr drauf ausführen da html tags gefiltert werden!

              mfg der litter
              Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
              [URL]http://www.lit-web.de[/URL]

              Kommentar


              • #8
                Ein mE sehr wichtiger Aspekt sind die verwendeten Paradigmen. Man muss sich klar machen, was jede Entscheidung für Konsequenzen hat.
                Zum Beispiel: Ich entscheide mich dafür, für die Datenbankanbindung mysql_connect, mysql_query usw. zu verwenden. Damit habe ich mindestens drei Entscheidungen getroffen.
                • Die offensichtlichste: Die Bindung an MySQL. Ich kann mich mit mysql_connect nicht zu einem PostgreSQL Server verbinden. MySQL spezifische Datentypen und Funktionen zu verwenden, steigt damit gerade im Kurs. Ich kann das Datenbanksystem schwerer auswechseln. Dafür kann ich auf mehr Funktionalität zurückgreifen und eventuell schnellere Lösungen entwickeln. Standard-SQL deckt eben nicht alles mögliche ab und Datenbank-Abstraktionen können mit einem mal (scheinbar grundlos) langsam werden, weil man irgendetwas abstrakt so abgebildet hat, dass es konkret schlecht umgesetzt wird.
                • Es werden SQL Statements wie INSERT INTO tablename (a,b,) VALUES ('x','y') verwendet. Sprachelemente (der Sprache SQL) werden mit den Daten vermischt. Daher rührt die Anfälligkeit für injections. Damit es sicher bleibt, muss man konsequent die Daten kontrollieren, in diesem Fall mit mysql_real_escape_string. Vergisst das irgendwo jemand, hat man eine Lücke. Dafür ist es leicht zu schreiben und jemand, der in SQL versiert ist, kann das Statement in jeder Sprache verstehen. Außerdem brauche ich nur ein kleines Set an speziellen Funktionen, der Rest ist String-Manipulation
                • Prozedurale/Imperative Programmierung. Ich muss nach jedem Funktionsaufruf den Rückgabewert prüfen und auf Fehler reagieren und sie (weiter-)propagieren. Tue ich das an irgendeiner Stelle nicht, geht Fehlerinformationen verloren.
                Wenn irgendeine der Konsequenzen Probleme macht, muss man bis zum Grund nach oben gehen, eine neue Lösung finden und die Konsequenzen wieder nach unten durchdenken.
                Insbesondere das Zusammenwürfeln von irgendwelchen Codestücke aus Foren ist ein ziemlich sicherer Weg, ein schlechtes Gesamtwerk zu erzeugen.

                Kommentar


                • #9
                  Zitat von litterauspirna Beitrag anzeigen
                  mysql_real_escape_string reicht schon völlig zu um sich vor SQL Injektions zu schützen.
                  Code:
                  $id = mysql_real_escape_string($_GET['id']);
                  $sql = 'SELECT * FROM table WHERE id = '. $id;
                  example.com/script.php?id=>=1

                  [URL="https://www.quizshow.io/"]Create your own quiz show.[/URL]

                  Kommentar


                  • #10
                    Häh? Was willst du mir grad damit sagen?

                    Übrigens auch die id kann man mit einem regex bearbetien und damit sicher stellen das id auch nur eine Zahl ist! Da brauche ich nicht unbedingt mysql_real_escape_string!
                    Das hier reicht völlig aus!

                    PHP-Code:
                    <?php
                    if(isset($_GET['id']))
                    {  
                     
                    $id preg_replace ("/[^0-9]/"'',  $_GET['id']);
                    }
                    ?>
                    Damit stellst du sicher das id nichts anderes als eine Zahl ist!
                    Wenn du die id über ein hidden feld weiter verwendest dann natürlich macht mysql_real_escape_string denn dann gilt ja wieder jedes Formular Element bzw. was über ein Formular kommt ist als nicht vertrauenswürdig einzustufen!
                    Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                    [URL]http://www.lit-web.de[/URL]

                    Kommentar


                    • #11
                      Soll heißen, der Query schlägt fehl, weil es kein Integer ist.

                      Allgemein gilt: Daten escapen reicht nicht. Man muss auch typensicher prüfen. Wenn also ein integer erwartet wird, sollte auch auf integer geprüft werden. is_numeric() reicht m.E. dazu nicht aus, weil es eben nicht nur Integer zulässt. Sichere Überprüfung:
                      Code:
                      if ((string)((int)$_GET['id']) !== $_GET['id']) {
                          exit("Manipulation, kein gültiger Wert!");
                      }
                      Am besten bei offensichtlichen Manipulationen abbrechen. Wenn man hingegen weitermacht, bleibt immer ein Restrisiko, zumal man die ungültigen Daten durch gültige Standard-Daten ersetzen müsste.

                      Die Regeln weiter oben möchte ich gern noch ergänzen. Nicht nur $_GET, $_POST, $_COOKIE sind unsicher, $_SERVER ist ebenso unsicher und sollte deshalb wie alle anderen Daten behandelt werden.
                      Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                      Kommentar


                      • #12
                        Ja aber wenn ich z.B. das so schreibe ist das doch schon sicher oder nicht?

                        PHP-Code:
                        <?php
                        htmlentities
                        ($_SERVER['PHP_SELF'])
                        ?>
                        So können doch schon zum Beispiel keine Javascripte mehr funktionstüchtig ausgeführt werden oder täusche ich mich da?
                        Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                        [URL]http://www.lit-web.de[/URL]

                        Kommentar


                        • #13
                          Wie sehen denn deine Skripts aus?
                          In der Regel werden die Daten noch verarbeitet und nicht nur ausgegeben.
                          Zum Beispiel werden die Daten in die Datenbank geschrieben. Und wenn man die Daten vorher nicht validiert, könnte jemand einfach seinen User-Agent manipulieren oder den Accept-Header etc.

                          Ach und bevor ich es vergesse: zur Ausgabe muss natürlich schon htmlentities() ran. Aber die Ausgabe ist ja nicht alles.
                          Folgendes Skript ist auch eine typische Falle:

                          test.php:
                          PHP-Code:
                          <?php
                          echo $_SERVER['PHP_SELF'];
                          ?>
                          Jetzt muss man die Datei nur noch mit dem Pfad
                          Code:
                          /test.php/%3Cscript%3Ealert('XSS')%3C/script%3E
                          aufrufen und sehen, was passiert.
                          Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                          Kommentar


                          • #14
                            Wie sichere ich mich aber eben im action Atribut richtig ab? Das würde mich interessieren das man da kein xss drauf hacken kann!
                            Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                            [URL]http://www.lit-web.de[/URL]

                            Kommentar


                            • #15
                              Das action-Attribut ist manipulierbar wie alles andere auch. Du musst eben alle Daten, die das PHP-Skript nicht unmittelbar selbst erzeugt, validieren.
                              Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                              Kommentar

                              Lädt...
                              X