nicht angemeldet
Sicherheit
Morgen,
hallo ich bin noch relative neu in der PHP-Sache. Hab schon einige Scripte probiert und nun soll bald meine erste HP online gehen.
Vorher wollte ich, wenigstens alibi mäßig meine codes nochmal unter dem Aspekt sichertheit überdenken.
Kennt jem. eine passable seite die sich mit sicherheitlücken in PHP scripten beschäftigt, und diese vernünftig erklärt???
Ich habe auf meiner Page:Gästebuch,Counter,Art"PHP BILDERBUCH" und noch n paar kleine sachen.
Freu mich auch über generelle Tipps von euch!!!
MFG Johannes
-
Hell-O!
Vorher wollte ich, wenigstens alibi mäßig meine codes nochmal unter dem Aspekt sichertheit überdenken.
Ein sehr löbliches Vorhaben.
Kennt jem. eine passable seite die sich mit sicherheitlücken in PHP scripten beschäftigt, und diese vernünftig erklärt?
Das PHP-Manual enthält ein sehr umfassendes Kapitel zum Thema Sicherheit.
Siechfred
-
Hallo,
für das Gästebuch(wird sicher kaum frequentiert werden ist mehr ne prestigesache)schreibe ich die daten per fwrite in meine datei guestbook.dat.php, kann daraus ein sicherheitsrisiko entstehen welches sich mit mysql vermeiden ließe???
MFG Johannes-
Hi,
für das Gästebuch(wird sicher kaum frequentiert werden ist mehr ne prestigesache)schreibe ich die daten per fwrite in meine datei guestbook.dat.php, kann daraus ein sicherheitsrisiko entstehen welches sich mit mysql vermeiden ließe???
Abgesehen davon, daß dadurch neue Sicherheitslücken entstehen könnten, kommt es auf die Umstände an. Das Schreiben von Daten ist grundsätzlich harmlos, aber
- warum gehst Du das Risoko ein, daß diese Datendatei ggfls. von php geparsed werden kann?
- sicherheitsrelevant dürfte erst die Verarbeitung der Daten werden.
freundliche Grüße
Ingo-
Hi,
ah na klar ich versteh was du meinst! Es ist blöd der include datei ne .php endung zu verpassen!so könnte man z.bsp bei name <?php unlink(... eintragen und der webserver kickt meine dateien weg.Danke
-
Hi
Hi,
ah na klar ich versteh was du meinst! Es ist blöd der include datei ne .php endung zu verpassen!so könnte man z.bsp bei name <?php unlink(... eintragen und der webserver kickt meine dateien weg.Danke
wäre gut möglich, kommt natürlich auch auf dein Script an. Wenn du es include'st, dann wäre das schon blöd.
Nimm ne einfache CSV-Datei, die du dann mit fgetcsv() einließt.
Als Tipp: Formulareingaben (z.B. im Gästebuch!) immer mit addslashes() bearbeiten. ;)
mfg dolito
-
Hey,
die datei wird über readfile eingebunden... das mit dem addslashes ist ein interessanter tipp!MFG Johannes
-
Moin!
Als Tipp: Formulareingaben (z.B. im Gästebuch!) immer mit addslashes() bearbeiten. ;)
Diese Aussage ist in ihrer Allgemeinheit immer falsch!
Es ist mit Sicherheit eine gute Idee, erhaltene Daten gemäß der Ausgabe- bzw. Speicherumgebung passend zu codieren bzw. zu escapen.
Daraus kann aber nicht gefolgert werden, dass diese Maßnahme immer und überall mittels addslashes() vollständig und zufriedenstellend ergriffen werden kann. Eher das Gegenteil ist der Fall: Wenn überhaupt, hat man deutlich mehr Veranlassung, stripslashes() auf Formulardaten anzuwenden.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Daraus kann aber nicht gefolgert werden, dass diese Maßnahme immer und überall mittels addslashes() vollständig und zufriedenstellend ergriffen werden kann. Eher das Gegenteil ist der Fall: Wenn überhaupt, hat man deutlich mehr Veranlassung, stripslashes() auf Formulardaten anzuwenden.
Wow! Jetzt erklär mir das mal, weiß grad nicht warum du stripslashes() anwenden willst?
mfg dolito
-
echo $begrüßung;
Daraus kann aber nicht gefolgert werden, dass diese Maßnahme immer und überall mittels addslashes() vollständig und zufriedenstellend ergriffen werden kann. Eher das Gegenteil ist der Fall: Wenn überhaupt, hat man deutlich mehr Veranlassung, stripslashes() auf Formulardaten anzuwenden.
Wow! Jetzt erklär mir das mal, weiß grad nicht warum du stripslashes() anwenden willst?
Das PHP-Feature Magic Quotes maskiert Daten, so dass man sie in den Kontext "Datenbank" bringen kann. Allerdings gibt es nicht "Datenbank" sondern "MySQL-Datenbank", "Postgres-Datenbank", "Oracle-Datenbank" usw. Und es gibt noch eine Menge andere Kontexte, wie "HTML", "Datei" und "Socket", die die Daten nicht gemäß "Datenbank"-Kontext maskiert haben möchten.
Magic Quotes verändern die Eingabedaten für ein einziges generisches Ausgabemedium, ohne die vom Programmierer wirklich verwendeten Medien zu berücksichtigen. Sie sollen dabei helfen, SQL-Injection zu verhindern, setzen aber bei den Eingabedaten an, und das ist die falsche Stelle. Das Maskieren der Daten ist im Prinzip nur zu dem Zeitpunkt sinnvoll, an dem diese Daten in diesen Kontext gebracht werden sollen, also unmittelbar vor dem Versenden. Sind die Daten schon eher maskiert lässt es sich gegebenenfalls nicht mehr richtig mit ihnen arbeiten. ("Blödsinn" != "Blödsinn")
echo "$verabschiedung $name";
-
Magic Quotes verändern die Eingabedaten für ein einziges generisches Ausgabemedium, ohne die vom Programmierer wirklich verwendeten Medien zu berücksichtigen. Sie sollen dabei helfen, SQL-Injection zu verhindern, setzen aber bei den Eingabedaten an, und das ist die falsche Stelle. Das Maskieren der Daten ist im Prinzip nur zu dem Zeitpunkt sinnvoll, an dem diese Daten in diesen Kontext gebracht werden sollen, also unmittelbar vor dem Versenden. Sind die Daten schon eher maskiert lässt es sich gegebenenfalls nicht mehr richtig mit ihnen arbeiten. ("Blödsinn" != "Blödsinn")
War mir bekannt. Zumindest im Ansatz. Und dennoch verwende ich addslashes() bevor ich Daten in einer Datenbank speichere und stripslashes() bevor ich sie wieder ausgebe. Wenn die Ausgabe dann noch in HTML geschehen soll kommt anschließend noch htmlentities(). (Also gemäß deinen Erläuterungen)
("Blödsinn" != "Blödsinn")
Ist wahr. Aber was hat das mit escapen zu tun? Wenn ich 'Blödsinn' escape, ist das immernoch 'Blödsinn'!
Aus 'Der Code lautet: "addslashes($string);"!' wird z.B.
'Der Code lautet: "addslashes($string);"!'Ich habe jedoch auch einige Projekte gesehen, die prüfen ob Magic Quotes verfügbar ist und dann, wenn vorhanden, gänzlich auf das Escapen verzichten.
Wie wichtig sind nun addslashes() und der Rest?
mfg dolito
-
echo $begrüßung;
Und dennoch verwende ich addslashes() bevor ich Daten in einer Datenbank speichere
addslashes() ist für MySQL nicht optimal, weil es nicht alle nötigen Zeichen berücksichtigt. Die Funktion, um die Daten speziell für MySQL zu escapen, lautet mysql_real_escape_string().
und stripslashes() bevor ich sie wieder ausgebe.
Dann hast du nicht verstanden, wie das mit dem Escapen funktioniert. SQL-Server nehmen Befehle und Daten auf einer Text-Schnittstelle entgegen. Um String-Daten von den Befehlsteilen zu unterscheiden, müssen sie (meist) in Anführungszeichen gesetzt werden. Wenn nun diese Anführungszeichen innerhalb der Daten vorkommen, müssen sie so gekennzeichnet werden, dass sie nicht als das Endezeichen der Daten interpretiert werden. Für ein paar weitere Zeichen gibt es ebenfalls spezielle Notationen.
Wenn Daten aus der SQL-Datenbank kommen, dann läuft das nicht mehr über die Eingabe-Text-Schnittstelle. Man bekommt die Daten in Roh-Form zurück. Die Ersatzschreibweisen, die für die Notation der Daten auf der Text-Schnittstelle verwendeten wurden, ist nicht mehr vorhanden. Sendet man ein ' bekommt man ' zurück, sendet man \n bekommt man einen "richtigen" Zeilenumbruch zurück.
("Blödsinn" != "Blödsinn")
Ist wahr. Aber was hat das mit escapen zu tun? Wenn ich 'Blödsinn' escape, ist das immernoch 'Blödsinn'!
Das war ein allgemeines Beispiel. Wenn Daten zu früh in den Ausgabe-Kontext gebracht werden, sind sie teilweise für eine andere Weiterverarbeitung unbrauchbar geworden.
Beispiel: In ein Feld dürfen nur x Zeichen eingegeben werden. Jemand gibt einen Text mit genau x Zeichen ein, die jedoch durch Magic Quotes mit zusätzlichen Zeichen versehen werden. Der String ist nun x + n Zeichen lang. Um die Daten zu prüfen, und beim Zählen nicht x + n sondern x zu erhalten, muss man entweder eine "gestripslashte" Kopie anlegen oder bei diesem und jedem weiteren Verarbeitungsschritt stripslashen.
Ich habe jedoch auch einige Projekte gesehen, die prüfen ob Magic Quotes verfügbar ist und dann, wenn vorhanden, gänzlich auf das Escapen verzichten.
Der bessere Weg wäre, wenn man die Magic Quotes nicht ausschalten kann, deren Auswirkungen für alle GPC-Eingabedaten[*] am Script-Anfang rückgängig zu machen und dann die für den jeweiligen Ausgabekontext optimalen Umwandlungen zu verwenden.
Wie wichtig sind nun addslashes() und der Rest?
Magic Quotes sind dafür gedacht, um dem gänzlich unbedarften PHP-Anwender ein klein wenig Sicherheit zu bieten. addslashes() ist da, um die von Magic Quotes verwendete Umwandlung dem PHP-Anwender zur Verfügung zu stellen. Ansonsten fällt mir kein wirklich nützliches Beispiel ein, bei dem adslashes() ausreichend wäre.
echo "$verabschiedung $name";
[*] GPC: GET, POST, COOKIE
-
-
-
-
-
-
-
Hallo Johannes,
Hallo,
für das Gästebuch(wird sicher kaum frequentiert werden ist mehr ne prestigesache)schreibe ich die daten per fwrite in meine datei guestbook.dat.php, kann daraus ein sicherheitsrisiko entstehen ...Was Dateioperationen betrifft, solltest du dich mal mit flock() vertraut machen.
Wenn deine Gästebuch-Benutzer beliebige Texte eintragen können, solltest du mit htmlentities() dafür sorgen, das HTML-Sonderzeichen entwertet werden. Spezielle Eingabefelder, wie E-Mail, Homepage und den ganzen Gästebuch-Kram solltest du auch auf sinnvolle Eingaben prüfen. Ich bevorzuge dazu preg_match(), aber es gibt dafür auch noch andere Funktionen.
Wichtige Aspekte dieser Sicherheitsproblematik werden auf der Website der PHP-FAQ erläutert:
http://www.php-faq.de/ch/ch-security.html
http://www.php-faq.de/q/q-sicherheit-parameter.htmlMffG
EisFuX--
Auch meine Hosenträger sind intelligent, in dem Sinne, das man sie regulieren kann. Sie besitzen ein adaptives Verhalten.
Stanisław Lem
-
-
-
Aus meinen Lesezeichen:
http://www.securephpwiki.com/index.php/Main_Page
http://www.hardened-php.net/articles/PHPUG-PHP-Sicherheit-Parametermanipulationen.pdfViel Glück ;)
Gruß
Krueger