Daten maskieren vorm Speichern in einer Session?

[Heinzelhund]

Hallo Allesamt,

was denkt ihr, sollte man potenziell unsichere Daten vor dem Speichern in einer Session-Textdatei zuvor maskieren? Und wenn ja, wie? Addslashes() vielleicht?

Wohlgemerkt, dies bezieht sich ausschließlich auf das Speichern in dem serialisierten Array, nicht auf die weitere Verwendung der Daten in einer Datenbank oder als HTML-Ausgabe.

Ciao
Heinzelhund

[EKKi]

Mahlzeit,

was denkt ihr, sollte man potenziell unsichere Daten vor dem Speichern in einer Session-Textdatei zuvor maskieren? Und wenn ja, wie? Addslashes() vielleicht?

Warum?

Weitere Fragen:

1. Was meinst Du mit "potentiell unsicher"?

2. Sollten Daten nicht generell so gespeichert werden, wie sie sind? Bei der VERARBEITUNG und/oder AUSGABE sollten dann entsprechende Überprüfungen stattfinden, das stimmt.

MfG,
EKKi

[Heinzelhund]

Hallo,

Warum?

Da es sich bei dem Inhalt der Session-Datei lediglich um einen serialisierten Array handelt, der von PHP auch irgendwann wieder einmal beim Auslesen geparst werden muss.

Weitere Fragen:

1. Was meinst Du mit "potentiell unsicher"?

Daten, die vom Client kommen.

2. Sollten Daten nicht generell so gespeichert werden, wie sie sind?

Ja, aber ich will sie ja auch nicht maskiert speichern, sondern ggf. nur für den Speichervorgang in den Array maskieren.

Ein serialisierter Array speichert generell einmal die Daten in Form eines Strings, der - falls es sich bei dem zu speichernden Wert um einen String handelt - auch von Anführungszeichen begrenzt wird. Daher läge es doch nahe, dass Anführungszeichen in einem Wert Probleme machen könnten.

Ferner speichert ein serialisierter Array aber auch die Länge eines Strings. Daher könnte ich mir wiederum  auch vorstellen, dass in einem Wert vorkommende Sonderzeichen überhaupt keinerlei Bedeutung haben. Und das ist halt meine Unsicherheit.

Ciao
Heinzelhund

[ChrisB]

Hi,

Ein serialisierter Array speichert generell einmal die Daten in Form eines Strings, der - falls es sich bei dem zu speichernden Wert um einen String handelt - auch von Anführungszeichen begrenzt wird. Daher läge es doch nahe, dass Anführungszeichen in einem Wert Probleme machen könnten.

Daher liegt es wohl ebenso nahe anzunehmen, dass sich die Leute, die serialize/unserialize implementiert haben, darueber auch selbst bereits Gedanken gemacht haben ...

Haben sie auch. Schau's dir doch einfach selber an - nimm ein Array mit ein paar Strings drin, in den Strings moeglicherweise selber wieder Anfuehrungszeichen/Hochkommata, und schau dir an, was serialize daraus macht.

unserialize soll allerdings wohl durchaus unsicher sein koennen [1], wenn die Daten, auf die man es anwendet, nicht aus vertrauenswuerdiger Quelle stammen - also bspw. aus einem Cookie oder GET-/POST-Parametern stammende Daten zu unserialisieren, sollte man sich gut ueberlegen - die koennten so manipuliert sein, dass sie irgendwelche Unzulaenglichkeiten von unserialze ausnutzen. Aber die Daten in einer Session-Datei sind vertrauenswuerdig, da sie in aller Regel auch von deinem Script selber dort hineingeschrieben worden, und das auf dem "normalen" Wege ohne Manipulation geschehen sein duerfte.

[1] Nichts genaues weiss man (ich) da, hab's nur mal gehoert. Bei Interesse ggf. selber nach Quellen/Belegen suchen gehen.

MfG ChrisB

[Heinzelhund]

Hallo,

Daher liegt es wohl ebenso nahe anzunehmen, dass sich die Leute, die serialize/unserialize implementiert haben, darueber auch selbst bereits Gedanken gemacht haben ...

Haben sie auch. [...]

müsste man meinen, aber was ist da schon sicher ;-)

unserialize soll allerdings wohl durchaus unsicher sein koennen [1], wenn die Daten, auf die man es anwendet, nicht aus vertrauenswuerdiger Quelle stammen - also bspw. aus einem Cookie oder GET-/POST-Parametern stammende Daten zu unserialisieren, sollte man sich gut ueberlegen - die koennten so manipuliert sein, dass sie irgendwelche Unzulaenglichkeiten von unserialze ausnutzen.

Eben, da gab's mal irgendwas auf heise.de

Aber die Daten in einer Session-Datei sind vertrauenswuerdig, da sie in aller Regel auch von deinem Script selber dort hineingeschrieben worden, und das auf dem "normalen" Wege ohne Manipulation geschehen sein duerfte.

Warum? Die Daten schreib ich doch mit meinem Script da rein und wo meine Daten herkommen, weiß die Session doch nicht. In meinem Fall ist es eine komplette angefragte URI mit gesamten Anhang, also das so ziemlich unsicherste, das man sich vorstellen kann.

Ciao
Heinzelhund

[ChrisB]

Hi,

Aber die Daten in einer Session-Datei sind vertrauenswuerdig, da sie in aller Regel auch von deinem Script selber dort hineingeschrieben worden, und das auf dem "normalen" Wege ohne Manipulation geschehen sein duerfte.

Warum? Die Daten schreib ich doch mit meinem Script da rein und wo meine Daten herkommen, weiß die Session doch nicht. In meinem Fall ist es eine komplette angefragte URI mit gesamten Anhang, also das so ziemlich unsicherste, das man sich vorstellen kann.

Ob etwas potentiell gefaehrlich ist, kommt immer auf den Kontext an, in dem es verwendet wird. Elektrizitaet bspw. ist zum Beleuchten meiner Wohnung und zum Betrieb meines Computers eine feine Sache - aber wenn ich in die Steckdose pinkle, werden die negativen Effekte vermutlich ueberwiegen ...

Und du hast lediglich einen Textstring vorliegen, der vom PHP-eigenen Session-Mechanismus in eine Session-Datei geschrieben wird - wie dedlfix schon sagte, reichlich unbesorglich.
PHP serialisiert die Daten selbst, und de-serialisiert sie dann auch wieder. Wenn da irgendein Gefahrenpotential vorhanden waere, dann haette PHP sich schon im ersten Schritt beim Serialisieren darum gekuemmert.

Potentiell gefaehrlich ist unserialize dann, wenn der Quelle, die die Daten (vermeintlich) serialisiert hat, nicht vertrauen kann. Dann koennten die in irgendeiner Form so manipuliert sein, dass sie unserialize einen "Schluckauf" verpassen, weil sie nicht im gewohnten Format vorliegen.
Deshalb sollte man wie gesagt keine (vermeintlich) *serialisierten* Daten, die von ausserhalb kommen (Cookie, GET, POST), de-serialisieren.
Die aus einer Sessiondatei ausgelesenen *serialisierten* Daten kommen aber nicht von aussen - sie wurden von vertrauenswuerdiger Quelle (PHP selber) *serialisiert*. (Es geht hier nur um die Serialisierung der Daten, *nicht* um ihren Inhalt.)

MfG ChrisB

[ChrisB]

Hi,

da faellt mir gerade noch ein huebsches Beispiel ein.

Du kennst doch sicher diese "Springteufel", die in einer kleinen Box stecken, und per Feder rausspringen, wenn man die Box oeffnet ...?

Nehmen wir an,
a) die Box waere unsere Session-Datei,
b) das Rausspringen eines Springteufels aus dieser waere gefaehrlich, weil es dich zu Tode erschreckt,
c) Serialisierung waere der Vorgang des Plattklopfens eines Springteufels mit dem Hammer, bevor er in die Box gesteckt wird, und
d) De-Serialisierung waere das Oeffnen der Box, um zu schauen, was schoenes drin ist.

Wenn sich jetzt jemand, dem du vertrauen kannst (PHP), um die Serialisierung - Platthaemmern des Teufelchens - gekuemmert hat, kannst du die Box auch immer gefahrlos oeffnen; dich wird nichts anspringen, du findest schlimmstensfalls die zertruemmerten, und deswegen harmlosen, Einzelteile eines Teufelchens vor.

Wenn dir jetzt aber jemand *anderes* eine Box in die Hand drueckt - sagen wir, er nenne sich Cookiex, GErT oder POSTmann - dann solltest du die nicht bedenkenlos oeffnen (de-serialisieren); denn dieser jemand koennte lediglich *behaupten*, er habe serialisiert/alles gefaehrliche plattgehaemmert, dies in Wirklichkeit aber gar nicht getan haben - so dass dich beim Oeffnen der Box doch ein Teufelchen anspringt, du tot umfaellst ... und wir die Scherereien mit der Leiche haben.

MfG ChrisB

[Heinzelhund]

Wenn sich jetzt jemand, dem du vertrauen kannst (PHP), um die Serialisierung - Platthaemmern des Teufelchens - gekuemmert hat, kannst du die Box auch immer gefahrlos oeffnen; dich wird nichts anspringen, du findest schlimmstensfalls die zertruemmerten, und deswegen harmlosen, Einzelteile eines Teufelchens vor.

Hm, das PHP eine Spaßbremse ist, die einem den Springteufel platt klopft, war mir bisher noch gar nicht so bewusst.

Ciao
Heinzelhund

[EKKi]

Mahlzeit,

Hm, das PHP eine Spaßbremse ist, die einem den Springteufel platt klopft, war mir bisher noch gar nicht so bewusst.

Tut es ja auch nur auf Anforderung. :-)

MfG,
EKKi

[dedlfix]

echo $begrüßung;

was denkt ihr, sollte man potenziell unsichere Daten vor dem Speichern in einer Session-Textdatei zuvor maskieren?

Bist du derjenige, der die Session-Textdatei anlegt und die Daten reinschreibt? Dann musst du auch dafür sorgen, dass du Zeichen mit Sonderbedeutung von denen in den Nutzdaten unterscheiden kannst. Wenn du einfach nur das $_SESSION-Array schreibend und lesend verwendest, dann ist es nicht deine Aufgabe, dich um das korrekte Schreiben in die im Hintergrund verwendete Datenhaltung zu kümmern. Es sei denn, das Handbuchkapitel zu diesem Thema gibt Handlungsanweisungen. Tut es aber nicht.

Und wenn ja, wie? Addslashes() vielleicht?

Irgendwas nehmen, wird schon stimmen? Das ist nicht die richtige Vorgehensweise. Informiere dich, welche Zeichen eine Sonderbedeutung im jeweiligen Kontext haben und wie diese zu behandeln sind.

Wohlgemerkt, dies bezieht sich ausschließlich auf das Speichern in dem serialisierten Array,

So eine Session-Datei ist ja kein Geheimnis. Öffne sie einfach in einem Texteditor und versuch dir über ihren Aufbau klar zu werden. Versuch dann, die dabei verwendeten Zeichen in deinen Nutzdaten zu verwenden. Wie sieht nun die Session-Datei aus? Und kommen die Daten so wieder raus, wie du sie reingetan hast oder werden sie verfälscht?

echo "$verabschiedung $name";

[Heinzelhund]

Hallo!

echo $begrüßung;

was denkt ihr, sollte man potenziell unsichere Daten vor dem Speichern in einer Session-Textdatei zuvor maskieren?

Bist du derjenige, der die Session-Textdatei anlegt und die Daten reinschreibt? Dann musst du auch dafür sorgen, dass du Zeichen mit Sonderbedeutung von denen in den Nutzdaten unterscheiden kannst.

Ja, indem ich session_start() aufrufe.

Wenn du einfach nur das $_SESSION-Array schreibend und lesend verwendest, dann ist es nicht deine Aufgabe, dich um das korrekte Schreiben in die im Hintergrund verwendete Datenhaltung zu kümmern. Es sei denn, das Handbuchkapitel zu diesem Thema gibt Handlungsanweisungen. Tut es aber nicht.

Da steht leider so vieles nicht drin.

Und wenn ja, wie? Addslashes() vielleicht?

Irgendwas nehmen, wird schon stimmen? Das ist nicht die richtige Vorgehensweise. Informiere dich, welche Zeichen eine Sonderbedeutung im jeweiligen Kontext haben und wie diese zu behandeln sind.

Es handelt sich um einen serialisierten Array, der Strings in Anführungsstriche setzt. Zudem notiert er zuvor die Länge des Strings. Es ist nun denkbar, das Anführungszeichen eine Auswirkung als Sonderzeichen haben. Da wäre addslashes() durchaus eine denkbare Möglichkeit und nicht einfach ins Blaue geraten.

So eine Session-Datei ist ja kein Geheimnis. Öffne sie einfach in einem Texteditor und versuch dir über ihren Aufbau klar zu werden. Versuch dann, die dabei verwendeten Zeichen in deinen Nutzdaten zu verwenden. Wie sieht nun die Session-Datei aus? Und kommen die Daten so wieder raus, wie du sie reingetan hast oder werden sie verfälscht?

"trial and error" ist in Sicherheitsfragen immer nur die zweitbeste Lösung, da man nicht alle Möglichkeiten durchspielen kann. Besser ist es, zu wissen, wie etwas abgearbeitet wird. Und das ist meine Frage. Aber da scheinst du ja auch kein näheres Wissen zu haben.

Ciao
Heinzelhund

[dedlfix]

echo $begrüßung;

Bist du derjenige, der die Session-Textdatei anlegt und die Daten reinschreibt? Dann musst du auch dafür sorgen, dass du Zeichen mit Sonderbedeutung von denen in den Nutzdaten unterscheiden kannst.
Ja, indem ich session_start() aufrufe.

Da besteht kein zwingender Zusammenhang. Die Verwaltung der Sessiondaten ist aus der Sicht des Script komplett uninteressant. Wenn du dir einen eigenen Session-Handler schreibst, der seine Daten beispielsweise in einer XML-Datei ablegt, dann kann es nicht Aufgabe des Scripts sein, in diesem Fall eine andere Sonderzeichenbehandlung vorzunehmen. Es weiß nichts darüber, wie die Daten abgelegt werden, und was dabei zu beachten ist. Es sieht nur das Array $_SESSION, das wie ein ganz normales Array aussieht (und ruft außerdem noch eine "ominöse" Funktion namens session_start() auf). Alles andere liegt außerhalb seines Fokus.

Es handelt sich um einen serialisierten Array, der Strings in Anführungsstriche setzt. Zudem notiert er zuvor die Länge des Strings. Es ist nun denkbar, das Anführungszeichen eine Auswirkung als Sonderzeichen haben. Da wäre addslashes() durchaus eine denkbare Möglichkeit und nicht einfach ins Blaue geraten.

Du weißt nicht, wie die Zeichen mit besonderer Bedeutung so notiert werden, dass sie ihre Sonderbedeutung verlieren, siehst aber addslashes() als probates Mittel an? Na ich weiß ja nicht ...

"trial and error" ist in Sicherheitsfragen immer nur die zweitbeste Lösung, da man nicht alle Möglichkeiten durchspielen kann. Besser ist es, zu wissen, wie etwas abgearbeitet wird. Und das ist meine Frage. Aber da scheinst du ja auch kein näheres Wissen zu haben.

Das scheint nur so. Zunächst erstmal: Es ist keinerlei Behandlung seitens des Script erforderlich. Greif einfach lesend und schreibend auf $_SESSION zu, so wie du es bei jedem anderen Array auch machen würdest. Der Session-Handler kümmert sich um die ordnungsgemäße und sichere Speicherung der Daten.[*]

Der Rest ist Wissen über Sinn und Zweck von Quotierung und Maskierung bzw. in diesem Fall dem Speichern von strukturierten Daten in einem unstrukturierten Container (hier: eine Textdatei) mit Hilfe von Trennzeichen. Damit diese Trennzeichen nicht mit Zeichen in Nutzdaten verwechselt werden, sind letzere gesondert zu notieren. Für alle anderen Zeichen besteht diese Notwendigkeit nicht. Es kommt also bei solch einer Speicherung nur auf die Trennzeichen an. Wenn man sich über die Art der Ersatzdarstellung informieren möchte, bzw. ob das System diese selbständig berücksichtigt, muss man also vorwiegend diese Zeichen betrachten. Notiert der Session-Handler diese Zeichen in einer besonderen Form, kann man davon ausgehen, dass er das auch bei allen anderen Sonderzeichen korrekt vornimmt. Täte er das nicht, gäbe es bei einem solch verbreiteten System wie PHP und innerhalb dessen an solch einer prominenten Stelle, wie es die Sessions sind, schon genügend Bugreports.

[*] Für die Session-Dateien sind gegebenenfalls Maßnahmen zu ergreifen, um sie vor Beeinflussung durch den durch andere Scripte mit anderen Konfigurationsdaten gestarteten Garbage Collector zu schützen. Dies kann man erreichen, wenn man für jedes Projekt, das auf dem Server läuft, einen eigenen session.save_path konfiguriert.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

Es ist schon eine Weile her, als ich mir das letzte Mal die serialisierte Darstellung von Werten anschaute.

serialize('foo"bar') ergibt s:7:"foo"bar";
  unserialize(serialize('foo"bar')) ergibt foo"bar

Es wird keine Maskierung der Trennzeichen verwendet. Trotzdem können die Daten ordentlich wiederhergestellt werden. Durch die vorangestellte Längenangabe ist eindeutig festgelegt, wieviel Zeichen zu den Nutzdaten gehören. Kommt also so ein Trennzeichen in den Nutzdaten vor, liegt es ja innerhalb der durch die Längenangabe festgelegten Zeichen und wird damit als Nutzdatenbestandteil interpretiert. Das ist eine ebenso sichere Vorgehensweise wie Quotierung und Maskierung ohne vorangehende Längenangabe. Im Grunde genommen sind selbst die "" überflüssig.

echo "$verabschiedung $name";

[Heinzelhund]

Hallo nochmal,

das ist doch mal eine Auskunft (deine letzten beiden Beiträge dieses Threads), wie ich sie erhofft hatte. Ähnliches hatte ich mir bereits selber gedacht, allerdings denk ich mir auch schon mal viel am Tag. :-)

Was mich jedoch wirklich irritiert hatte, war der Aspekt, den du auch ansprachst:

serialize('foo"bar') ergibt s:7:"foo"bar";
  unserialize(serialize('foo"bar')) ergibt foo"bar

[...]Durch die vorangestellte Längenangabe ist eindeutig festgelegt, wieviel Zeichen zu den Nutzdaten gehören.[...]Im Grunde genommen sind selbst die "" überflüssig.

Eben das gab mir zu denken, da die Anführungsstriche ja nur bei Strings gesetzt werden. Was mich auch verunsicherte, war die Frage, ob die auch immer richtig zählen, egal was da rein geschrieben wird. Aber da trifft wahrscheinlich das zu, was du in deinem vorletzten Beitrag schreibst.

Täte er das nicht, gäbe es bei einem solch verbreiteten System wie PHP und innerhalb dessen an solch einer prominenten Stelle, wie es die Sessions sind, schon genügend Bugreports.

Danke für deine Antwort.

Ciao
Heinzelhund