Formular Sicherheit

[lnqlorlouz]

Hey,

hab eine kleine Frage. Ich komme gerade nicht drauf, wie ich das nochmal beheben kann.
Ich habe ein Formular und speichere die Einträge so:

PHP Code:

$username = $_POST['username'];
mysqli_real_escape_string($username);
$message = $_POST['message'];
mysqli_real_escape_string($message);
date_default_timezone_set('Europe/Berlin');
$timestamp = time(); 
// $date = date("d.m.Y - H:i",$timestamp);

$sql = "INSERT INTO test (username, message, date)
VALUES ('$username', '$message', '$timestamp');"; 


1. Bringt mir das mysqli_real_escape_string an der Stelle etwas?
2. Wenn ein User bzw. Ich als Tester das hier eingebe:

<meta http-equiv="refresh" content="5; URL=http://de.selfhtml.org/">

und ich gebe das Formular aus, auf meine Seite, dann wird man weitergeleitet auf die selfhtml.org Seite. Wie kann ich solche Befehle unnützlich machen bzw. das es die erst gar nicht einträgt?

Und ja ich weiß ich kann da noch mehr absichern, trim, if(empty) etc, kommt noch.

Grüße

[NotEnoughForYou]

So wie du es momentan hast nicht. Würdest du schreiben:

PHP Code:

$message = mysqli_real_escape_string($_POST['message']); 


dann schon. Denn so wie du es jetzt hast wird deine escapte Expression nirgends gespeichert und auch nicht übergeben.

Alternativ kannst du auch die prepare Funktion von mysqli nutzen, oder auf PDO umsteigen und dort die prepare Funktion nutzen.

Bezüglich der Weiterleitung:
Solche Dinge (xss-Lücken) lassen sich beispielsweise über htmlspecialchars / htmlentities o.ä umgehen. Natürlich kannst du dir auch dein eigenes Pattern schreiben und dann die Eingaben prüfen.

[lnqlorlouz]

Hab ich mir doch fast gedacht, dass das so nicht gehen kann.

Stimmt! Htmlentities und htmlspecialchars hatte ich vor einer Weile mal benutzt, wusste aber nicht mehr wie die Begriffe heißen.

Danke!

[RecK]

Stopp! HTMLEntities sind HTML-Elemente.
Das hat im Groben erstmal nichts mit mysql_escape zu tun.
Das eine (mysqll_escape) dient zur Präventation von SQL-Injection.
Ein Beispiel dafür:
Du nimmst eine ID via GET-Parameter entgegen. Nun kann ich,
wenn du die ID ohne mysql_escape in das WHERE schmeißt SQL dazu packen.
Beispiel (statt id=1 dann id=1 OR name!='') so nun kriege ich nicht ide Benutzer mit der ID,
sondern mit der ID oder wo der Name nicht leer ist ... Denke das brauch man nicht
weiterführen und es ist klar, das sowas ssehr gefährlich ist, besonders
wenn Fehlermeldungen auf der Seite angezeigt werden (Connection fails, ..)

HTMLEntities wiederum escaped JavaScript-Tags und unerlaubte HTML-Elemente.
Das ist gefährlich, wenn ich in ein Gästebuch JavaScript einbinde, beispiel:
<script>window.location.href="böse seiite.de";</script>
Wenn der Eintrag so in die Datenbank kommt, werden alle Benutzer nun auf eine Seite
kommen, worauf meine Umleitung per JavaScript referenziert..Gaanz böse!
So werden auch Portscans auf Webseiten untergebracht usw.

Sehr wichtig und das eine ersetzt niemals das andere.
In PHP5 übernehmen die filter_input Funktionen glaube den Aufruf beider Funktionen.

Wie bereits gesagt gibt mysql_escpae einen String zurück,
der gespeichert und verwendet werden muss
Wenn du PHP>5.2 bist solltest du nicht mehr $_POST verwenden!



lg, Tim

[lnqlorlouz]

Originally Posted by RecK

[...]

Alles klar. Das mit dem SQL-Injections kenne ich bereits. Hab das nun auch gut gelöst bekommen:
insert.php

PHP Code:

$message = mysqli_real_escape_string($conn, $_POST['message']);
$message = trim($message);
if (empty($message)) {
die (''.header("Location: formular.php?info=forgotmessage").'');}
$message = htmlspecialchars($message); 


Jetzt ist es nicht mehr möglich (ich hab's probiert und denke es), eine Weiterleitung zu machen. Eine SQL-Injection ist ebenso nicht möglich, da escaped wird. Vielleicht hast du ja noch Tipps, schneller, besser?

Habe mein Formular per HTML, nicht per Java geschrieben. Java bin ich noch nicht groß angegangen, nur grob.

[Mikesch01]

Originally Posted by RecK

Wie bereits gesagt gibt mysql_escpae einen String zurück,
der gespeichert und verwendet werden muss
Wenn du PHP>5.2 bist solltest du nicht mehr $_POST verwenden!

Warum sollte er das denn nicht mehr verwenden?!

PDO ist die Zukunft und erleichtert dem Programmmierer die Arbeit, etliche Sicherheitsprobleme von selbst zu lösen.

[NotEnoughForYou]

Originally Posted by RecK

Stopp! HTMLEntities sind HTML-Elemente.
Das hat im Groben erstmal nichts mit mysql_escape zu tun.
Das eine (mysqll_escape) dient zur Präventation von SQL-Injection.
Ein Beispiel dafür:
Du nimmst eine ID via GET-Parameter entgegen. Nun kann ich,
wenn du die ID ohne mysql_escape in das WHERE schmeißt SQL dazu packen.
Beispiel (statt id=1 dann id=1 OR name!='') so nun kriege ich nicht ide Benutzer mit der ID,
sondern mit der ID oder wo der Name nicht leer ist ... Denke das brauch man nicht
weiterführen und es ist klar, das sowas ssehr gefährlich ist, besonders
wenn Fehlermeldungen auf der Seite angezeigt werden (Connection fails, ..)

HTMLEntities wiederum escaped JavaScript-Tags und unerlaubte HTML-Elemente.
Das ist gefährlich, wenn ich in ein Gästebuch JavaScript einbinde, beispiel:
<script>window.location.href="böse seiite.de";</script>
Wenn der Eintrag so in die Datenbank kommt, werden alle Benutzer nun auf eine Seite
kommen, worauf meine Umleitung per JavaScript referenziert..Gaanz böse!
So werden auch Portscans auf Webseiten untergebracht usw.

Sehr wichtig und das eine ersetzt niemals das andere.
In PHP5 übernehmen die filter_input Funktionen glaube den Aufruf beider Funktionen.

Wie bereits gesagt gibt mysql_escpae einen String zurück,
der gespeichert und verwendet werden muss
Wenn du PHP>5.2 bist solltest du nicht mehr $_POST verwenden!



lg, Tim

Es wurde doch auch nicht behauptet, dass htmlentities was mit sql injection zu tun hätten?

[RecK]

Originally Posted by NotEnoughForYou

Es wurde doch auch nicht behauptet, dass htmlentities was mit sql injection zu tun hätten?

Sorry hatte das in Klammern (xss-Lücke) nicht gelesen und dachte du beziehst dich mit htmlentities auf mysql_escape und dessen Nutzung beziehst Mein Fehler!

Und bei $_POST geht es auch nicht um PDO oder sonstige Treiber,
sondern um die PHP super-globals die seit PHP5.2+ nicht mehr direkt angesprochen werden sollen, sondern filter_input erwendet werden. Diese Funktion übernimmt direkt wieder Arbeit für den Programmier und hat nichts mit PDO zu tun. Das gilt auch für Cookies, GET, Request, Server -globals ...

[Mikesch01]

Meine Frage sollte eigentlich eigenständig sein^^

Wollte das mit PDO noch zusätzlich erwähnen.

Wo steht denn, dass man nun filter_input benutzen soll? Ich glaube kaum, dass die Global Variablen in nächster Zeit deprecated werden.

Gruß

[RecK]

Das sie als deprecated makiert werden ist sehr unwahrscheinlich.
Im Hintergrund von filter_input werden diese ja auch verwendet.
Gut ein Standard ist es nicht, jedoch bietet es PHP 5 an und daher sollte man es auch nutzen,
bzw man tut denke ich nichts falsch, wenn man PHP validieren lässt

[lnqlorlouz]

Originally Posted by RecK

Das sie als deprecated makiert werden ist sehr unwahrscheinlich.
Im Hintergrund von filter_input werden diese ja auch verwendet.
Gut ein Standard ist es nicht, jedoch bietet es PHP 5 an und daher sollte man es auch nutzen,
bzw man tut denke ich nichts falsch, wenn man PHP validieren lässt

Da ich das mit dem $_POST draufhabe und kaum Zeit für die neuen Anwendungen/Funktionen habe bzw. mich nicht groß damit beschäftigen will, reicht mir das was ich bisher weiß und kann. Aber das scheint eine gute Idee zu sein, sich das mal anzuschauen. Wohl nicht umsonst wurde diese - neue - Funktion implementiert. Mal schauen was ich rausholen kann und ob Sie mir zusagt. Natürlich wenn ich Zeit habe... Danke euch.