Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen

**Griecherus** · 04.03.2008, 23:41

Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen

Original geschrieben von Stub

1. Frames
Mir ist klar das php-Entwicklung ohne Berücksichtigung von Frames einfacher/leichter ist. Da ich aber gern Frames verwenden möchte, ist mir nicht klar, in wie weit Frame-Nutzung ein Sicherheitsrisiko darstellen könnte oder was generell einen wirklich bedeutender Grund wäre keine Frames zu nutzen.
Das php ohne Frames einfacher wäre ist für mich nicht relevant. es zählen für mich allein erstmal Anwender-Aspekte also: Wenig Traffic/schnellerer Seitenaufbau und übersichtlichere dargestellte Seiten (ohne Wegscrollen einer Navigation aus dem sichtbaren Bereich).
Hinweis: Ich möchte hier keine Argumente gegen frames sammeln, wenn sie nicht den Sicherheits-Aspekt berücksichtigen
Hinsichtlich bisher gelesener Sicherheitsvorkehrungen in "normalen" (damit meine ich nicht-Frame-Seiten) php-Entwicklungen, gibs bei Frames evtl. mehr zu berücksichtigen?

2. Sessions oder Cookies?
Grundsätzlich hielt ich früher Session-Nutzung für besser, las jetzt aber auch Infos, wo Leute meinen, Cookie-Nutzung wäre nicht unsicherer/schlechter. Dies versteh ich nicht ganz.
Was könnte generell gegen oder für das eine oder andere sprechen?

Zu 1.) gibt es zig gute Gründe, keine Frames zu benutzen. Mit Einfachheit hat das relativ wenig zun als viel mehr mit Richtigkeit und der Tatsache, dass dir Frames in Sachen Benutzerfreundlichkeit so einige Striche durch die Rechnung ziehen.

Zu 2.)
Die Fragestellung ist so unsinnig. Das eine schließt das andere nicht aus, im Gegenteil: Sessions nutzen Cookies, falls nicht anders vorgegeben (auto_use_transid).

**Stub** · 04.03.2008, 23:53

Re: Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen

@Griecherus
>>Zu 1.) gibt es zig gute Gründe, keine Frames zu benutzen.
Leider hast du nicht einen Grund genannt.

>> Mit Einfachheit hat das relativ wenig zun als viel mehr mit Richtigkeit und der Tatsache, dass dir Frames in Sachen Benutzerfreundlichkeit so einige Striche durch die Rechnung ziehen.

Was richtig / besser ist oder manchmal die eine oder andere Lösung favorisiert, liegt im Auge des Betrachters und der Erfordernisse.
Das Frames generell für einen Benutzer einer Website zum Benutzen der Website eine Benutzer-Unfreundlichkeit darstellen möchte ich bezweifeln. Leider ist Deine Antwort genau das was ich mir nicht erhoffte.
Ich zitiere mich selbst: "Ich möchte hier keine Argumente gegen frames sammeln, wenn sie nicht den Sicherheits-Aspekt berücksichtigen"

>> Die Fragestellung ist so unsinnig. Das eine schließt das andere nicht aus, im Gegenteil: Sessions nutzen Cookies, falls nicht anders vorgegeben

Wenn ich sessions nutze, bin ich nicht gezwungen Cookies zu nutzen. Ich kann die SID doch immer in der Adress-zeile mit durchschleifen.
Daher erscheint mir dein Einwand "im Gegenteil: Sessions nutzen Cookies" nicht logisch und Dein Zusatz: falls nicht anders vorgegeben... relativiert Deine Aussage nur wiederum.
Dementsprechend - falls du keine besseren Erläuterung hast, würde ich Deine Antwort als unsinng empfinden. (Sorry)

**Griecherus** · 05.03.2008, 00:07

Deine Frage "Sessions oder Cookies" suggeriert, dass das eine nichts mit dem anderen zu tun hat, was so nicht richtig ist. Es ist also anzunehmen gewesen (so ging es mir zumindest, und meine Antwort war demnach nur gut gemeint), dass dir nicht bewusst ist, dass Sessions unter bestimmten Gegebenheiten auf Cookies basieren.
Um mal auf den Sicherheitsaspekt zu sprechen zu kommen: Dazu gibt es im Internet eine ganze Menge Lektüre, die Google für dich findet. Die TransID z.B. ist insofern problematisch, als dass eine Laie, der einem Dritten einen Link mit enthaltener SID zuschickt, eine Möglichkeit zum Session-Hijacking bietet, sofern das System keine Entsprechenden Vorkehrungen getroffen hat. Das nur mal als Beispiel.

Was richtig / besser ist oder manchmal die eine oder andere Lösung favorisiert, liegt im Auge des Betrachters und der Erfordernisse.

Dann solltest du deine Betrachtungen und insbesondere die Erfordernisse offen legen, sofern du nützliche Antworten auf deine Fragen erhalten möchtest.

Hier noch einige Links zum Thema Sicherheit hinsichtlich Sessions:
Session Fixation
Session Management - OWASP

OffTopic:
Es ist bedauerlich, einem Topic Zeit zu widmen, deren Resultat vom Fragesteller als "unsinnig" abgestempelt wird. Insofern könntest du bezüglich deiner Erwartungshaltung ja etwas mehr Offenheit an den Tag legen, wenn ich mal etwas Kritik äußern darf.

**Stub** · 05.03.2008, 00:45

@Griecherus
>> Es ist also anzunehmen gewesen (...), dass dir nicht bewusst ist, dass Sessions unter bestimmten Gegebenheiten auf Cookies basieren.

Wenn Deine Antwort bedeutet, das Sessions auf Gegenheiten (was sind as für welche?) basieren MÜSSEN, dann ist mir das nicht bewußt.

Wenn ich i.d. Vergangenheit SIDs nutzte, hab ich zur SID immer IP, UserName/PW mit festgehalten und wenn ne neue Seite mit ...&SID-Angabe aufgerufen wurde, auch überpüft ob die SID immer noch zur IP passt.
Ich wüßte nicht was dann Session-IDs mit Cookies zu tun haben müßten und meine eigentliche Frage zielte auch eher drauf ab, ob es irgendwelche relevanten Anmerkungen hinsichtlich Sicherheitsaspekte bei verwendung von Cookies gäbe, wobei ich bei Cookie-Nutzung im Cookie auch nur ne ID verwenden würde damit auf dem lokalen PC nicht Username+PW gespeichert werden.
Zusätzlich würde ich dann bei Cookie-Nutzung auf dem Server aber auch die akt. genutzte IP loggen um z.b.Doppel-Einloggversuche unterbinden zu können.

>> Um mal auf den Sicherheitsaspekt zu sprechen zu kommen: Dazu gibt es im Internet eine ganze Menge Lektüre, die Google für dich findet.
Dankeschön für den Hinweis.
Bevor ich hier meine Frage gepostet habe, hab ich 2 Tage lang, jeweils mehrere Stunden im Inet nach Infos gesucht, aber wie ich eingangs erklärte brachte mir das keine endgültige Erkenntnis.

>> Die TransID z.B. ist insofern problematisch, als dass eine Laie, der einem Dritten einen Link mit enthaltener SID zuschickt, eine Möglichkeit zum Session-Hijacking bietet, sofern das System keine Entsprechenden Vorkehrungen getroffen hat. Das nur mal als Beispiel.

Das ist mir klar, siehe auch meine obigen anmerkungen dazu.
Das ist aber auch das mir einzige Beispiel das mir einfällt , das mit etwas Code + dem Festhalten von ein paar Infos auch sicherer gehandhabt werden kann.
Ich wüßte darüberhinaus keine weiteren Beispiele wieso Sessions unsicher(er als Cookies) sein könnten.
Aber wie erwähnt zielte meine Frage auf Sicherheit bei Cookies ab, denn Cookies wären wiederum benutzerfreundlicher, denn mit Cookies braucht man sich beim Neu-Besuchen einer HP nicht immer wieder neu einzuloggen.

>> Hier noch einige Links ....
Dankeschön dafür, ich werde mich da durchwühlen.

Ab Deinen Zeilen:
>> Dann solltest du deine Betrachtungen .....
sehe ich persönlich alles als OffTopic an (bis auf die Link-Beispiele).

Und da ich nicht gewohnt bin in fach-Foren OTs zu lesen bekommst du jetzt von mir eine PM.

Edit: Aha, PMs funzen hier nicht, und ne eMail kann ich dir auch nciht senden. Dann gibts von mir halt kein OT zu lesen für Dich

**jmc** · 05.03.2008, 01:37

auf php.net, google oder wikipedia findest du sehr schnell die Unterschiede zwischen Session und Cookies und erkennst dabei auch noch gerade was "sicherer" ist. wenn "sicher" ins Spiel kommt muss man immer wissen wofür sicher. In den meisten Fällen sind Cookies jedoch unsicherer, da cookies von jedermann einfach erstellt werden können, die session jedoch nur vom server.

**unset** · 05.03.2008, 09:46

Re: Re: Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichti

Original geschrieben von Stub
@Griecherus
>>Zu 1.) gibt es zig gute Gründe, keine Frames zu benutzen.
Leider hast du nicht einen Grund genannt.

Weil du von der falschen Seite an die Fragestellung herangehst: Nenne mir einen guten Grund Frames zu benutzen. Dir wird keiner einfallen (jedenfalls keiner, den ich nicht widerlegen könnte). Aber hier ein paar Gründe, warum *ich* Frames nicht benutze und von der Benutzung abrate:

- Unflexbiles Layout
Mit Frames verhält sich ein Seitenlayout unflexibel in Bezug darauf, wie es auf Browsergrößenveränderung reagiert. Sicher, man kann vieles Abfangen, aber warum sich das leben schwer machen

- Not Valid
Frames sind nicht im XHTML 1.1 Standard definiert. Sicher, zur not kann man XHTML 1 nehmen, aber warum soll ich Rückständig bleiben? (Zugegeben, dieser Grund ist häufig Gegenstand von erbitterten Streitdiskussionen bei denen man eh zu keinem Ergebnis kommt

)

- Nicht eindeutige URLs
Wenn ich eine URL mit einem Frameset aufrufe, und sich ein oder mehrere Frames verändern, handelt es sich (aus Anwendersicht) um eine andere Seite. Die URL bleibt aber bestehen, dass aufrufen genau dieser Seite (zum Beispiel weil ich sie bookmarken will) ist so nicht mehr sauber möglich. Es sei denn, ich bookmarke nur den Inhalt eines Frames, dann fehlen mir aber unter Umständen wichtige Elemente der Seite wie die Navigation oder Ähnliches.

Sicherheitsaspekte spielen beim Für und Wider von Frames keine (große) Rolle. Was bei unsauberer Programmierung mit Frames möglich ist, ist bei unsauberer Programmierung auch anders machbar.

Ich muss an dieser Stelle aber auch mal erwähnen, dass in den meisten Ressourcen bezüglich Frames diese und viele andere Gründe mit aufgezählt werden. Darüberhinaus: Was zum Teufel hat das mit PHP zu tun?

**3DMax** · 05.03.2008, 10:53

Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen

Original geschrieben von Stub
2. Sessions oder Cookies?
Grundsätzlich hielt ich früher Session-Nutzung für besser, las jetzt aber auch Infos, wo Leute meinen, Cookie-Nutzung wäre nicht unsicherer/schlechter. Dies versteh ich nicht ganz.
Was könnte generell gegen oder für das eine oder andere sprechen?

äpfel oder birnen?

jmc hat es bereits auf den punkt gebracht. es hängt vom verwendungszweck ab. für die wiedererkennung der sprach- / layout-einstellungen eines benutzers kann man durchaus cookies benutzen für die hinterlegung des benutzernamens nach dem login jedoch nicht.

insofern ist deine frage, wie Griecherus bereits bemerkt hat, in der tat unsinnig.

**Stub** · 05.03.2008, 18:38

Re: Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen

@ 3DMax
>> jmc hat es bereits auf den punkt gebracht

hier hat es leider bisher keiner auf nen Punkt gebracht hinsichtlich meiner Fragestellungen, sondern alle haben genau in die Richtungen geantwort, die ich in meinem Start-post explizit ausgeschlossen haben wollte.

Dazu zitiere ich mich zum wiederholten Male:
Hinweis: Ich möchte hier keine Argumente gegen frames sammeln, wenn sie nicht den Sicherheits-Aspekt berücksichtigen

Von den 4 Postern, ist lediglich unset in der Lage konstruktive Angaben zu machen, wofür ich mich auch bei ihm bedanke.
Obwohl auch unset lieber auf das eingeht, was er für sinnvoll hält und auf meine Fragen hin eher nebensächlich eingeht.

Aber unset hat durch seine Beispiele mich auf etwas hingewiesen, was ich bisher nicht berücksichtigte: XHTML
Alle anderen Gründe, weswegen unset von Frames abrät, erscheinen mir irrelevant weil ich den Begründungen nicht zustimmen kann.

Hinsichtlich XHTML ist mir bisher garnichts klar, denn damit hab ich mich in all den Jahren in denen ich nichts mit Programmierung zu tun hatte, garnicht beschäftigt habe und heute garnicht beurteilen kann inwieweit XHTML wichtig zu berücksichtigen ist bzw. XHTML Pflicht ist zu benutzen. Bei php bis 3.xx gabs früher kein XHTML und daher hab ich dies für mein Wiedereinstieg in php auch garnicht berücksichtigt.

Zu XHTML kann dazu erstmal nur sagen, da muß ich mich gehörig schlau machen. Für den Hinweis drauf bin ich somit auch vorerst dankbar.

Im folgenden gehe ich mal auf Eure Anmerkungen ein:

@Unset

>> Mit Frames verhält sich ein Seitenlayout unflexibel in Bezug darauf, wie es auf Browsergrößenveränderung reagiert.
Niemand hier weiß genaues über das was und wie ich etwas erstellen möchte. Das was du da anreisst, ist irrelevant, weil ich bei meinem Einstiegs-Projekt keinerlei Probleme sehe und auch in der Vergangenheit keine probleme mit unflexiblen Layouts hatte.

>> - Not Valid, Frames sind nicht im XHTML 1.1
In wieweit ich es für sinnvoll erachten werden, XHTML zu nutzen weiß ich noch nicht, dazu muß ich sicher erstmal wieder viel lesen müssen.

>> - Nicht eindeutige URLs
Da spielt sicherlich für viele Projekte eine Rolle, für mich allerdings nicht. Selbst wenn eine Sub-Seite eines einzelnen Frames gebookmarkt werden soll, sehe ich keine Probleme, wenn die Sub-Seite aufgerufen wird, das sich trotzdem alles (Haupt-Frames+andere Frames) mit aufbauen kann.
Aber es geht nicht drum, irgendwelche Seiten zu bookmarken, bei mir handelt es sich um private/geschlossene User-bereiche.

>> Sicherheitsaspekte spielen beim Für und Wider von Frames keine (große) Rolle. Was bei unsauberer Programmierung mit Frames möglich ist, ist bei unsauberer Programmierung auch anders machbar.
Endlich mal eine Aussage zu meiner Fragestellung

>> : Was zum Teufel hat das mit PHP zu tun?
das hab ich mich auch bei all den Antworten gefragt.

@ 3DMax
>> insofern ist deine frage, wie Griecherus bereits bemerkt hat, in der tat unsinnig.
Es gibt keine unsinnigen Fragen.
Ein Fragender weiß etwas nicht oder versteht etwas nicht. Das allein ist der primäre Aspekt den andere Wissendere ausgleichen können.
Das man Cookies nicht zur Speicherung von z.b. Namen, passwort nutzen sollte habe ich ja selbst schon geschrieben.
Meine Frage zielte auf mögl. Sicherheitsunterschiede ab.

@ jmc
>>auf php.net, google oder wikipedia findest du sehr schnell die Unterschiede zwischen Session und Cookies
Es geht nicht um allgemeine Unterschiede bei diesen beiden Punkten, sondern um Sicherheitsfragen und php.net stellt nunmal nur ein php-Manuel dafür bereit.
Ebenso kann ich auf Wikepedia hinsichtlich dieser Thematik nichts finden und was google bringt, hab ich eingangs auch geschrieben: 2 Tage lang und viele stunden suchen aber keine Erkentnnisse erlangen.

>> In den meisten Fällen sind Cookies jedoch sicherer, da cookies von jedermann einfach erstellt werden können, die session jedoch nur vom server.
Das ist eine Aussage ohne Erklärung und erscheint mir nicht logisch.

Ansonsten kann ich nur sagen., dies ist ein Forum in dem man fragen stellen kann. Wenn man dann antworten bekommt, wie "nutze Google" obwohl eingangs gesagt wurde das diese Möglichkeit keine befriedigenden Ergebnisse lieferte, so erscheinen solche Antworten als nicht hilfreich, sondern eher als indirekter Hinweis drauf, das die Frage(n) hier nicht erwünscht/lästig ist/sind.
Wenn man nicht wenigstens wie Griecherus auch direkte Info-Links posten kann, sind aus meiner Sicht dann solche antworten unzweckmäßig/unkonstruktiv (somit unsinng).

Schlußwort

Da die Ausbeute hier für ein Fach-Forum nicht rühmlich ist, werde ich mich hier wieder verabschieden und nicht mehr nach meinem Post sehen.
Ich bedanke mich für die Mühe, die einige hier investierten viel Text und ihre Meinungen kundzutun und im besonderen bei Griecherus für die Link-Angaben und ganz besonders bei unset für konstruktive Antworten.

/closed

**st@tic** · 06.03.2008, 10:43

Re: Re: Re: Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichti

Da die Ausbeute hier für ein Fach-Forum nicht rühmlich ist, werde ich mich hier wieder verabschieden und nicht mehr nach meinem Post sehen.

ich glaub das ist auch besser so.
wie schon alle vorher sagten frames sind veraltet und sollten von jedem entwickler, welcher ernstgenommen werden möchte (egal ob profi oder anfänger) nicht mehr benutzt werden.

wenn man schon was lernt, dann sollte man das akutelle lernen und nicht irgendwas steinzeitmäßiges.

**jahlives** · 06.03.2008, 10:51

original von jmc
In den meisten Fällen sind Cookies jedoch unsicherer, da cookies von jedermann einfach erstellt werden können, die session jedoch nur vom server.

Wenn ich aber via URL eine erfundene Session ID anhänge, die aber existiert, dann bin ich auch drin.
Im Session Cookie speicherst du ja hoffentlich nur die Session ID und nicht noch irgendwelche Zugangsdaten. Anhand der Session ID kann der Server dann die entsprechenden Session Vars laden.
Ich für meinen Teil halte Cookies für solch ein Unterfangen als sicherer als die Session ID durch die URL zu schleifen. Dies weil Cookies weniger "sichtbar" sind als URL Parameter. Ausserdem umgeht man so, wie bereits geschrieben, das Problem mit dem Posten von Links.

Gruss

tobi

**onemorenerd** · 06.03.2008, 11:24

SID per Cookie ist sicherer als SID per URL!

Beispiel: Ich bin eingeloggt, kopiere eine URL (inkl. SID) und sende sie einem Bekannten.
Der klickt drauf. Der Server vergleicht nun die IP des Bekannten mit der in der Session abgelegten. Wenn mein Bekannter aber ein Kollege in der selben Firma ist, haben wir nach außen hin die selbe IP, die des Gateways. Mein Bekannter führt also meine Session fort!

Mit einem Cookie wäre das nicht passiert. w.z.b.w.

Der TS wird das hier nicht lesen, aber evtl. interessiert es andere.

**jmc** · 06.03.2008, 15:12

bitte löschen // aus versehen zweimal abgeschickt

**jmc** · 06.03.2008, 15:19

Wenn ich aber via URL eine erfundene Session ID anhänge, die aber existiert, dann bin ich auch drin.

Normalerweise ist die Wahrscheinlichkeit, dass du die richtige Session-ID erwischst kleiner als im Lotto einen 6er zu haben und um SID-Übergabe per url zu vermeiden gibts es ja z.B. session.use_only_cookies.
Man kann natürlich immer noch die SID im Cookie nachschauen gehen und dann selbst ein cookie mit der selben SID erstellen, aber dann kann man auch gerade alle infos in den Cookies anschauen. Zusätzlich müssen ja nicht gerade alle Daten aus der Session auf einer Seite ausgegeben werden, sodass man an diese Daten trotzdem nicht rankommt.

@stubborn stub
http://ch2.php.net/session <--- (php.net stellt nunmal nur ein php-Manuel dafür bereit. stimmt nicht ganz)
http://ch2.php.net/cookies

http://de.wikipedia.org/wiki/Sitzung_%28Informatik%29
http://de.wikipedia.org/wiki/HTTP-Cookie

und das in ca 10 sec, da kannst kaum selbst nachgekuckt haben

Wiedereinstieg in php und erstmal aktuelle sicherheitsapekte berücksichtigen