Update einer Chatfunktion

[j4nk3y]

Hey,

Das verstehe ich wohl aber ich will ja verhindern das ein < oder ähnliches in die Datenbank kommt.

und genau das ist der falsche Ansatz. Warum sollte man bestimmte Zeichen ausschließen, wenn man sie problemlos verwenden kann, solange man entsprechende Regeln einhält?

Stimmt. Vielleicht gehe ich einfach nur nicht generell genug an die Sache ran, sondern weiss wo ich was benötige oder eben nicht erwarte.

Warum sollte man Markup in einer DB speichern?

Warum nicht? - Okay, meist ist es sinnvoller, Informationen formatneutral zu speichern, also am besten als Plaintext. Aber es muss ja nicht unbedingt Markup sein. Wie dedlfix gezeigt hat, genügt ja schon ein '<', das als mathematisches Zeichen gemeint ist. Und dieses Zeichen kann gefahrlos in die DB geschrieben werden. Erst beim Auslesen, wenn der Text in HTML eingefügt werden soll, muss dieses Zeichen maskiert werden.

Verstanden, Danke!

Und weil jeder individuelle Kontext (HTML, Javascript, SQL, CSS, ...) seine eigenen Sonderregeln und Sonderzeichen hat, muss man die Information immer dem Zielkontext entsprechend aufbereiten. Teilweise hat PHP fertige Funktionen dafür, die man an der richtigen Stelle einfach benutzen kann.

Natürlich gehe ich von meinem einfachen Fall aus und es ist interessant das einem noch viel mehr Möglichkeiten zu Verfügung stehen bei denen man dann auch einiges beachten muss. Nur ich sehe im Moment nicht die Notwendigkeit mir alles aneignen zu müssen was möglich und erst damit nötig ist.

Das halte ich für eine ungünstige Denkweise. Wenn du in deinem überschaubaren Fall Vereinfachungen machst, ist die Gefahr groß, dass du bei anderen Projekten aus Gewohnheit genauso verfährst. Warum sollte man es sich also nicht gleich "richtig" angewöhnen?

Naja andere Projekte werden es wohl nie werden dafür studiere ich das falsche.

Und es wäre hilfreich wenn mal ein Beispiel kommt was ich auch versteh

Wenn du etwas nicht verstehst, frag bitte gezielt nach. Kein Problem. Ich versteh nämlich nicht, was für ein Beispiel du eigentlich noch brauchst.

Ich meine nur für welchen Fall ich was machen muss. Aber viele sehe ich eben jetzt nicht das ich sie mal brauchen könnte, daher würde ich wenn so vorgehen, dass ich mir den speziellen Fall dann anschaue wenn ich ihn brauche.

if(isset($_POST['chat']) && !empty($_POST['chat']))
{
	$writer = mysqli_real_escape_string($_SESSION['user_name']);
	$chat = mysqli_real_escape_string($_POST['chat']);
	
	$insert_message = sprintf(
	'INSERT INTO chat ('
    . 'message_writer, message, message_date'
    . ') VALUES ('
    . '\'%1$s\', \'%2$s\', \'%3$s\''
    . ')',
    $_SESSION['user_name'],
    $_POST['chat'],
    time());
	if($db -> query($insert_message) === TRUE)
	{
		$db -> commit();
	}
	else
	{
		//error_log! $create_db_connect->error.
	}
	
	
	exit();
}

Hier hast du dir selbst ein Bein gestellt: Warum kopierst du die Eingabedaten $_SESSION['user_name'] und $_POST['chat'] erst in andere Variablen um und maskierst sie dabei korrekt, benutzt aber im SQL-Statement doch wieder die unmaskierten Originaldaten? Ich gehe mal davon aus, dass in diesem Beispiel eigentlich $writer und $chat in der sprintf-Funktion stehen sollten.
Und mit dieser Korrektur gilt: Solange diese Anweisungen als zusammenhängender Block (z.B. in eine Funktion gekapselt) stehen, ist das völlig in Ordnung. Dann ist ja die kontextspezifische Maskierung ungefähr da, wo sie hingehört. Nämlich unmittelbar vor der Übergabe der Daten an die DB.

Ja ist beim kopieren schief gegangen, sry. Danke für den Hinweis. Ich denke mir eben nur, dass das nichts anderes ist als das, was ich vorher schon gemacht hab:

if($_POST)
{
	foreach($_POST as $key=>$value)
	{
		$_POST[$key]= mysqli_real_escape_string($value);
				
		if (stripos($_POST[$key], "<script") !== false)	//Check more?
		{
			unset $_POST[$key];
			//Warn or delete User!
		}
	}
}

Wie auch immer lasse ich das sein und mache es in jedem fall einzeln.

Und in der $_POST['chat'] steht meinetwegen <script>böser.pfad</script>, was kommt in der Datenbank an?

Genau das, was geliefert wurde: "<script>böser.pfad</script>"
Bis hierher kein Problem.

Ja stimmt.

Danke für die Erklärungen und die Mühe.

Gruß Jo