Update einer Chatfunktion

[Der Martin]

Hallo,

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?

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.

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?

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.

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.

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.

Und wieso entschärft:

 $output = "";
require_once('db_connect_function.php');

$get_messages = "Select * FROM (Select message_writer, message, message_date FROM chat ORDER BY message_date DESC Limit 50 ) chat ORDER BY message_date ASC";

if ($result = $db->query($get_messages)):
while ($row = $result->fetch_assoc()): 
?>
    <article>
      <footer>
        <time datetime="<?php echo date('c', $row['message_date']); ?>"><?php echo date('H:i:s', $row['message_date']); ?></time>
        <span class="author"><?php echo htmlspecialchars($row['message_writer']); ?></span>
      </footer>
      <p class="message"><?php echo htmlspecialchars($row['message']); ?></p>
    </article>
<?php
endwhile;
else:
	//error_log! $create_db_connect->error.
endif;

das nicht die Ausgabe?

Tut es doch. Durch die Verwendung von htmlspecialchars() werden die HTML-Sonderzeichen in &lt; und &gt; umgewandelt, so dass in der Browser-Ausgabe wieder "<script>böser.pfad</script>" steht. Als reiner Text, der keinen Schaden anrichtet.

Ciao,
 Martin