nicht angemeldet
Wie unterbinde ich, das PHP Code über ein Formluar kommt
0 0 0 0 
Matthias Apsel
0
Wie unterbinde ich, das PHP Code über ein Formluar kommt
Also ich habe ein Formular das man ausfüllen kann. Die Daten werden mittels
mysql_real_escape_string in die MYSQL Datenbank geschrieben, aber wenn ich dort einen php Code reinschreibe, wird dieser vieleicht beim ausgeben der Datenbank ausgeführt.
Beispiel: Ich habe ein Textfeld in meinem Formular
<textarea></textarea>
Dort gebe ich zum Beidpiel folgendes ein:
</textarea>'; $i=1; echo $i; echo'<textarea
wenn es dann wieder aufgerufen wird, bekomme ich wahrscheinlich die 1.
Wie kann ich das verhindern!!
Michi
-
Hello,
zur Frage aus dem Subject: Kein Formular anbieten.
mysql_real_escape_string in die MYSQL Datenbank geschrieben, aber wenn ich dort einen php Code reinschreibe, wird dieser vieleicht beim ausgeben der Datenbank ausgeführt.
mysql(i)_real_escape_string ist nur relevant für die Textschnittstelle von MySQL - aber von Dir durchaus richtig angewandt.
-> Artikel "Kontextwechsel" im SelfHTML-Wiki.
Dort gebe ich zum Beidpiel folgendes ein:
</textarea>'; $i=1; echo $i; echo'<textarea
wenn es dann wieder aufgerufen wird, bekomme ich wahrscheinlich die 1.
"Es" wird nicht "aufgerufen", sondern ein Datenbankinhalt wird per HTML ausgegeben.
Hierzu musst Du nur wieder den Kontextwechsel berücksichtigen. Die bloße Ausgabe von Daten führt aber bei PHP nicht zur Interpretation als Befehl. Dazu wäre ein "include", "require" oder "eval" notwendig.-> Artikel "Kontextwechsel" im SelfHTML-Wiki.
Wenn Du allerdings die übertragenen Daten aus dem Formula auf der Platte speicherst, dann kommen die Probleme von "Uplods" hinzu.
-> Artikel "Fileupload" im SelfHTML-Wiki.
Der gilt auch für jeglichen anderen Inhalt, der per Post, Put, oder Get auf den Server gelangst, wenn er dort gespeichert wird und anschließend irgendwie per HTTP/s zugänglich wird.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Also rein mit
mysql_real_escape_string in die MYSQL Datenbank
und raus in die Freiheit mit
nl2br(htmlspecialchars(AUS DER DATENBANK))
Aber wenn ich den Code der über ein Formular eingeben wird, nicht in die Datenbank schreiben möchte, kann ich in wahrscheinlich mit strip_tags einigermassen bereinigen, oder?
Michi
-
Hello,
mysql_real_escape_string in die MYSQL Datenbank
und raus in die Freiheit mit
nl2br(htmlspecialchars(AUS DER DATENBANK))
Das nl2br() kannst Du dir auch noch schenken, wenn Du per CSS den passende Style wählst:
whitespace:pre-wrapkönnte da schon helfen.
Aber wenn ich den Code der über ein Formular eingeben wird, nicht in die Datenbank schreiben möchte, kann ich in wahrscheinlich mit strip_tags einigermassen bereinigen, oder?
Kommt darauf an, was Du damit machen willst.
Wenn der vermeintliche Code per Formular ankommt im Script, dann wird er ja vermutlich erstmal in einem Element von $_POST oder $_GET landen.Solange du nichts weiter damit machst, ist er in diesem Speicherblock "gefangen". Erst, wenn Du mit dem String etwas unternimmst, wird es spannend.
Die Ausgabe des Strings auf die HTML-Ausgabe kann aber bestenfalls Irritationen beim Browser verursachen, wenn Du nicht das htmlspecialchars() benutzt.
Die einbindung in den Code im weiteren Script oder das Speichern des Codes als oder in einem eigenständigen Dokument kann aber schwerwiegende Folgen haben.
Beim Aufruf des Dokumentes per HTTP/s könnte der Code ggf. aktiv werden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Die Ausgabe des Strings auf die HTML-Ausgabe kann aber bestenfalls Irritationen beim Browser verursachen, wenn Du nicht das htmlspecialchars() benutzt.
Bei php-Code wird es wohl so sein, anderes kann aber schlimmere Folgen haben, auch wenn die ohne Speicherung nur den betreffen, der die Daten geschickt hat. Hm oder jemanden, der sich danach an das Browserfenster setzt.
-
Hello,
Die Ausgabe des Strings auf die HTML-Ausgabe kann aber bestenfalls Irritationen beim Browser verursachen, wenn Du nicht das htmlspecialchars() benutzt.
Bei php-Code wird es wohl so sein, anderes kann aber schlimmere Folgen haben, auch wenn die ohne Speicherung nur den betreffen, der die Daten geschickt hat. Hm oder jemanden, der sich danach an das Browserfenster setzt.
Das ist dann aber die Client-Seite.
Dem OP ging es, so habe ich das gedeutet, um die Angreifbarkeit des Servers.
Und da kann ich nur immer wiederholen, die größte Lücke stellen immer noch Uploadscripts dar. Die zweitgrößte steckt dann in nicht abgesicherten Datenbankabfragen, bei denen einfach Requestparameter in die Abfrage eingebunden werden. Darum ja das Escapen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Das ist dann aber die Client-Seite.
Dem OP ging es, so habe ich das gedeutet, um die Angreifbarkeit des Servers.
Stimmt aber da Du von Ausgabe und "bestenfalls Irritationen beim Browser" geschrieben hast, hast Du eine Aussage dazu gemacht.
-
-
-
-
Om nah hoo pez nyeetz, Michi!
Aber wenn ich den Code der über ein Formular eingeben wird, nicht in die Datenbank schreiben möchte, kann ich in wahrscheinlich mit strip_tags einigermassen bereinigen, oder?
siehe t216811m1487705 f.
Matthias
-
-
zur Frage aus dem Subject: Kein Formular anbieten.
Damit verhindert er nur, daß Code aus seinem Formular ankommt.
Die Antwort lautet: Gar nicht, solange der Server erreichbar ist.
-
Hello,
zur Frage aus dem Subject: Kein Formular anbieten.
Damit verhindert er nur, daß Code aus seinem Formular ankommt.
Die Antwort lautet: Gar nicht, solange der Server erreichbar ist.
Stimmt auch wieder.
Es reicht ja ein Script oder ein Prozess auf dem Server, dass Parameter eines Requests annimmt und ggf. verarbeitet... Den "normalen" Request (Get) lasse ich hier jetzt mal außer Betracht, aber selbst der könnte bei falsch konfiguriertem Webserver schon die erste Lücke darstellen. *ohoh*
Ein Formular muss es dazu gar nicht geben.
Aber die Frage war wohl eher praktisch orientiert und nicht so theoretisch, wie wir sie jetzt umgedeutet haben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
