sicherheitsrisiko: use_trans_sid ?

[Potassium]

servus
ich hab mal ne frage.
wie hoch stuft ihr das sicherheitsrisiko ein, wenn man session.use_trans_sid bei php aktiviert hat?
ich bräuchte es damit man sich auch einloggen kann wenn man keine cookies akzeptiert.
was meint ihr, risikiere ich da viel?

[Sloter]

Also ich würde eher den Weg gehen, die ID in eine DB zu schreiben und von dort auszulesen für die Weiterverarbeitung.
Die Session bleibt sonst ewig am Leben

Bin mal gespannt, was die Profis meinen

Sloter

[Potassium]

Original geschrieben von Sloter
Also ich würde eher den Weg gehen, die ID in eine DB zu schreiben und von dort auszulesen für die Weiterverarbeitung.
Die Session bleibt sonst ewig am Leben

Bin mal gespannt, was die Profis meinen

Sloter

wenn du mir verräts wie ich die sessionid vom browser OHNE cookie zum server schicke dann gerne.
mir fällt dazu aber keine (einfache) lösung ein.

[Sloter]

Es gibt 2 Systeme, also auch 2 Sessions. Man programmiert nun entweder eine Pipe, wo alle Daten verschlüsselt per GET (bis 1024Byte) oder POST (je nach Einstellung am Server) übergeben werden. Oder man legt alle Daten in einer Datenbank ab und übergibt nur die Session-ID, welche bei jedem Datensatz mitgespeichert wird. Die Session-ID verschlüsselt man z.B. mit RSA und schon ist es sicher.

Sloter

[Potassium]

das wäre das drumherum nur mein prob is wie sende ich die id immer per get mit? und zwar nur dann, wenn der client KEINE cookies nimmt, da anonsten die sessionid eh mit dem cookie gesendet wird.

[käptn]

Das kommt ganz darauf an...

Bei einem Forum ist es sicher nicht so tragisch wie bei einem WebShop oder WebMailer.

Worauf man achten sollte:

Nach dem Login die Session-ID mit session_regenerate_id() neu erzeugen.

Externe Links über ein Redirect-Script laufen lassen, welches die Session-ID "schluckt".

Bleibt immer noch die Möglichkeit, dass der User die URL einfach aus der Adresszeile kopiert.

Wie kann man jetzt sicherstellen, dass die Session dem Benutzer gehört, der sie aufruft?

... gar nicht.

Ein Check des User-Agents ist sogar verlässlicher als die IP...

Soll es wirklich sicher sein, wirst du um SSL nicht herum können.

Ob unser alkalischer Freund die Session-Daten jetzt in der DB speichert oder nicht, ist eher Geschmackssache, da sich dabei höchstens Spionage am Server etwas eindämmen läßt.

~

[Potassium]

session_regenarte_id() muss ich ausprobieren klingt aber gut
ad externe links:
ich weiß nicht was du genau meinst aber bei mir haben externe links keine session_id drangehängt.

user agent ist doch nur ne agabe über den browser oder?

ajo und es wird kein webshop sondern ich möcht nur verhindern, dass jemand ohne größere schwierigkeiten admin-rechte etc auf meiner seite erwirbt.

[käptn]

Original geschrieben von Potassium
ad externe links:
ich weiß nicht was du genau meinst aber bei mir haben externe links keine session_id drangehängt.

...aber der Refer(r)er

~

[Potassium]

Original geschrieben von käptn
...aber der Refer(r)er

~

ajo.
und wie kann ich ausm referer was entfernen?
bzw wie genau wird mir der gefährlich?

[käptn]

Sieh dir mal eine Apache AccessLog Datei an.

redirect.php

PHP-Code:

<?php
require_once 'HTTP.php';

if (isset($_GET['PHPSESSID']))
    HTTP::redirect('?url='. urlencode($_GET['url']));

HTTP::redirect($_GET['url']);
?>

~