Allgemeiner Fragethread

[Tessio]

Wo war dann das Problem?

...

Das Problem machte in Form eines "owned" Bildes auf jeder zu verwaltenden Seite auf sich aufmerksam...

Schlecht, ich habe eher darauf abgezielt zu erfahren wer "die" sind.

...

Ah, hab die Seite wiedergefunden. _o/
Hans Wurst backt Pflaumen
Ich zitiere :

Die Sicherheit Ihrer Webseite ist beim Einsatz von Sessions nur dann gefährdet, wenn jemand die aktuelle Session-Id errät oder Zugriff auf Ihren Session-Ordner erlangt. Insbesondere bei kommerziellen Seiten sollte ein solcher Zugriff ausgeschlssen sein und der Session-Ordner auch nicht unbedingt den Standartnamen besitzen und im Standartverzeichnis (z.b C...\tmp) abgelegt sein. Wenn Sie dann noch den Variablenamen für die Session-ID so wählen, dass er schwer zu erraten ist, haben Sie schon ein gewisses Mass an Sicherheit erreicht!

...

Das hat diese Frage in mir geweckt.
Und ich sehe gerade, dass ich an etwas völlig anderes gedacht habe. oO

ob_start() bedeutet, dass der von PHP erzeugte Quelltext zwischengespeichert wird. Dadurch wird es z.B. möglich, header nach echo aufzurufen, was aber schlechter Stil ist imho.
ob_end_flush() liest den ZWischenspeicher und gibt ihn aus.

...

Okay. \o_

[mitaki]

Danke. Hat geklappt nachdem ich auch noch ein bisschen Code in den Überschriften Formatierungen geändert hab.

...

Freut mich

Das Problem machte in Form eines "owned" Bildes auf jeder zu verwaltenden Seite auf sich aufmerksam...

...

Und du meinst oder kannst bestätigen, dass die Lücke bei der HTTP-Authentifizierung lag?

Wenn Sie dann noch den Variablenamen für die Session-ID so wählen, dass er schwer zu erraten ist, haben Sie schon ein gewisses Mass an Sicherheit erreicht!

...

Ich sehe da keinen Zusammenhang. Benutzerdaten kommen entweder aus Cookies, oder Formularen (ein kleiner Teil auch auch _SERVER-Daten). Diese haben meist nicht viel mit den _SESSION-Schlüsseln zu tun. Ohnehin frage ich mich, wie der Autor darauf kommt, diese Schlüssel seien eine Gefahr.

Meiner Meinung nach ist dieses Tutorial nicht sehr gehalt- und sinnvoll. Der Autor scheint weder sonderlich recherchiert noch den Text überprüft zu haben.

[Tessio]

Und du meinst oder kannst bestätigen, dass die Lücke bei der HTTP-Authentifizierung lag?

...

Nope.
Aber nunja.
Es ist kurz nach der Einführung des ACPs passiert, davor war alles okay und ich hab das FTP Passwort danach nicht geändern, trotzdem kam das nie wieder.
Naja, ich weiss ja auch nicht, du bist hier der Profi, bei mir ists dann doch nur die Intuition.

Ich sehe da keinen Zusammenhang. Benutzerdaten kommen entweder aus Cookies, oder Formularen (ein kleiner Teil auch auch _SERVER-Daten). Diese haben meist nicht viel mit den _SESSION-Schlüsseln zu tun. Ohnehin frage ich mich, wie der Autor darauf kommt, diese Schlüssel seien eine Gefahr.

...

Wie dem auch sei, ich wollte halt nur ein Loginscript anschaun und da das funktionierte, hab ichs genommen.
Danke für deine Aufklärung.

Meiner Meinung nach ist dieses Tutorial nicht sehr gehalt- und sinnvoll. Der Autor scheint weder sonderlich recherchiert noch den Text überprüft zu haben.

...

Ausgeschlssn! :D

_o/

[mitaki]

Naja, ich weiss ja auch nicht, du bist hier der Profi, bei mir ists dann doch nur die Intuition.

...

Die HTTP-Methode ist meines Erachtens schon sehr sicher und nicht für dein Problem verantwortlich. Natürlich schließt das keine Passworte wie „password1“ mit ein

Wie dem auch sei, ich wollte halt nur ein Loginscript anschaun und da das funktionierte, hab ichs genommen.

...

Ich will dir nicht den Mut nehmen, wie es mir jetzt vorkommt.
Loginbereiche sind ein relativ komplexes Thema, ich gebe dir folgenden Gedanken mit auf den Weg:

Überlege, welche Möglichkeiten du hast, nach dem Login angemeldet zu bleiben. Dann überlege dir, wie du prüfen kannst, ob auch tatsächlich der echte Benutzer die Seite aufgerufen hat und erlaube bzw. verweigere den Zugriff je nach Ergebnis. Es besteht dann zwar ein Restrisiko, aber das ist ja immer gegeben.

Ausgeschlssn!

...

Ach komm^^ Wie viele der selbsternannten Profis sind schon echt?

[Tessio]

Die HTTP-Methode ist meines Erachtens schon sehr sicher und nicht für dein Problem verantwortlich. Natürlich schließt das keine Passworte wie „password1“ mit ein

...

Das Password war ein 32-Stellen String, also mit MD5 generiert (ich glaube das verschlüsselte Wort war Ananasbananensplitcouch), das von dem damals noch alleineherrschenden Admin (meine Wenigkeit) in Textform auf einem Zettel niedergeschrieben war und nein, bei mir kommt keiner ins Haus, der auch nur die Seite kennt. However. Passwort war sicher. Relativ.

Ich will dir nicht den Mut nehmen, wie es mir jetzt vorkommt.
Loginbereiche sind ein relativ komplexes Thema, ich gebe dir folgenden Gedanken mit auf den Weg:

Überlege, welche Möglichkeiten du hast, nach dem Login angemeldet zu bleiben. Dann überlege dir, wie du prüfen kannst, ob auch tatsächlich der echte Benutzer die Seite aufgerufen hat und erlaube bzw. verweigere den Zugriff je nach Ergebnis. Es besteht dann zwar ein Restrisiko, aber das ist ja immer gegeben.

...

Hmhm, danke, mein eigentliches Problem ist dann doch eher die Unkreativität, da mir jetzt kein besserer Weg als der im oben gespoilerten Loginscript einfällt...
Ich bin noch ein Greenhorn. =_=

Ach komm^^ Wie viele der selbsternannten Profis sind schon echt?

...

Alles klar. mitaki ist ein Bot. :o

*shrug* Hmhm, hoffentlich leidet der Thread nicht allzu dolle an diesem Dialog. *hust* >.>

[Manni]

Ah, hab die Seite wiedergefunden. _o/
Hans Wurst backt Pflaumen
Ich zitiere :

Die Sicherheit Ihrer Webseite ist beim Einsatz von Sessions nur dann gefährdet, wenn jemand die aktuelle Session-Id errät oder Zugriff auf Ihren Session-Ordner erlangt. Insbesondere bei kommerziellen Seiten sollte ein solcher Zugriff ausgeschlssen sein und der Session-Ordner auch nicht unbedingt den Standartnamen besitzen und im Standartverzeichnis (z.b C...\tmp) abgelegt sein. Wenn Sie dann noch den Variablenamen für die Session-ID so wählen, dass er schwer zu erraten ist, haben Sie schon ein gewisses Mass an Sicherheit erreicht!

...

Das hat diese Frage in mir geweckt.
Und ich sehe gerade, dass ich an etwas völlig anderes gedacht habe. oO

...

Wenn irgendjemand in deinem Session-Verzeichnis rumpfuschen kann, läuft schonmal irgendwas ziemlich falsch. Dann sollte man sich lieber darüber Gedanken darüber machen, was man da falsch gemacht hat.
Ich würde außerdem das Passwort nicht in der Session speichern, schon allein um es vor einem Auslesen durch den Admin zu schützen.

Ich würde eher darauf tippen, das jemand dein FTP Passwort herausgefunden oder auf eine andere Art und Weise Zugriff auf den FTP Server bekommen hat. (auch wenn du das Passwort danach nicht geändert hast...)

[mitaki]

Alles klar. mitaki ist ein Bot.

...

Du schmeichelst mir.

Ich selbst würde mich nicht als Profi bezeichnen, dazu gibt es in diesem bereich noch viel zu vieles, dass ich nicht verstehe. Aber ich bin in der Hinsicht immer lernbereit, so zur Info, ne?^^

*shrug* Hmhm, hoffentlich leidet der Thread nicht allzu dolle an diesem Dialog. *hust* >.>

...

Wenn wir jetzt aufhören, eher nicht

[Antares]

Ich suche eine Möglichkeit den Zugriff zu bestimmten Inhalten nur registrierten Nutzern zu gewähren.
Lass ich die entsprechende Datei includen und man ist nicht eingeloggt, so wird die() ausgeführt.
Alleerdings wird sämtlicher Code, der nach die() komtm nicht mehr berücksichtigt, also ist in diesem Moment (auch wenn es nur ein kurzer ist das rechts Menü und der Footer weg.
Gibt es da eine Alternative zu die() ?

[Blakkeight]

evtl. exit().

e:
INFO

[mitaki]

Falls es dir nicht zu komplex ist würde ich dir raten, am Anfang der Hauptdatei die Benutzerprüfung einzubauen und darauf aufbauend eine Variable oder Konstante zu erstellen, die true ist, wenn man sich richtig eingeloggt hat und false, wenn es beim Login Probleme gab.

[Antares]

Öhm, ich bin ja auch selten blöd..

Ich habe mir diesen Code gebastelt:

PHP-Code:

if($erfolg != "login")
   {
   die ("Bitte erst <a href=\"index.php\">einloggen</a>");
}
else
{
// hier folgt der normale Seitenaufbau... 

So.
Da frage ich mich, warum ich eigentlich nicht gleich echo() anstatt die() verwendet habe -.-

Also, von daher hat sichs erledigt.

[Tessio]

Öhm, ich bin ja auch selten blöd..

Ich habe mir diesen Code gebastelt:

PHP-Code:

if($erfolg != "login")
   {
   die ("Bitte erst <a href=\"index.php\">einloggen</a>");
}
else
{
// hier folgt der normale Seitenaufbau... 

So.
Da frage ich mich, warum ich eigentlich nicht gleich echo() anstatt die() verwendet habe -.-

Also, von daher hat sichs erledigt.

...

Unsicher. Schau bezüglich der Variable mal in mitakis neuestes Meisterwerk, dann wirst du wissen, wie man mit der nötigen Information Buhmann spielen kann.

[Antares]

Unsicher. Schau bezüglich der Variable mal in mitakis neuestes Meisterwerk, dann wirst du wissen, wie man mit der nötigen Information Buhmann spielen kann.

...

Schon, aber register_globals ist sowieso ausgeschaltet.

[Blakkeight]

Ich denke mal er meinte damit das du es auf diese weise machen sollst:

PHP-Code:

if($_GET['erfolg'] != "login")
   {
   die ("Bitte erst <a href=\"index.php\">einloggen</a>");
}
else
{
// hier folgt der normale Seitenaufbau... 

[Tessio]

Ich würde das aber mit $_SESSION lösen, da man den Wert von $_GET-Variablen manuell ändern kann.

[Antares]

Nunja, also eigentlich wird die Variable $erfolg bei einem erfolgreichen Login auf "login" gesetzt und in der variable $_SESSION["status"] gespeichert.

Also, wo ist dabei das Problem?