sichere Datenübermittlung

[Stefan Iffland]

Ich habe das folgende Problem:
Ich entwickel eine Plattform für die Personalverwaltung über das Intranet. Dabei steh ich nun noch in der Entwicklungsphase. Für die Benutzung ist natürlich Benutzername und Passwort erforderlich. Benutzername und Passwort werden mit den Einträgen in der Datenbank abgeglichen. Nach der Überprüfung wird die zugewiesene Session mit dem entsprechenden User verbunden. Ich befürchte nur ein Sicherheitsproblem, wenn jemand am selben Rechner die letzte Session (Verlauf) aufruft. Gibt es keine Möglickeit die sessionID wie bei einem Formular per POST zu übergeben, also für niemanden sichtbar. Ich will also das Anhängsel an der URL vermeiden um dieses Problem zu lösen.

Danke für Eure Tips! Stefan

[Xafford]

du kannst die SID auch so, wie standardmäßig vorgesehen, über cookies übermitteln und diese cookies mit session_set_cookie_params begrenzen. am sinnvollsten wär natürlich, wenn du die sessions zwingend nach jeder verbindung mit session_destroy zerstörst.
noch als kleine anmerkung: wenn es nur um einloggen geht, würde ich ohnehin auf sessions verzichten

[Stefan Iffland]

Es geht nicht nur um das einloggen. Ich muß das schon mit Sessions machen. Es geht um Personaldaten, die sehr vertraulich sind und da muß man sich anmelden und die Sitzung muß eben mitgenommen werden. Leider gibt es da scheinbar nur die Möglichkeit der GET-Methode. Ich wollte die SessionID gerne unsichtbar im POST-Bereich der URL übergeben, damit man nicht über die History der Browser zurück ins Programm kommt, ohne sich anzumelden. Die Session sind schon zeitlich eingeschränkt, nach einer Stunde inaktivität wird die Session vom Script beendet und man kann mit der Session nichts mehr anfangen. Mir geht es nur darum, ob man die SessionID anders als über GET übermitteln kann. Weil die Browser ja in der History keine POST-Daten speichern. Danke für Eure Denkanstöße

[Xafford]

du kannst die session schon problemlos via cookies übertragen lassen. ich verute mal, daß du auf dem server mod_rewrite nutzt und deswegen automatisch an alle lokalen links die SID angehängt wird. wenn du das umgehen willst, so mußt du mod_rewrite deaktivieren und dich dann selbst um die übergabe der session kümmern.
aber noch ein kleiner punkt, wenn die daten so sensibel sind, dann ist session-hijacking eher noch das kleinere problem, ein netzwerksniffer wie ethereal kann dir auch problemlos die daten aus dem post-stream präsentieren, wenn diese unverschlüsselt übertragen werden und z.b. in einem LAN über proxy oder router erst ins Inet gehen. hast du die möglichkeit mit SSL zu arbeiten

[Stefan Iffland]

Ich arbeite mit WAMP. Würde lieber mit LAMP arbeiten, aber die Firma setzt auf Windows-Server. Ich kann den Apache mit SSL installieren, sodaß ich eine sichere Verbindung herstellen kann. Die Daten gehen nicht ins Inet. Das ist ein reines Intranet. Zwar können die Rechner teilweise eine Verbindung ins Inet herstellen, aber an die Intranet-Seiten kommt von außen keiner ran. Ich arbeite ohne SID. Ich hänge meine GET-Variablen selbst an die Links an.
Also <a href="xxx.php?sess=<?php echo $_SESSION['sess']; ?>">xxx</a>
Nur ich würde dieses Anhängsel gerne irgendwie anders übertragen, auf den ersten Blick eben unsichtbar für den User. Nur scheinbar gibt es da keinen Weg. :-(
Ich hab soweit die Sicherheitsvorkehrungen getroffen. Automatischer Logout nach 60 Minuten Inaktivität, jeder User kann nur eine Sitzung haben. Kein Login auf 2 Stationen gleichzeitig. Kennwortalter wird überprüft, Kennwort muß Mindestlänge haben. Datenbank erfaßt jeden Zugriff, Admin kann Zugriffe auswerten und weitere kleine Gimmicks.
Gibt es denn keinen Weg die sessionID, um die geht es mir ja nur, anders als mit GET zu übertragen.
Ich könnte natürlich bei jeder abgeschlossenen Aktion die Session zerstören und dem gleichen User halt nur eine neue Session-ID für jede neue Aktion zuweisen. Dann sind alle abgeschlossenen Aktionen zumindest nicht mehr über die History aufzurufen. Dann bleibt aber immernoch die letzte SessionID, für 60 Minuten, wenn der User vergißt sich abzumelden. und von der aus kann man ja da auch alles machen, wenn man einmal drin ist. Wenn ich das mit Cookies mache und setze die Gültigkeit des Cookies auf diese Browsersession, also so lange der Browser geöffnet ist, kann ich auch nicht davon ausgehen, daß der User den Browser nach dem Verlassen schließt. Er könnte ja eine weitere Seite im Intranet aufrufen.
Jetzt kommt Dir vielleicht auch die Idee mit JavaScript mit onLeave oder so, aber das würde nicht funktionieren, weil ich das in jede Seite einbauen müßte, weil der User von jeder Seite aus das Programm verlassen kann, aber onLeave wird immer ausgeführt, das kann ich nicht an Bedingungen binden.
Ich brauch also eine Möglichkeit zur Überprüfung, meinetwegen minütlich, ob der User tatsächlich noch online ist, oder aber die Übertragung der SessionID auf eine andere Weise. :-(

Ich verzweifel schier!

Danke schonmal wieder für Deine/Eure Denkanstöss

[Xafford]

wenn du ohnehin mit cookies arbeitest, so brauchst du die SID nicht mehr über die URL mit zu geben, sie ist doch bereits über das cookie verfügbar. somit arbeitest du eigentlich redundant ;o)...

[Stefan Iffland]

Ja nur ich kann mich nicht auf den Cookie verlassen. Auf den meisten Arbeitsstationen sind Cookies standardmäßig gesperrt und dafür muß ich quasi eigentlich doppelt arbeiten.
Und für die Ausweichvariante brauche ich eben die beschriebene Lösung für mein Proble

[jens schachtschneider]

Kann sein das ich falsch liege....bin noch neuling.....aber kannst du denn nicht alles was in der Url übergeben wird verschlüsseln

[Stefan Iffland]

Du meinst urlencode() zum Beispiel. Diese Funktionen sind nur dafür da, daß man Sonder- und Leerzeichen, die über die URL übergeben werden nicht verschlüsselt, sondern quasi codiert werden, sodaß keine Fehler entstehen

[andreas ullrich]

Wieso Cookies - wieso GET oder POST ????

Warum speicherst Du die Daten nicht in Sessionvariablen (ergo SID) da mußt Du doch überhaupt nicht auf Cookies zurückgreifen. Zu mal dann die sensiblen Daten auch nicht im HTTP erscheinen und somit auch nicht mitgelesen werden können.

Die Sessionvariablen liegen doch im TMP des Apache und nur da - sollte ich mich jetzt täuschen möchte ich es gerne wissen.......

[Stefan Iffland]

Das mit den Sessions ist schon richtig, ich verwende ja auch sessions, aber Du hast mein eigentliches Problem nicht erkannt. Ich will die SessionID nicht über die URL übergeben, sondern unsichtbar für den Benutzer, weil das für mich ein Sicherheitsrisiko darstellt.

Darum ging es einzig.

Hab das Prog erstmal so laufen, und einige Sicherheitsfunktionen eingebaut, aber wenn der User sich vergißt anzumelden ist die Session ab der letzten Änderung noch eine Stunde gültig. Diese Zeitspanne ist gefährlich, wenn der User diese ID zufällig in der History aufschnappt und deswegen wollte ich die Übertragung der SessionID über die URL vermeiden, aber ich kann ja nicht jedes Dokument aus einem Formular heraus aufrufen, damit ich die Daten mit POST übergeben kann.

Gruß Stefa

[Jürgen Schaaf]

Aus selfhtml:<br>
&lt;meta http-equiv="cache-control" content="no-cache"&gt;
Anweisung an den Browser: keinen Cache benutzen, sondern von Originalseite laden.

&lt;meta http-equiv="pragma" content="no-cache"&gt;
An Proxy-Agenten: Datei bitte nicht auf Proxy-Server speichern!

Damit dürften Deine heißen Seiten nicht mehr in den Caches landen und zumindest für die Zurück-Vorwärts-Knöpfe tabu sein

[Stefan Iffland]

Danke! Ich probiers gleich! Der Tip könnte Gold wert sein!

Gruß Stefa

[Jürgen Schaaf]

1. siehe auch <br>
&npsp;&npsp;&npsp;http://www.php.net/manual/de/features.http-auth.php<br>
&npsp;&npsp;&npsp;http://www.phpfreaks.com/tutorials/40/0.php<br>
&npsp;&npsp;&npsp;<a href="/webx?50@@.ee8dd5b">Jürgen Schaaf "Passwortschutz und Nutzerverwaltung" 23.01.2003 10:05</a><br>
2. ich übermittle die Session-ID und nur die Session-ID in einem hidden-Formularfeld (POST-Methode). Die Navigation der entsprechenden Seite realisiere ich über die Submit-Buttons des Formulars. Sonst steht nichts weiter im Formular und der Rest der Seite ist normales HTML. Die Session-Id ist aber aufklärbar, wenn man sich den Quelltext der Seite anzeigen läßt, sie steht aber nicht offentlich in der URL. Die Aufklärung wird auch noch etwas verschleiert, wenn Du zusätzlich Frames benutzst. Alle anderen Variablen speichere ich in der Session auf dem Server. So funktioniert das auch bei abgeschalteten Cookies.<br>
3. Wichtig ist auch, dass Du eine LOGOFF-Funktion anbietest, die die Session killt. Als Autobauer mußt Du Türschlösser und Wegfahrsperre einbauen. Benutzen muß sie der User. Für ein geklautes Auto mit steckenden Schlüssel und laufenden Motor kommt keine Versicherung auf. Genau so hat das mit der Sicherheit von Seiten des Entwicklers seine Grenzen. Du mußt nur funktionierende Featchers anbieten und beschreiben. Diese sollen ergonomisch durchdacht sein, sie werden aber allein den Weltfrieden nicht bringen. Die letzten 20% eines EDV-Projektes verschlingen 80% der Kosten !!

[Jürgen Schaaf]

1. siehe auch <br>
http://www.php.net/manual/de/features.http-auth.php<br>
http://www.phpfreaks.com/tutorials/40/0.php<br>
<a href="/webx?50@@.ee8dd5b">Jürgen Schaaf "Passwortschutz und Nutzerverwaltung" 23.01.2003 10:05</a><br>
2. ich übermittle die Session-ID und nur die Session-ID in einem hidden-Formularfeld (POST-Methode). Die Navigation der entsprechenden Seite realisiere ich über die Submit-Buttons des Formulars. Sonst steht nichts weiter im Formular und der Rest der Seite ist normales HTML. Die Session-Id ist aber aufklärbar, wenn man sich den Quelltext der Seite anzeigen läßt, sie steht aber nicht offentlich in der URL. Die Aufklärung wird auch noch etwas verschleiert, wenn Du zusätzlich Frames benutzst. Alle anderen Variablen speichere ich in der Session auf dem Server. So funktioniert das auch bei abgeschalteten Cookies.<br>
3. Wichtig ist auch, dass Du eine LOGOFF-Funktion anbietest, die die Session killt. Als Autobauer mußt Du Türschlösser und Wegfahrsperre einbauen. Benutzen muß sie der User. Für ein geklautes Auto mit steckenden Schlüssel und laufenden Motor kommt keine Versicherung auf. Genau so hat das mit der Sicherheit von Seiten des Entwicklers seine Grenzen. Du mußt nur funktionierende Featchers anbieten und beschreiben. Diese sollen ergonomisch durchdacht sein, sie werden aber allein den Weltfrieden nicht bringen. Die letzten 20% eines EDV-Projektes verschlingen 80% der Kosten !!