✔ Ein paar grundlegende Sachen zur Sicherheit in PHP / MySQLi

Was ich meinte ist, nicht "dauerhaft" jede PHP-Meldung mitloggen, speziell wenn man es sowieso nicht anschaut.
Während der Entwicklung kein Problem, und wenn man später einen Fehler sucht auch, aber sonst ...

Und ja, Backups :D Ohne hatte allein ich das Forum hier schon zweimal geschrottet.
 
Hi,

Loggen generell schon, ist auch wichtig. Nur Logfiles eignen sich mit PHP nicht so gut. Eine andere Möglichkeit wäre in die Datenbank (extra Tabelle, *nur* INSERT, keine Rechte für UPDATE oder DELETE!) oder per Syslog an einen externen Server wenn man extrem paranoid ist :)

Das richtige Logging ist auch so eine Sache für sich... Nicht zu viel, aber falls ein Fehler auftritt genügend um den Fehler leichter zu finden.
Zeitstempel, Level, Client-IP, RequestID, SessionID, PHP Klasse / Filename, Nachricht

Loglevel nicht nur "global" einstellbar, sondern pro Komponente / Klasse / Datei.
Zeitstempel UTC, mit Millisecs
Client-IP je nach Datenschutz auch nur die ersten 3 Oktets oder gehasht.
Request-ID z.B. eine UUID nehmen um parallele Abläufe filtern zu können.
Session-ID ähnlich RequestID

Grüsse,
BK
 
Habt Ihr das selbst gecoded? Oder gibt es gute fertige Scripte dafür? Man muss ja nicht für Alles das Rad neu erfinden, oder?

Ich dachte gerade an das loggen von fehlgeschlagenen Anfragen. Aber beim loggen wage ich nich auf Neuland. Habe ich noch keine Erfahrung mit und weiß nicht was wichtig ist. (Bei meinen laufenden Projekten, tut das mein CMS für mich)
 
Naja, ein DB-Insert mit PHP ist nicht viel Code.
Und wo im großen PHP-Programm man welche Logmessage haben will, das muss man wohl selbst coden...

Es gibt schon auch Libs, die dann an zig verschiedene Stellen loggen können (Mails, Dateien, DB, usw.usw.), aber wenn man nur was einfaches braucht sind die zu umständlich
 
Danke für deine Nachricht. Ich schaue mir das noch genau an.

Kannst du noch was zu meiner Frage bzgl. des Loggen sagen, zwei Posts vor Deinem?

Ansonsten noch eine generelle Frage:

Wie schütze ich mich vor Brute Force Attacks? Die IP loggen und aussperren macht da sicher wenig Sinn, weil solche Angriffe sicher in Kombination mit Proxy Servern laufen und die IP ständig wechselt oder?
 
Loggen: Ich bin mir nicht sicher, was ich da antworten soll...
sicherheitsmäßig wäre alles interessant, was irgendwie abnormal ist (nicht nur die Art, sondern zB. auch die Menge einer Aktion; oder bestimmte Kombinationen; usw.) Was das ist hängt wohl sehr stark vom Programm ab.

(Und Logs dann auch regelmäßig anschauen... sonst kann man sich die Loggerei gleich sparen)

...

Bruteforce?
Um was zu tun? Passwort erraten (welches, wo), Filenamen herausfinden, den Server einfach sehr auszulasten (eher als DOS bekannt), ...?

Falls es um Passwörter geht, ein wirkliches Massen-IP-Problem hab zumindest ich nicht. IPs sperren geht gut.
Es kann schon sein dass die verwendeten IPs von Proxies sind (nur eben nicht sehr viele), und dass auch ehrliche Nutzer des Proxies ausgesperrt werden, aber das ist dann imho Kollateralschaden ... zB. könnte der Proxybetreiber etwas tun, damit sein Proxy nicht von Bruterforcern missbraucht wird...

Was man auch im Massen-IP-Fall teilweise gut machen könnte, ist, nicht die IP sondern dem Account nach x Anmeldeversuchen für eine bestimmte Zeit generell keine Anmeldungen mehr erlauben. Egal von welcher IP. Leute die schon eingeloggt sind aber trotzdem drin lassen. Für die sehr seltenen Fälle wo dadurch ein ehrlicher Benutzer ein Problem hat, Adminkontakt, etwas halbwegs geheimes (wie zB. die verwendete Mailadresse) sagen lassen, und dann manuell reinlassen.
Aber sowas nicht für SSH oder so, nur für zB. Forenaccounts wo man auch einen Admin kontaktieren kann. (Bei SSH den Zugang für alle IPs eine Zeit lang sperren wäre blöd.) Abhilfe in dem Fall: Einfach sein sehr starkes Passwort bzw. Key+PW (worauf man sich bei vielen tausend Forenbenutzern natürlich nicht verlassen kann, bei ein paar wenigen Admins schon eher), und das normale Einzel-IP-basierte Sperren.

(Mit einer strengen Einstellung wie max. 5 falsche SSH-Logins pro Tag und IP: Auch ein Angreifer mit allen IPs der Welt müsste ca. 9322804573176396259270537189911457 Jahre warten, um einer 256bit-SSH-Key per Bruteforce herauszufinden. Und das wäre nur ein Key, mit serverseitigem Passwort vervielfacht sich das noch weiter)
 
Wow, hier wurde ja schon einiges gepostet!

Eine kleine Ergänzung hierzu noch:
filament hat gesagt.:
Die meisten empfehlen die PHP hash Funktion.
Zum Vergrößern anklicken....
Wenn du password_verify() von PHP verwendest, so wirst du in der Doku dazu folgenden Satz finden:
This function is safe against timing attacks.

Zwar ist das Ausnutzen von Timing Attacks bei Vergleichen von Hashwerten von sehr wenig Nutzem, aber ich denke, es ist ganz gut, wenn man weiß, dass es auch solche Angriffsszenarien gibt ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück