Forum: PC-Programmierung Daten "Konsistenz" zwischen mysql und html?


von Markus (Gast)


Lesenswert?

Ich weiß nicht ob ich einfach nur nach dem falschen Wort suche, oder 
eine web Anwendung dafür nicht geeignet ist, aber ich finde nichts so 
wirklich was dazu.

Wenn man etwas in einer Datenbank gespeichert hat, mysql, und dies über 
den üblichen php, ajax, javascript Weg in ein html Feld lädt (Textfield 
meistens) und das dann zurück speichert, geht das noch einigermaßen gut 
mit normalen Zeichen A-Z und 0-9.

Der Sinn soll natürlich sein, Daten zu ändern, so wie das phpmyadmin 
macht, nur halt auf einer eigenen website.

Aber was ist, wenn man den Text auch mit Sonderzeichen, newline, Tabs, 
etc. hat.

Gibt es hierfür eine einfache Lösung oder kommt man um das Durchdenken 
jeglicher Kodierungen für die ganzen Zwischenschritte einfach nicht drum 
rum?

Kann man von mysql jegliche Datensätze zu html mit etwas "durchreichen" 
ohne sich um die vielen Kodierungen, Escape, etc. in den 
Zwischenschritten Gedanken machen zu müssen?

von ThomasW (Gast)


Lesenswert?

Bei der Verbindung zur Datenbank (in deinem PHP -Skript) kannst Du den 
gewünschten Zeichensatz mitgeben. Wenn du dort den gleichen Zeichensatz 
verwendest wie auf deiner Webseite, dann gibt es normalerweise keine 
Probleme.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

> Gibt es hierfür eine einfache Lösung oder kommt man um das Durchdenken
> jeglicher Kodierungen für die ganzen Zwischenschritte einfach nicht drum
> rum?

Den Zeichensatz bzw. das Encoding (heute üblicherweise UTF-8) der 
Webseite ansich legt man im HTML-Header und bei der Erstanlage der DB 
fest, das ist eigentlich ungefährlich.

Aber nicht nur wegen der Optik, sondern vor Allem aus Sicherheitsgründen 
sollte man durch Zwischenschalten von Filterfunktionen dringlichst 
darauf achten, dass ausschließlich "unbedenkliche" Zeichen und 
Zeichenfolgen (also kein HTML, Javascript, SQL etc.) den Weg in die 
Datenbank finden. Einem einfachen "escapen" alleine würde ich nicht 
vertrauen.

Wenn du deiner Sache sicher bist, genügt es ja, einfach generell jede 
Eingabe auf dem Wege vom Webformular in die DB an zentraler Stelle zu 
filtern. Wenn "Mist" gar nicht erst in die DB gelangt, kann auch keiner 
heraus kommen.

Lieber etwas zu restriktiv als hinterher überrascht zu werden ...

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Ich sehe das komplett umgekehrt. Bei Sachen wo man klar sagen kann, was 
gültig ist und was nicht (z.B. eine Zahl sollte nur Ziffern haben), ist 
Validierung und sanitizing der Daten OK und wichtig. Aber in allen 
anderen Fällen (Name, Text, etc.) sollte man keine derartigen Änderungen 
am Input vornehmen. Das ist unnötig und verärgert nur die Nutzer.

Wann auch immer es um Freiform Text geht, sollte man diesen Escapen, und 
zwar ausschliesslich direkt vor / bei der Serialisierung. Man muss immer 
damit rechen, dass variierende Daten schlecht sein können. Und sobald 
man die Daten erstmal versehentlich dreifach mit Sanitizing und Escaping 
ruiniert hat, bekommt man die nicht mehr ganz sauber / wie sie mal 
waren. Darum, nur Escapen, aber genau da wo nötig.

Idealerweise macht man das aber gar nicht selbst. Bei vielen Templating 
Engines wo man eine {variable} einfügt ist das Escapen der Default. (Bei 
reinem PHP für templating leider nicht, da muss man selber 
HTMLEntities() aufrufen, aber es gibt sicher gute PHP templating 
Engines, die einem das abnehmen).

Noch besser sind dedizierte APIs. MySQL hat prepared statements, damit 
sind Queries und unsichere Daten strikt getrennt, und man muss sich 
selbst keine Gedanken mehr darüber machen.

Auf Browser / Client Seite, gibt es den DOM. Manchmal etwas verbose, 
aber bei Sachen wie x.innerText=bla; 
x.appendChild(document.createTextNode(bla)); usw. da kann nichts 
unerwartetes passieren. Man kann auch ein Template nehmen, und dann per 
DOM Instanzieren und Werte einfüllen. Reacts JSX ist da was dazwischen 
Templating und DOM, auch ein nettes Konzept. Auch Serverseitig kann man 
mit einem guten DOM auch dem Serializierer das escaping überlassen. Das 
muss auch kein voller Browser DOM shim sein, ein simpler DOM mit 
Elementen und Text Nodes reicht meisst schon. Wobei DOM Serialisierung 
funktioniert besser bei XML als bei HTML.

HTML basiert auf SGML, und erfordert bei Serialisierung / 
Deserialisierung dass diese jedes Element kennen, um korrekt zu 
funktionieren. Das ist niemals der fall, denn es kommen auch immer 
wieder neue dazu (wobei in der Regel zum glück keine self-closing tags, 
vermutlich genau darum). Gewisse HTML Elemente sind self-closing, manche 
können nur gewisse andere enthalten, etc. Und dann gibt es noch 
sonderregeln bei Elementen wie <script>, <style> und <template>. In 99% 
deer Fälle geht das trotzdem gut. Solange man Nutzer nur Texte & 
bestimmte Attribute setzen lässt, ist das ok. Aber wenn man ihn tags / 
HTML Dokumente erstellen lässt, muss man das einschränken, und man muss 
höllisch aufpassen, was man durchgehen lässt. Damit meine ich nicht nur, 
dass er keine <script> tags nutzen kann, das reicht nicht. Bei Browsern 
z.B. gibt es Situationen, bei denen y.innerHTML=x.innerHTML NICHT zum 
selben DOM Tree führen! (Was ich eigentlich auch falsch finde, aber es 
gibt da wohl irgendwelche legacy gründe, warum man das nicht mehr ändern 
kann). Wenn man also z.B. Formatierungen zulässt, am besten entweder 
kein HTML zum speichern nehmen (eventuell stattdessen Markdown, oder ein 
JSON oder so), oder notfalls ein XHTML Subset verwenden, wo nur wenige 
Tags und Attribute gewhitelistet sind. Arbitrary HTML sanitization ist 
eine der schwierigsten Sachen überhaupt, das kann man sonst eigentlich 
nur verkacken, und sollte man deshalb vermeiden.

Und zuletzt noch zur Encoding. Das ist simpel. Immer überall konsistent 
UTF-8 nehmen, dann ist alles gut. Aber nur dann.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Frank E. schrieb:
> Aber nicht nur wegen der Optik, sondern vor Allem aus Sicherheitsgründen
> sollte man durch Zwischenschalten von Filterfunktionen dringlichst
> darauf achten, dass ausschließlich "unbedenkliche" Zeichen und
> Zeichenfolgen (also kein HTML, Javascript, SQL etc.) den Weg in die
> Datenbank finden. Einem einfachen "escapen" alleine würde ich nicht
> vertrauen.

Ich befürchte mal so tief ist der TO noch garnicht in der Materie drin, 
wenn es noch mit Zeichencodierung kämpft:
- https://de.wikipedia.org/wiki/SQL-Injection
- https://www.php.net/manual/de/security.database.sql-injection.php

von DPA (Gast)


Lesenswert?


von mm (Gast)


Lesenswert?


Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.