✔ Ein paar grundlegende Sachen zur Sicherheit in PHP / MySQLi

Danke für den Hinweis ;)

Ja ist ziemlich viel Holz was man beachten muss. Ich werde mein Bestes geben das zu berücksichtigen in meinem Projekt.

Ich Danke auch nochmal Sheel und Bratkartoffel :)

Zusätzlich werde ich nun auch noch versuchen via htacces etwas Sicherheit rein zu bringen und meine Ordnerstruktur etwas verschleiern. Zumindest will ich es versuchen. Aber dieses mod rewrite bringt mich zum Verzweifeln. Das versteht doch kein Mensch :D Naja schon, aber mit regulären Ausdrücken stehe ich etwas auf Kriegsfuß.

Mein Plan sieht vor den Gast domain.de/Zeichenkette/ aufrufen zu lassen und auf index.php?ziel=zeichenkette zu leiten. Macht dass das Projekt etwas sicherer eurer Meinung? Oder ist das Spielerei?
 
Damit man nicht erkennt wie die Struktur ist bzw. damit nicht erkannt werden kann dass es PHP ist. Zumal Natürlich die Variablen nicht in der URL offen stehen und Angriffsfläche bieten, Dachte ich :rolleyes:
 
Ob es PHP ist lässt sich an einer Reihe von anderen Merkmalen auch erkennen.

Und den Variablennamen verstecken ... naja, schaden wirds nicht, aber imho ist es den Aufwand nicht wert
(natürlich haben solche Rewrites andere gute Gründe außer Variablennamen-verstecken...)
 
Bin da noch über etwas gestolpert was eine Frage ausgelöst hat: Register Globals.

Wenn ich in meinen Skripten stets die genutzten Variablen vorher initialisiere. Zum Beispiel $logged_in = false; habe ich dann etwas zu befürchten? Wenn nein macht es Sinn ganz weit vorn eine Variablenliste zu Includen und dort alles zu initialisieren? Dann müsste ich in den Skripten selbst nichts mehr machen. Oder besser per Klasse oder Funktion das ganze?

Habe auch gelesen ab PHP6 soll das standardmäßig deaktiviert sein? Stimmt das?

Außerdem habe ich noch einen Codesnippet gefunden:

PHP: 
function unregister_globals() {
    // Überprüfung, ob Register Globals läuft
    if(ini_get("register_globals") == "1") {
        // Erstellen einer Liste der Superglobals
        $superglobals=array("_GET", "_POST", "_REQUEST", "_ENV", "_FILES", "_SESSION", "_COOKIES", "_SERVER");
        foreach($GLOBALS as $key => $value) {
            // Überprüfung, ob die Variablen/Arrays zu den Superglobals gehören, andernfalls löschen
            if(!in_array($key, $superglobals) && $key != "GLOBALS") {
                unset($GLOBALS[$key]);
            }
        }
        return true;
    }
    else {
        // Läuft Register Globals nicht, gibt es nichts zu tun.
        return true;
    }
}
unregister_globals();

Was haltet Ihr davon?
 
Die Funktion ist...
a) seit PHP 5.3 (2009) eigentlich ausgeschaltet, und nur nach explizitem Einschalten verfügbar
b) seit PHP 5.4 (2012) überhaupt nicht mehr vorhanden.
http://php.net/manual/de/security.globals.php

Also, keine Sorgen machen, außer du hast noch so alte Versionen (und dann hast du viel mehr Probleme)

Btw., dann kam PHP 5.5 (ab Juni 2013) und 5.6 (ab August 2014). 5.6 bekommt, durch einige Verlängerungen gegenüber vom ursprünglichen Plan, noch immer (Sicherheit-)Updates (aktuell 5.6.30), aber trotzdem gibt es auch da keinen Grund mehr, es zu verwenden. DIe Updates gibts nur noch deswegen, weil gemerkt wurde, dass viele Leute zu faul sind upzudaten, und man die Massen-hack-welle etwas rausschieben will.
PHP 6 gibts keins, weitergemacht wurde mit PHP 7 (ab Dezember 2015), und da ist man aktuell bei 7.1.5

...

Zur ursprüngliche Frage: Ja, die Variablen sicher immer zu initialisieren löst das. Das Programm vor Onlinestellen gründlich testen (keine undefined-variable-Meldungen bei nicht-bösartigen Testern) löst das auch.

(Beide Sachen sind aber etwas, was man von 95% der PHP-"Programmierer" aber leider nicht erwarten kann. Der durchschnittliche PHP-Programmierer kann nicht programmieren, versteht nicht einmal das Konzept einer Variable usw. wirklich, sondern kopiert einfach nur Code von verschiedenen Webseiten zusammen und ändert die Zusammenstellung bis es irgendwie funktioniert. Ok, Rant over).
 
Zuletzt bearbeitet:
Ohje :confused:

Kann ich mir gar nicht vorstellen, dass es solche Typen gibt, denen all sowas völlig egal ist. Gerade wenn man Kunden hat, ist es doch wichtig o_O

Danke für die Exkursion in die PHP Versionen. Ich habe selbstverständlich Kein PHP 5 mehr im Einsatz sondern das neuste ;) Das mit PHP 6 habe ich gelesen und übernommen ohne drüber nachzudenken. Mein Fehler.
 
Ich glaube das Thema nimmt Überhand an :D;) Bitte um Verzeihung.

Mir ist nämlich noch etwas eingefallen. Thema Bilder schützen. Hier gibt es zwei Sachen für mein Projekt zumindest. Meine Bilder für die Webseite und die Bilder der User.

Meine eigenen Bilder:

Ich dachte mir, ich könnte ja einfach meinen Ordner Bilder schützen indem ich das Verzeichnis via htaccess vor Zugriffen schütze. Mit deny from all schließe ich allerdings auch die Zugriffe meiner Scripte aus.

Also dachte ich mir, schließe ich den Zugriff von außen aus:

PHP: 
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?domain.de(/.*)?$ [NC]
RewriteRule .(gif|jpg|jpeg|png|GIF|JPG|JPEG|PNG)$ https://domain.de/images/restricted.gif [R,L]

Das passt zwar für die Zugriffe die nicht von meinem Server stattfinden. ABER ich kann trotzdem bei den Bildern rechtsklicken und Grafik anzeigen klicken, downloaden etc. Das würde ich gern ebenfalls unterbinden. Da sollte dann auch das restricted.gif stehen, wenn möglich.

Bilder der User:

Bei den Usern dachte ich einfach daran deny from all zu machen und den Aufruf via PHP zu regeln, wie in diesem Thread: https://www.tutorials.de/threads/apache-modul-direktaufruf-von-bildern-verhindern.216790/

Geht das eventuell auch einfacher?
 
filament hat gesagt.:
Bitte um Verzeihung.
Zum Vergrößern anklicken....
Ein Forum lebt von Fragen :) kp

Zum Verhindern vom Speichern von Bildern ... eine brauchbare Lösung gibts nicht. Man kann es "etwas" schwerer machen, ein paar wenige User kann man vielleicht sogar komplett aufhalten, aber zB. mich kannst du damit keine 10 Sekunden verlangsamen (für alle Bilder auf der Seite zusammen).

Aber alles der Reihe nach:

Zum "deny from all": Wie bereits geschrieben heißt das "Require all denied".
"deny from all" war in früheren Apache-Versionen, und funktioniert jetzt nur noch wenn man ein bestimmtes Kompatibilitätsmodul hat.

Beide beeinflussen deine PHP-Scripte nicht. Nur HTTP-Zugriffe von außen, zB. eben Browserzugriffe, werden dadurch geblockt.
Nur ... es wäre zwar möglich, Bilder denien, in <img>-Tags PHP-Dateien anzugeben die dann das Bild von der Platte holen und zum Browser weiterleiten usw.., aber das ändert rein gar nichts an der Speicherbarkeit. (Und auch wenn, bitte eine bessere Lösung. Der 12 Jahre alte Code dort ist nicht mehr zeitgemäß, in vielen Punkten)

Vorgehen 1: Die Referrer-Sachem, kennst du ja schon. Probleme: a) Sehr einfach fälschbar, b) Wenn das Bild schon gerade angezeigt wird und der Nutzer es speichern will machen viele Browser nicht noch einen Request, sondern nehmen einfach das Bild vom RAM, und c) wirds dadurch evt. überhaupt nicht mehr angezeigt (Den Browser einfach keine Referrer mehr senden lassen, aus Datenschutzgründen, usw. ... kommt vor (Tor-Browser, Firefox-Privatmodus, ...)).
Wenn man Trafficprobleme hat (wie der Fragesteller im Link) kann das schon helfen, aber sowas passiert auch nicht wegen Leuten die direkt das Bild wollen (sondern zB. Einbettung in Forenthreads, die von vielen Leuten gelesen werden die nicht speziell am Bild interessiert sind)

Vorgehen 2: Die rechte Maustaste per JS blocken. Probleme: a) Browser lassen diesen Unsinn nicht mehr zu (entweder gar nicht, oder einfach mit zB. Shift-Taste umgehbar), b) Scriptblocker für JS generell,c) kann man auch ohne rechte Maustaste speichern (Menüleiste, Developertools, wget, ... Notfalls einen Screenshot machen und zuschneiden...), d) ärgert es die User und vertreibt manche auch ganz. Die rechte Maustaste ist auch ohne Bildspeichern sehr nützlich, und da alles verbieten ist eben nicht zielführend.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück