Allgemeiner Fragethread

[mitaki]

Ah ich seh grad ich habe noch das die() vergessen. =)

...

Wobei die() der schlechteste aller Fehlerhandler ist. Nach die() wird das Skript nicht mehr weiterverarbeitet.

PHP-Code:

<?php
 echo 'test';
 die('stirb');
 echo 'ende';
?>

Siehste?

Beim Testen mag das noch in Ordnung sein, aber bei einer öffentlichen WebApp wäre das unter Umständen fatal.

[Blakkeight]

Stimmt eigentlich. =)
Mal gucken was ich so naechste Woche hingebastelt bekomme.

Danke schon mal.

[drunken monkey]

Wobei die() der schlechteste aller Fehlerhandler ist. Nach die() wird das Skript nicht mehr weiterverarbeitet.

...

Naja, oft ist das ja genau das, was man will. o_O Man muss halt nur vorher alles machen, was man bei einem Fehler machen will, aber dann ist an die () oder exit doch nichts auszusetzen. .___.
Es sei denn natürlich, der Fehler ist nicht so schwer und man kann trotzdem weitermachen...

Das ist mir bewusst, das ist ja auch eine eigene Funktion und die wollte ich ja nun mit mysql_query() OR mysqlErrorLog() aufrufen. Ansich Funktionierte ja auch die Funktion nur halt nicht in Verbindung mit OR...

...

Also dein Problem ist, dass selbst wenn mysql_query() "false" zurückgibt, mysqlErrorLog() nicht aufgerufen wird? o_O Erschiene mir merkwürdig, bei mir funktioniert das problemlos! Bist du dir sicher, dass es nicht aufgerufen wird, und nicht nur nicht funktioniert?
Ansonsten würde ich das die() weglassen und stattdessen exit entweder in die Funktion schreiben, oder, noch besser, mitakis sauberere Version - ohne "or", dafür mit anschließender if-Abfrage - mit einem exit drin verwenden. Also in etwa:

PHP-Code:

$query = 'SELECT ... WHERE ...';
$sql = mysql_query ($query, $db); // Man sollte besser immer auch den Zeiger auf die Datenbank übergeben
if (!$sql) {
    mysqlErrorLog ();
    exit;
} 

PHP-Code:

$query = "SELECT ... WEHRE ...";
$sql = mysql_query($query) OR die(mysqlErrorLog());
# und dann noch die If abfragen. ;) 

...

Ich denke zwar nicht, dass es das ist, aber du hast "WHERE" falsch geschrieben, auch im vorigen Post.

[Blakkeight]

Ich denke zwar nicht, dass es das ist, aber du hast "WHERE" falsch geschrieben, auch im vorigen Post.

...

Im Code bei mir ist es richtig geschrieben, hier sollte es ja auch nur ein bsp. sein wie es bei mir ungefaehr aussieht, den Original Code habe ich leider auch nicht hier, erst ende der Woche wenn mein Laptop wieder Zuhause ist. (Aus Faulheit auf Schule gelassen.)

Wie gesagt ich Spiel mir die Woche noch einen mit weg und dann sehen wa weiter und ich meld mich noch mal.

Danke schon mal fuer eure Bemuehungen.

[Tessio]

Hi Leute.
Also, ich wollte mich mal in Sachen Sicherheit weiterbilden.
Dabei geht es mir um zwei große Bereiche : Ein Loginscript und Eintragen von Formulartexten in Datenbanken.

Zum ersteren : Kann man im Array $_SESSION rumfummeln?
Bei den meisten Tuts wird der geschütze Inhalt dann gezeigt, wenn ein bestimmter Wert in das Array SESSION geschrieben wurde, also zum Beispiel, wenn $_SESSION[benutzer_id] angegeben ist, was passiert, wenn man die Logindateien korrekt eingegeben hat.
Ist das sicher? Ich habe zur Sicherheit noch einen anderen notwendigen Wert in das Array schreiben lassen, wenn die Daten korrekt waren, denn auf manchen Seiten wird geschrieben, man soll den Namen des Schlüssels im SESSION Array nicht zu einfach machen.
Folglich muss man in dem Array ja auch rumwurschteln können, oder wie meinen die das?

Zum letzten :
Ich bin allgemein in solchen Sachen nicht sonderlich begabt, also in Sachen Sicherheit.
Wenn ich beispielsweise in einem Kommentarsystem die Eingaben so wie sie da stehen in die Datenbank eintrage und sie erst beim Ausgeben mit htmlspecialchars und nl2br umwandeln lasse, kann das auch Schaden in der Datenbank oder sonst wo anrichten?
Gebet mir euer Wissen über Sicherheit, ich brauche es. ;_;
Und ja ich weiss, dass mal eigentlich keine totale Sicherheit erreichen kann.

[Blakkeight]

Zu den Sessions, vlt findest ja hier was.

Vorm eintragen in die DB:
Addslashes
Trim
HTMLSpecialChars
Strip Tags

Beim Auslesen/Anzeigen:
nl2br
Stripslashes

So mach ich es, damit keiner unerwuenschten Code reinschreibt.

[mitaki]

@Samogas. Das mit der Session verstehe ich nicht ganz. Arbeitest du nach einem Tutorial und verstehst nicht was gemeint ist?

Zur Sache mit DB/Benuterangaben:

Momentan wird bei den meisten PHP-Anbietern auf Daten, die vom Benutzer kommen (Cookie-, Get- und Postdaten) automatisch addslashes angewendet.

Es ist empfehloenswert, bei Daten, die du in die Datenbank schreibst zuerst stripslashes() anzuwenden und dann die datenbankspezifische Maskierungsfunktion [MySQL: mysql_real_escape_string()]. Dadurch werden alle Zeichen, die für das Datenbanksystem gefährlich sind maskiert (bzw. escaped).

Wenn du die Daten aus der Datenbank herausholst sind diese nicht mehr escaped, ist auch meistens nicht nötig. Je nachdem, wozu du diese Daten dann verwenden willst kannst du htmlentities() und nl2br() darauf anwenden.

[Tessio]

Erstmal danke an euch beide. ^_^

@Samogas. Das mit der Session verstehe ich nicht ganz. Arbeitest du nach einem Tutorial und verstehst nicht was gemeint ist?

...

Doch doch, ich verstehe es schon.
Ich hab ja nur gefragt, ob der Internetnutzer auf einer fremden Seite in einer gestarteten Session die Werte in dem SESSION-Array verändern kann, weil bei diesem Turorial halt gesagt wurde, man soll die Benennung schwerstmöglich machen.
Das wäre aber sehr sinnlos, wenn man das könnte, also wird es wohl nicht so sein.
Wie sieht es denn mit der Session-ID aus? Die wird ja, wenn nicht anders eingestellt, als Cookie gespeichert.
Sollte man sich bei der Art der ID-Speicherung noch Gedanken um die Sicherheit machen?
Der einzige Weg, der mir einfällt, um an eine S-ID von einem anderen zu kommen, wäre, dass dieser an dessen PC geht oder sich die ID geben lässt.
Oder gibts da auch fießere Tricks?
(Wie ihr sicher merkt, habe ich schon ganz böse Erfahrungen in Sachen Admin Bereich machen müssen ;_;)

Zur Sache mit DB/Benuterangaben:

Momentan wird bei den meisten PHP-Anbietern auf Daten, die vom Benutzer kommen (Cookie-, Get- und Postdaten) automatisch addslashes angewendet.

Es ist empfehloenswert, bei Daten, die du in die Datenbank schreibst zuerst stripslashes() anzuwenden und dann die datenbankspezifische Maskierungsfunktion [MySQL: mysql_real_escape_string()]. Dadurch werden alle Zeichen, die für das Datenbanksystem gefährlich sind maskiert (bzw. escaped).

Wenn du die Daten aus der Datenbank herausholst sind diese nicht mehr escaped, ist auch meistens nicht nötig. Je nachdem, wozu du diese Daten dann verwenden willst kannst du htmlentities() und nl2br() darauf anwenden.

...

Vielen dank. :)

Zu den Sessions, vlt findest ja hier was. ;)

...

Nicht wirklich das, was meine Frage direkt beantwortet, aber auch nützlich, danke. ^^

Vorm eintragen in die DB:
Addslashes
Trim
HTMLSpecialChars
Strip Tags

Beim Auslesen/Anzeigen:
nl2br
Stripslashes

So mach ich es, damit keiner unerwuenschten Code reinschreibt.

...

Alles klar. _o/

[mitaki]

Wie ihr sicher merkt, habe ich schon ganz böse Erfahrungen in Sachen Admin Bereich machen müssen ;_;

...

Wenn das deine Problematik ist, dann ist HTTP-Authentifizierung (.htaccess) empfehlenswert. Sehr sicher und bei einem entsprechendem Passwort nur mit BruteForce knackbar

Ich hab ja nur gefragt, ob der Internetnutzer auf einer fremden Seite in einer gestarteten Session die Werte in dem SESSION-Array verändern kann, weil bei diesem Turorial halt gesagt wurde, man soll die Benennung schwerstmöglich machen.

...

Ja, sofern sich dieser Benutzer die entsprechende Session zu eigen macht und die Anwendung entsprechende Bearbeitungsformulare bietet.
Hast du eventuell die Adresse dieses Tutorials parat?

Wie sieht es denn mit der Session-ID aus? Die wird ja, wenn nicht anders eingestellt, als Cookie gespeichert.

...

Unter Umständen kann die SID dennoch in die URI geschrieben werden. Dann reicht eventuell eine kopierte Adresse um sich die Sitzung zu eigen zu machen.

Sollte man sich bei der Art der ID-Speicherung noch Gedanken um die Sicherheit machen?

...

Alles was irgendwie vom Benutzer kommt ist potenziell gefährlich. Wenn du eine Sitzung startest und die ID per URI weitergibst kannst du z.B. prüfen, ob bei einem Neuaufruf mit dieser ID die IP-Adresse noch identisch ist.

Der einzige Weg, der mir einfällt, um an eine S-ID von einem anderen zu kommen, wäre, dass dieser an dessen PC geht oder sich die ID geben lässt.

...

Es gibt mehrere Wege, Session IDs oder allgemein Cookies zu stehlen, das hängt meist mit fehlerhafter Programmierung zusammen.

Nebenbei zur strip_tags-Funktion. Diese ist nur bedingt nützlich, da anscheinend alles was die Form <*> hat entfernt wird.

[Tessio]

Wenn das deine Problematik ist, dann ist HTTP-Authentifizierung (.htaccess) empfehlenswert. Sehr sicher und bei einem entsprechendem Passwort nur mit BruteForce knackbar

...

Das ACP war mit .htaccess geschützt. :/
Halt nur mit .htaccess, jetzt will ichs so sicher wie möglich haben. ;_;

Ja, sofern sich dieser Benutzer die entsprechende Session zu eigen macht und die Anwendung entsprechende Bearbeitungsformulare bietet.

...

Nunja, klingt beunruhigend. ^^

Hast du eventuell die Adresse dieses Tutorials parat?

...

Indirekt. Das war eher sowas "fertiges", was ich mir angeschaut und in der Art nachgeschrieben habe. Ich kann aber gerne zeigen, was das System macht :

In der index.php, also dem eigentlichen Admin Bereich, wird checkuser.php inkludiert (gibts das Wort?).
In der steht :

PHP-Code:

<?php
 session_start ();
 if (!isset ($_SESSION["blablabla"])) {
   header ("Location: formular.php");
 }
?>

formular.php :

PHP-Code:

<?php session_start (); ?>
<html>
 <head>
   <title>Login</title>
 </head>

 <body>
<?php
 if (isset ($_REQUEST["fehler"])) {
   echo "Die Zugangsdaten waren ungültig.";
 }
?>

<form action="login.php" method="post">
  Name: <input type="text" name="name" size="20" /><br />
  Kennwort: <input type="password" name="pwd" size="20" /><br />
  <input type="submit" value="Login" />
</form>

 </body>
</html>

Nicht den Code, also den Rest außer dem Script kritisieren, ich schreibs ja noch um. >_>

login.php :

PHP-Code:

<?php
 session_start ();
 $connectionid = mysql_connect ("localhost", "...", "...");
if (!mysql_select_db ("...", $connectionid)) {
  die ("Keine Verbindung zur Datenbank");
}

$sql = "SELECT ".
    "ID, name ".
  "FROM ".
    "...".
  "WHERE ".
    "(name like '".$_REQUEST["name"]."') AND ".
    "(kennwort = '".MD5($_REQUEST["pwd"])."')";
$result = mysql_query ($sql);

if (mysql_num_rows ($result) > 0)
{
  $data = mysql_fetch_array ($result);

  $_SESSION["blabla"] = $data["ID"];
  $_SESSION["blabla"] = $data["name"];

  header ("Location: index.php");
}
else
{
  header ("Location: formular.php?fehler=1");
}

Ja, schrecklicher Code, besonders der SQL Befehl. :x
Wird auch umgeschrieben.

Die logout.php:

PHP-Code:

<?php
// Wird ausgeführt um mit der Ausgabe des Headers zu warten.
ob_start ();

session_start ();

if (!isset ($_SESSION["blabla"]))
{
  die('Warst nicht angemeldet!');
}


session_unset ();
session_destroy ();

header ("Location: formular.php");
ob_end_flush ();
?>

Um ehrlich zu sein weiss ich nicht, was ob_start und ob_end_flush bedeuten. ;_;
--- Ja. Ich wusste nicht so, aber ich hab mal ein paar Sachen in den Arrays zensiert, vielleicht wars ja nicht nötig. ._.

Alles was irgendwie vom Benutzer kommt ist potenziell gefährlich. Wenn du eine Sitzung startest und die ID per URI weitergibst kannst du z.B. prüfen, ob bei einem Neuaufruf mit dieser ID die IP-Adresse noch identisch ist.

...

Naja, ich gehe die ID ja nicht per URI weiter.

Danke.

[mitaki]

Das ACP war mit .htaccess geschützt. :/
Halt nur mit .htaccess, jetzt will ichs so sicher wie möglich haben. ;_;

...

Wo war dann das Problem?

Nunja, klingt beunruhigend.

...

Wenn jemand deine Sitzung klauen kann ist das der Schlüssel. Letzteres bedeutet, dass du im ACP ermöglichst, Passwort und andere Daten, die du in $_SESSION speicherst verändern kannst.

Indirekt.

...

Schlecht, ich habe eher darauf abgezielt zu erfahren wer

Folglich muss man in dem Array ja auch rumwurschteln können, oder wie meinen die das?

...

sind.
Allerdings sind die SChlüssel eines Arrays nur selten gefährlich - imho.

Um ehrlich zu sein weiss ich nicht, was ob_start und ob_end_flush bedeuten. ;_;

...

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.

[underdark]

Den IE stört das negative margin oben in div.box_head. Wenn du für den IE das margin in div.box_head von rundherum -10px auf 0 -10px -10px umänderst (d.h. oben 0, links, rechts und unten aber weiterhin -10px margin) löst sich das Problem.

...

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

[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() ?