PHP Sicherheit

Dieses Thema im Forum "Webentwicklung" wurde erstellt von gummel, 6. Februar 2008 .

Schlagworte:
Status des Themas:
Es sind keine weiteren Antworten möglich.
Seite 1 von 2
  1. 6. Februar 2008
    Hallo liebe community,

    ich hätte da ein paar fragen zur sicherheit einer website.

    meine erste frage ist, wenn man seiten über GET aufruft Beispiel: http://www.uschibahuschi.de/index.php?page=rums

    Wie macht man das, das er es auch wirklich nur über die index macht und nicht über eine beliebige andere seite (beispiel: video.php?page=uschi)? Ich nehme mal an über die .htaccess ... aber wie lautet der code dazu?

    Dann wäre ich für alle weiteren tipps dankbar, wie zum login mit session etc.

    Auf Kommentare wie benutz die sufu oder bla bla bla^^ kann ich gern verzichten

    BW bekommt jeder der mir auch nur im ansatz hilft

    und natürlich ein DANKE
     
  3. 6. Februar 2008
    AW: PHP Sicherheit

    Du frägst doch in der index.php die GET-Parameter ab und gibst dann die entsprechende Seite aus. Wenn du so eine Abfrage nicht auch in der video.php hast, kann man doch gar nicht über die video.php auf andere Seiten zugreifen! Oder hab ich dich falsch verstanden?
     
  4. 6. Februar 2008
    AW: PHP Sicherheit

    doch das geht, dann wird seite halt ohne template etc dargestellt
     
  5. 6. Februar 2008
    AW: PHP Sicherheit

    print_r($_SERVER)
    da findeste alles benötigte zum Checkn, welche PHP Datei aufgerufn wird.
     
  6. 6. Februar 2008
    AW: PHP Sicherheit

    hilft mir zwar gerade nicht weiter.... aber bw ist raus
     
  7. 6. Februar 2008
    AW: PHP Sicherheit

    Wenn du nicht willst dass Dateien direkt über den browser aufgerufen werden, sondern nur per include() oder andren befehlen von PHP, kannst du folgenden Code benutzen:
    PHP:
         if ( basename ( __FILE__ ) ==  basename ( $_SERVER [ 'PHP_SELF' ])) {
                 header  ( "Location: index.php" );
            exit(     0 );
        }
    oder die Dateien in ein extra Verzeichnis legen (z.B. template) und da eine .htaccess Datei mit folgenden Inhalt erstellen:
    Code:
    <FilesMatch "\.(inc.php|htaccess)$">
 order allow,deny
 deny from all
 </FilesMatch>
    hoffe ich konnte helfen
     
  8. 7. Februar 2008
    AW: PHP Sicherheit

    Solche Threads mag ich, eigentlich hat der Thread ja nicht wirklich was mit Sicherheit zu tun sondern wie man ordentlich programmiert. Zumal solch ein oberer Thread echt für die Katz ist, denn der Vergleich der Basenames ist auch bei jeder anderen Datei als index.php true und zusätzlich dazu ist die Weiterleitung nicht korrekt. Nun gut, exit kann man in dem Fall auch ohne Parameter aufrufen aber passt schon ...


    Mein Tipp zu der Frage wäre einfach, ORDENTLICH programmieren! Was nicht öffentlich abgelegt wird, kann auch nicht öffentlich aufgerufen werden. Und dem User nur das anzubieten, was er brauch, UND NICHT MEHR, sollte eigentlich zum Gundverständnis moderner Software gehören!

    Alles andere sind nur Workarounds gegen die Symptome aber die Krankheit bleibt!
     
  9. 7. Februar 2008
    AW: PHP Sicherheit

    nu mal net so zornig^^

    erstmal danke an teqnix

    ehm ... ja ordentlich programmieren ... ich bin gerade am lernen und hab ein admin portal etc für einen kollegen gebaut ... klar ist durch richtiges programmieren alles sicher, wäre ja auch unlogisch wenn nicht -.- Nur weis ich nicht ob das so 100%ig gut ist etc ... und es gibt immer ein paar faktoren wo das eine besser ist als das andere etc .... Find dein Posting etwas agressiv

    naja bw ist an euch beiden raus

    Übrigens über tipps würd ich mich auch weiterhin freuen
     
  10. 7. Februar 2008
    AW: PHP Sicherheit

    Ja was ist dir denn lieber?

    Einen öffentlichen Ordner mit .htaccess sperren, oder direkt einen privaten Ordner außerhalb des öffentlichen Baumes nutzen.

    Oder überall das Script ändern und Zeilen mit einer unkonformen Weiterleitung einrichten, oder es direkt ordentlich machen, denn der PHP - Trickt erzeugt effektiv nur Redundanz. In der index.php darf man es nicht nutzen so, weil es eine Endlosschleife geben würde, also muss man es in den anderen nutzen. Aber wenn man diesen Unterschied doch verstanden hat, wieso muss man den nochmal kontrollieren anstatt es direkt anders zu machen.

    Weißt du, du musst doch im Endeffekt nur eine index.php anlegen, einen GET - Parameter kontrollieren und die passende Datei includen. Das sind drei Schritte die in jedem Anfänger - Tutorial erklärt werden und den Begriff Whitelist wirst du auch schonmal gehört haben .... Also alles chillig und das ohne .htaccess oder irgendwelche Weiterleitungen!
     
  11. 8. Februar 2008
    AW: PHP Sicherheit

    php und sicherheit:

    eingaben überprüfen(GET,POST,COOKIE)
    - eigene oder bereits vorhandene filter anwenden
    - reguläre ausdrücke sind sehr hilfreich

    client
    - überprüfen der benutzer(referer)
    - eindeutige benutzer-id vergeben

    sessions
    - eigenes session-management realiseren z.b mit mysql

    eigene sicherheitsmechanismen
    - regenerierung der benutzer-id bei login/logout/registrierung u.s.w
    - formular ohne akzeptierung von cookies ausblenden
    - verschlüsselungen von daten

    beispiel für eine kleine absicherung:
    man kann auch eine zufalls-id in session ablegen und diese in url beifügen, um auf der nächsten seite zu überprüfen ob die daten übereinstimmen. falls nicht neue generieren...

    mit php kann man schon sichere webanwendungen entwickeln, die kreativität ist hier gefragt
     
  12. 8. Februar 2008
    AW: PHP Sicherheit

    Das sieht erstens unschoen aus (Suchmaschinen usw.) und ich verstehe nicht, was das bringen soll.
     
  13. 8. Februar 2008
    AW: PHP Sicherheit

    wenn es für suchmaschinen zu unschoen ist, dann packst du die id am ende der url rein und lässt es mit dem mod_rewrite überschreiben.

    was das bringen soll?
    somit sparst du dir captchas und sonstiges. also verhinderst sinnlose Angriffen von bots oder exploits.
     
  14. 8. Februar 2008
    AW: PHP Sicherheit

    wo liegt denn da das problem für die bots und exploits? die url auszulesen ist eines der leichtesten sachen...
    irgendwie erkenn ich den sinn nicht, was das bringen soll...
     
  15. 8. Februar 2008
    AW: PHP Sicherheit

    bots kennen sessions nicht, somit bleibt jedem bot der zugang zur seite verwehrt => google usw. werden diese seiten nicht listen.

    am sichersten ist, wie makenx schon sagte, eine saubere programmierung.

    PHP:
    <? php
        
             function  requestPage ( $page ,  $prefix ,  $extension ,  $exept  =  null ,  $includePath  =  './' ) {
                 $fileName  =  $prefix  . ( preg_replace ( '~(\W|\s)~' ,  '' ,  $page )) .  '.'  .  $extension ;
            
                 //dateiname okay?
                 if(( is_array ( $exept ) &&  in_array ( $fileName ,  $exept )) || ( is_string ( $exept ) &&  $fileName  ==  $exept )) 
                return      false ;
            
                 //datei suchen
                 if( is_array ( $includePath )) {
                foreach(     $includePath  as  $path ) {
                         $incPath  = (( $path [ strlen ( $path ) -  1 ] !=  '/' ) ?  $path  .  '/'  :  $path ) .  $fileName ;
                    if(     file_exists ( $incPath )) return  $incPath ;
                }
            } elseif(     is_string ( $includePath )) {
                     $incPath  = (( $includePath [ strlen ( $includePath ) -  1 ] !=  '/' ) ?  $includePath  .  '/'  :  $includePath ) .  $fileName ;
                if(     file_exists ( $incPath )) return  true ;
            }
            
            return      false ;
        }    
        
             //mixed requestPage(string $name, string $prefix, string $extension [, mixed $exept[, mixed $includePath]])
             $isOkay  =  requestPage ( 'index' ,  '' ,  'php' , array(
                 'start.php' ,  'main.php' ,  'index.php'  //diese datein sind nicht valid!
             ));
        
        print ((     $isOkay ) ?  'okay'  :  'nicht okay' );  //nicht okay, da "index.php" verboten ist
     ?>
     
  16. 8. Februar 2008
    AW: PHP Sicherheit

    du machst ne scheiß variable in deine index und fragst in der includeten datei nach ob diese variable exestiert.... falls nicht werden keine daten ausgegeben... so einfach ists....
     
  17. 11. Februar 2008
    AW: PHP Sicherheit

    was aber nix bringt wenn die page direkt inkludiert wird.

    man nehme http://deine-domain.de/include.php?page=../../WINDOWS/system32/cmd.exe
    das ist keine von dir erstellte page, somit auch keine abfrage drinnen.

    mfg - so einfach ists...
     
  18. 11. Februar 2008
    AW: PHP Sicherheit

    Hehe gefährliches halbwissen, Session-Management ist im PHP schon vorhanden.

    ...

    Es heisst übrigens nicht Bots sondern Crawler und klar durchsuchen die auchh Session orientierte seiten.
     
  19. 11. Februar 2008
    AW: PHP Sicherheit

    es heißt spider und nein wenn die seite nur über ne sessionid or whatever angezeigt wird wird der bot die seite nicht listen (da kein content).

    ein spider ist kein browser, kann also mit ner session nicht viel anfangen, es sei denn er wurde gut programmiert. (session sind serverseitig, stimmt, aber die id wird ganz normal in nem cookie gespeichert der wiederum vom browser als file auf dem remotepc abgelegt wird)
     
  20. 12. Februar 2008
    AW: PHP Sicherheit

    ich hab immernoch kein plan, wieso das session gedönst bots ausschließen soll. sicher, die 0815 teile die jedes skriptkiddie runterladen kann können das nicht von haus aus. die skripte sind ja auch eher ein "proof of concept". wenn man dann aus dem stadium einen skriptkiddie raus ist und sich die sachen nimmt und umschreibt, dann stößt man schnell z.b. auf python. dort bindet man nur ne kleine standardklasse ein, schreibt ein wenig am ursprünglichen skript rum und schon hat man volle sessionunterstützung... hängt von mir aus irgendwelche parameter an urls an, schickt cookies soviel ihr wollt; meine skripte haben kein problem damit

    das einfachste was nützt um php dateien zu schützen, die nur aus einem hauptskript aufgerufen werden dürfen ist durchzuführen, indem man ne konstante im hauptskript definitert und diese dann in den zu sperrenden seiten abfrägt. wenn sie nicht vorhanden ist, dann "die".
    was auch noch schön ist: oop. wird nur in der hauptdatei eine instanz von einer klasse erzeugt und in den includierten dateien nur ne klasse deklariert wird, dann kann man soviel dateien aufrufen wie man will
     
  21. 12. Februar 2008
    AW: PHP Sicherheit

    Ausschließen wird man automatische Programme nie ganz können, aber es kommt immer auf die Kosten-Nutzen - Kalkulation an wie mit Sessions, clientseitigen Scripten usw. umgegangen ....

    Nein ist es nicht, wieso müssen wir andauernd um den heißen Brei reden? Was der User nicht durch einen simplen Aufruf zu sehen bekommen soll, wird ihm einfach nicht öffentlich angeboten und PUNKT. Man sollte es natürlich nicht bei dieser Maßnahme belassen, aber solch ein Sicherheitsgrundsatz sollte eigentlich Standard sein, der User darf nur das, was er auch wirklich "dürfen soll".

    Eine Konstante wie z.B. beim phpBB kann man dann natürlich immernoch einsetzen, aber imho ist das nicht der wichtigste und einfachste Schritt ....

    Den Satz verstehe ich sinngemäß noch nichtmals ganz, aber saubere Programmierung führt meistens auch zu sicherem Code .... Falls du das sagen wolltest.
     
  22. 12. Februar 2008
    AW: PHP Sicherheit

    @ caramba, du könntest auch mal dein Kein/Halb/Profi Wissen mit uns teilen, anstatt nur mein Post zu zitieren.

    es wurde nicht gesagt dass man unbedingt Session-Management benutzen sollten. PHP bietet viele Funktionen mit denen man auch sichere Scripte programmieren kann. damit können viele Sicherheitsmechanismen realisiert werden. es hängt alles vom Programmierer/Coder ab, wie diese arbeiten bzw. sich verhalten sollten.

    Session-Management kann man auch auf eigene Art und Weise gestalten. Ich arbeite mit Clients also wertet man diese aus und speichert die dazugehörige variablen in der Datenbank. Du kannst es auch Client-Management nennen bleibt dir überlassen.
     
  23. 13. Februar 2008
    AW: PHP Sicherheit

    genau... an phpBB hatte ich auch gedacht... so wie ich den threadstarter verstanden habe, wollte er verhindern, dass dateien aufgerufen werden, die ansonsten nur zum includieren vorgesehen sind. in dem fall behaupte ich, dass der weg von phpBB eben der einfachste weg ist.

    so jetzt komm ich zum heißen brei, nämlich der server sicherheit im allgemeinen (was ja jetzt nicht vom threadstarter so gefragt wurde):

    php.ini:
    • register_globals off (seit einer hohen 4er und bei 5er php versionen standard)
    httpd.conf:
    im internet ergooglen, wie man:
    • directory listing abstellt
    • den apache zum schweigen bringt bzgl. versionsnummer, module usw...
    .htaccess:
    • generell, wenns was zum verbergen gibt
    bei root rechten:
    • auf richtiges chmod und chown achten...



    sry, da war ich unter zeitdruck was ich sagen wollte: mit hilfe von oop kann man php code "kapseln" (im sinne von: der code wird nur ausgeführt, wenn auch ne instanz einer klasse erzeugt wird). wird nun in der datei, die NICHT für die öffentlichkeit bestimmt ist keine instanz einer klasse erzeugt, bzw. ne klassenmethode aufgerufen, so wird eben der code in der klasse auch nicht ausgeführt.
     
  24. 13. Februar 2008
    AW: PHP Sicherheit

    Jo wobei du beim phpBB bedenken musst, das dessen Entwickler auf Massenkompatibiltät setzen, was wiederum bedeutet, alles in einen "Foren-Ordner" zu knallen. Die können ja nicht im Voraus wissen, wie es um die Ordner-Struktur des "Kunden bestellt ist.
    Das mit der Konstanten ist somit ein notwendiger Weg, aber immer noch nicht der einfachste

    Hat effektiv nichts mit Sicherheit zu tun, denn auch ordentlich gecodet ist eine Applikation mit register_globals OK. Das "ordentliche Coden" wird nur schwerer damit, zu PH5 - Zeiten.

    Und hiermit unterstützt du bereits, was ich dir als Kritik entgegen brachte, zeige dem User nur das, was er sehen soll. Wenn in der öffentlichen Directory nur die index.php zu finden ist, dann kann er im Listing klicken was er will. Dieser Schritt kuriert ein Fieber, aber nicht die "Krankheit".

    "Security by Obscurity" hält keinen "Verbrecher" vom "böse Sachen tun" ab. Wenn ein Apache die Option für ein Produktivsystem ("Prod") anbietet, sollte man sie auch nutzen. Steigert die Sicherheit, klar, aber auch hier meine Meinung, dass das doch eigentlich selbstverständlich ist.

    Ahso meinst du das, jo guter Ansatz, aber man sollte trotzdem darauf achten, auf Variablen mit globalem Scope zu verzichten, denn das gehört auch zu gutem Code.
     
  25. 13. Februar 2008
    AW: PHP Sicherheit

    darum habe ich das auch vorgeschlagen...


    naja... ich fand es schon bedenklich, dass man per get-parameter variablen ändern konnte, die im skript zufällig den gleichen namen hatten... hast du z.b. etwa deine ganzen schleifenvariablen untersucht, ob sie per get-parameter umgeändert werden?! [gut... initialisierung hilft: $i = 0;]

    och... selbstverständlich sollte es schon sein, aaaaber wenn ich mir da einige große seiten anschaue, dann wird man förmlich mit informationen überhäuft. auch wenns nur ein wenig mehr sicherheit ist, machen sollte man es doch. achja: um damit auf das session-thema zurückzukommen: im grunde genommen hat das eben genausowenig wirkung wie sbo

    jo.. würde ja auch den ganzen vorteil von oop zunichte machen...


    naja... um dem thema vll. mal ein ende zu machen:
    für wirkliche sicherheit gibt es nicht DAS eine mittel. es ist immer ein ganzes bündel von möglichkeiten, das man nutzen sollte um sicher zu sein.... was im umkehrschluss bedeutet: absolute sicherheit gibt es nicht...
     
  26. 13. Februar 2008
    AW: PHP Sicherheit

    Richtig, wer nicht ordentlich codet muss schnell sein Lehrgeld bezahlen.

    Erst heute ein Projekt von einem anderen Mitbewerber angenommen, und was sehe ich da, fehlende Eingabevalidierung beim Login-Formular...YEAH....

    Also naja, am Beispiel von Suchmaschinen-Spidern sieht man, dass clientgelagerte Dinge eben sehr wohl Einfluss haben, mehr als ein Text, wie z.B. n Apache-Token (wenn wir jetzt mal den Status Code außen vor lassen)

    WORD ...
     
  27. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.

Seite 1 von 2