sicherheitsfrage

[hopsekey]

ich programmiere jetzt seit vier wochen php. nun bin ich glücklicherweise auf das thema sicherheit gestoßen.
zur weitergabe einiger variablen benutze ich hidden fields und register_globals ist on. nicht meckern, ich habe schon mitbekommen, dass das nicht gut ist. als wirklich wichtige variable übergebe ich den benutzernamen. ansonsten sind die anderen variablen nur sachen die vorher ausgewählt wurden. ich würde nicht unbedingt sessions verwenden wollen, da nicht gewährleistet ist, dass jeder user cookies zulässt. der speicher auf dem server sehr begrenzt ist und das nicht an die url angehangen werden soll. ich habe vor das ganze mit einem zusätzlichen zufällig generierten schlüssel in der db abzusichern. das ganze soll nur im intranet laufen und nun frage ich mich, wie hoch ist mein sicherheitsproblem?

[penizillin]

einmetersiebzig.

argumente gegen die sessions sind sehr schwach. weder spielt der platz auf dem server keine rolle noch sind die "schönen" urls ein wichtiger faktor.

[Schnoop]

Die "unschönen" URLs spielen nur bei der Suchmaschinen einen Rollen. Also solltest du wenn möglich die Session nur starten wenn ein User auf die Seite kommt, und nicht bei Suchmaschinen.

[hopsekey]

@ penizillin
ich habe hier ein php buch vor mir liegen, dass sich mit php3 und 4 beschäftigt.

Speichert der Server die Sitzungsdaten im Speicher,
sind erhebliche Zugriffe auf die Systemressourcen zu beobachten.
Auch wenn nur wenige Byte gespeichert werden,
benötigt wird oft weitaus mehr Speicher.

dazu kommt, dass wenn cookies deaktiviert sind, automatisch alles in die url geschrieben wird und die genauso einsehbar ist, wie hidden fields.

[Schnoop]

Ja wo ist denn das Problem wenn die Session ID an die URL angehängt wird?

[hopsekey]

na es geht doch um die sicherheit und wenn jemand die sessionid hat, kommt er doch an die variablen genauso ran, wie bei hidden fields?!?

[Schnoop]

ich besitze das gefährliche halbwissen!

Und woher nimmst du dieses gefährliche halbwissen?? bzw. woher soll er die Session ID bekommen?

[hopsekey]

in diesem tollen buch steht, dass die hidden fields genauso einfach einzusehen sind, wie die url. da dann das im buch vielleicht etwas übertriebene problem mit speicher dazu kommt, kann ich doch eigentlich gleich bei hiddenfields bleiben, da sie mir lediglich den traffic steigern, aber der server davon unbehelligt bleibt.

[wahsaga]

Re: sicherheitsfrage

Original geschrieben von hopsekey
als wirklich wichtige variable übergebe ich den benutzernamen.

und an hand von diesem checkst du dann, ob ich "eingeloggt" bin ...?

in diesem fall hindert mich niemand daran, das formular mit irgendeinem anderen usernamen abzuschicken, z.b. hopsekey - und dann wäre ich plötzlich dieser user.

[hopsekey]

nein, als aller erstes musst du dich einloggen. ist das nicht der fall, bringt dir der nutzername gar nichts. den nutzernamen schleppe ich mit, da ich anhand des angemeldeten benutzernamens die rechte, die er hat, umsetzen kann.
sollte es dir gelingen die anmeldung zu umgehen, bringt dir das auch nichts, da durch die anmeldung ein schlüssel in die datenbank geschrieben wird. steht der nicht drin, hast du keine rechte. der schlüssel wird zufällig erzeugt und dem formular mitgegeben und der db halt.

[Schnoop]

Na das mit dem Usernamen ist bissl unpraktisch. Wieso arbeitest du nicht mit der Userid?

[hopsekey]

was für ne userid? der username ist mein primarykey.

[Schnoop]

Hm. Naja, ein wenig unglücklich würde ich sagen, aber wenn du es so machen willst.

[hopsekey]

die hier legen keinen wert drauf, das der nutzername nicht auftaucht. der soll sogarn angezeigt werden, wer was zuletzt geändert hat. aber mit ner id natürlich etwas besser, wenn die stattdessen im hiddenfield steht. ich schreibs mir auf Danke

[penizillin]

ich habe hier ein php buch vor mir liegen, dass sich mit php3 und 4 beschäftigt.

das ist u.u. veraltet. der umgang mit den sessions ermöglicht es dir, die session id und evtl. noch irgendein flag / schlüssel zu speichern - der rest wird z.b. mit der db abgeglichen. d.h. pro session (sprich, pro user) benötigt php somit keine 100 byte platz. oder ist das jetzt auch zu viel?

Speichert der Server die Sitzungsdaten im Speicher, sind erhebliche Zugriffe auf die Systemressourcen zu beobachten.

sollte euer intranet aus mehreren tausen knoten bestehen, trifft das zu. dann sollte man sich aber auch einen besseren server leisten können.

dazu kommt, dass wenn cookies deaktiviert sind, automatisch alles in die url geschrieben wird

das stimmt nicht, es wird nur die sid in die url geschrieben. der rest wird nach wie vor serverseitig verwaltet.

wenn jemand die sessionid hat, kommt er doch an die variablen genauso ran, wie bei hidden fields?!?

dann sollte man die stelle absichern, an der ein "jemand" an die sid kommen könnte, z.b. ssl gegen banales http sniffing, todesstrafe gegen schlechte administrierung der client rechner, etc.