HTML in cookie speichern
devian
- html
Hallo liebe Community,
ich habe eine Frage bezüglich der Sicherheit meiner Webseite.
Ich speicher einen HTML Code in eine Datenbank. Innerhalb dieses HTML Codes sind ganz viele Termine gespeichert, die ich zuvor aus der Datenbank ausgelesen habe. Da nicht 10 Cookies für 10 Termine verwenden wollte habe ich einfach den HTML-Code indem die Termine ausgegeben werden in einen Cookie gespeichert. Das Cookie wird mit urlencode verschlüßelt und vor der ausgabe mit urldecode wieder entschlüßelt. Nun ist es aber dennoch möglich eine HTML Injektion zu machen oder?
Wie verhindere ich dies und gebe gleichzeitig meinen HTML-Code ungesetzt aus?
Wenn ich htmlentities verwende wird ein Fettgeschriebenes wort ja als <b>Fettgeschriebeneswort</b> ausgegeben.Dass will ich ja aber nicht. Gleichzeitig soll aber fremder Code der in das Cookie gespeichert worden sein könnte nicht codiert werden.
Hat vielleicht einer von euch eine Lösungsidee?
Moin,
Hat vielleicht einer von euch eine Lösungsidee?
Der Sinn eines Cookies ist mir für Deinen Fall nicht klar, kannst Du das mal ein bischen genauer beschreiben: Wozu ein Cookie?
Hotti
Moin,
Hat vielleicht einer von euch eine Lösungsidee?
Der Sinn eines Cookies ist mir für Deinen Fall nicht klar, kannst Du das mal ein bischen genauer beschreiben: Wozu ein Cookie?
Hotti
Meine Seite hat ziemlich viele Benutzer und die Termine werden auf jeder Seite angezeigt. Wenn ich sie jedesmal neu aus der Datenbank laden müsste, so würde das den Server nur überflüssig belasten. Daher wollte ich die Termine in einem Cookie speichern.
Moin,
.. Daher wollte ich die Termine in einem Cookie speichern.
Klar, mach das, gute Idee. Aber nicht den kompletten HTML-Code in den Cookie schreiben. Wenn die Doks in einer DB liegen, gibt es bestimmt eine ID, die würde reichen (oder eine Liste der IDs). Es kommt auch auf die Organisation der Ausgabe an, Du könntest z.B. "Seiten" definieren (von..bis Record), wo dann nur die Seitennummer im Cookie gespeichert ist. Oder "Seiten" entsprechend der Termine nach Datum.
Die Abfrage auf die DB jedesmal neu zu machen ist ok, wenn der Index an der richtigen Stelle sitzt. Der Cookie speichert lediglich die benutzerdefinierte Auswahl, ggf. einen Suchstring o.a. Filter und bleibt damit klein.
Hotti
Hi!
Ich speicher einen HTML Code in eine Datenbank. Innerhalb dieses HTML Codes sind ganz viele Termine gespeichert, die ich zuvor aus der Datenbank ausgelesen habe. Da nicht 10 Cookies für 10 Termine verwenden wollte habe ich einfach den HTML-Code indem die Termine ausgegeben werden in einen Cookie gespeichert.
Wozu machst du denn den ganzen Umstand mit zweifacher Datenbankspeicherung und dann noch im Cookie zwischen Client und Server hin- und hersenden?
Das Cookie wird mit urlencode verschlüßelt und vor der ausgabe mit urldecode wieder entschlüßelt. Nun ist es aber dennoch möglich eine HTML Injektion zu machen oder?
Natürlich, urlencode() ist ja auch keine Verschlüsslung sondern lediglich als kontextgerechte Behandlung gedacht.
Wie verhindere ich dies und gebe gleichzeitig meinen HTML-Code ungesetzt aus?
Wenn etwas beim Client war, so wie deine Cookies, kann der das beliebig manipulieren. Du kannst das nur gegen eine Prüfsumme testen, die natürlich auch nicht vom Client manipuliert werden darf.
Wenn ich htmlentities verwende wird ein Fettgeschriebenes wort ja als <b>Fettgeschriebeneswort</b> ausgegeben.Dass will ich ja aber nicht. Gleichzeitig soll aber fremder Code der in das Cookie gespeichert worden sein könnte nicht codiert werden.
Da musst du dir was überlegen, wie du fremden von eigenem Code unterscheiden kannst. Es ist sicher weniger Aufwand, die Daten neu zu erzeugen, anstatt sie zu analysieren.
Hat vielleicht einer von euch eine Lösungsidee?
Nimm eine Session, wenn du vorübergehend Client-individuelle Daten speichern musst.
Lo!
Entschuldige ich habe mich ein wenig falsch ausgedrückt. Die Daten (Termine) werden aus der Datenbank ausgelesen, in einen html-code eingebunden und in einem cookie gespeichert.
Der Zweck dahinter ist den Sever nicht unnötig zu belasten. Meine Seite hat ziemlich viele Besucher und wenn bei jedem reload der Seite die Termine aus der Datenbank gelesen werden, so ist dies extrem Serverlastig. Daher wollte ich die Termine in einem Cookie speichern und anschließend darüber ausgeben lassen. So spare ich mir die MYSQL-Abfrage.
Wie meinst Du das mit der Session? Diesen Ansatz kann ich nicht ganz nachvollziehen.
Vl sollte ich nur die ausgelesenen Timestamps in ein Array speichern und das Array in einem Cookie speichern. Dann könnte ich prüfen ob das Array nummerisch ist und es so gegen fremdeingriffe absichern. Das Array würde dann nur bei jedem Reload neu verarbeitet werden. So spare ich wenigstens die Abfrage bei jedem Seitenreload.
Hi!
Wie meinst Du das mit der Session? Diesen Ansatz kann ich nicht ganz nachvollziehen.
Bei einer Session werden serverseitig Daten in einem temporären Speicher abgelegt. Der Client wird anhand einer Session-ID identifiziert, die er vom Server zugewiesen bekommt und bei jedem Request mitzusenden hat - zum Beispiel in einem Cookie. Über diese Session-ID findet das Session-Management die zugehörigen Daten auf dem Server.
Die Daten sind gegen direkte Manipulation durch Clients sicher. Lediglich die Session-ID kann er verfälschen. Dann bekommt er im besten Fall eine Session ohne Daten (wie ein Client, dem noch keine Session gestartet wurde) oder die Daten einer fremden Session. Letzteres verhindert man möglichst, in dem man die Session-ID unerratbar gestaltet.
Unter PHP ist das Verwenden von Sessions normalerweise sehr einfach: session_start() an (je)den Script-Anfang stellen und dann auf das Array $_SESSION zugreifen.
Lo!
Hi,
Der Zweck dahinter ist den Sever nicht unnötig zu belasten. Meine Seite hat ziemlich viele Besucher und wenn bei jedem reload der Seite die Termine aus der Datenbank gelesen werden, so ist dies extrem Serverlastig. Daher wollte ich die Termine in einem Cookie speichern und anschließend darüber ausgeben lassen.
M.E. vollkommen falscher Ansatz.
Die Daten per JSON an den Client auszuliefern, wäre eine sinnvollere Alternative.
MfG ChrisB