Passwort sicher?
- Ersteller Sunnyboy
- Erstellt am
Körnerbrötchen
Aktives Mitglied
Kannst du uns irgendwie beweisen, dass du der Besitzer der Seite bist? Zum Beispiel durch das Einbringen eines Kommentars in den Quelltext? Ansonsten wäre es illegal. ;)
Bizzi
Neues Mitglied
Manche leute haben echt einen Vogel XD
Sry das ich das Sage.
Aber du willst, das wir "dein passwort" knacken?
Unmöglich.
Warum?
Du vergleichst in deiner index.php ein vorgegebenes Passwort. Stimmt dies nicht überein, so krazt es des script wenig - Denn hier wird das Passwort ja überprüft.
Das einzigste was du Fragen müsstest:
Ist dein Passwort-Script gegen Injections geschüzt.
Sry das ich das Sage.
Aber du willst, das wir "dein passwort" knacken?
Unmöglich.
Warum?
Du vergleichst in deiner index.php ein vorgegebenes Passwort. Stimmt dies nicht überein, so krazt es des script wenig - Denn hier wird das Passwort ja überprüft.
Das einzigste was du Fragen müsstest:
Ist dein Passwort-Script gegen Injections geschüzt.
Körnerbrötchen
Aktives Mitglied
Nichts da. Wieso wäre das illegal? Viele größere Firmen lassen ihre Netzwerke so auf Schwachstellen überprüfen.
xXxPeterPanxXx
Neues Mitglied
Und weil sie so nett sind überprüfen Sie die Sicherheit der Konkurrenz gleich mit.
Körnerbrötchen
Aktives Mitglied
Auch das wäre nicht illegal…
@xXxPeterPanxXx: Was meinst du?
@xXxPeterPanxXx: Was meinst du?
Vielen Dank
Ich habe schon immer geahnt, dass ich einen Vogel habe :-)
Ich bin nicht auf der suche nach illegalen Leuten. Es ist nun ein Kommentar am Anfang vom Quelltext der heisst: bitte Passwort checken
Allerdings bin ich schon recht sicher, dass es gut gesichert ist, da scheins einige von euch doch etwas versucht haben.
Also nun viel Spass beim legalen oder illegalen Versuchen.
LG Sunnyboy
Ich habe schon immer geahnt, dass ich einen Vogel habe :-)
Ich bin nicht auf der suche nach illegalen Leuten. Es ist nun ein Kommentar am Anfang vom Quelltext der heisst: bitte Passwort checken
Allerdings bin ich schon recht sicher, dass es gut gesichert ist, da scheins einige von euch doch etwas versucht haben.
Also nun viel Spass beim legalen oder illegalen Versuchen.
LG Sunnyboy
Weil ich 1. ein Passwortschutz habe, damit nicht jeder auf die Seite kann (dieser waer also fuer die Katz, wenn ich ihn hier poste) 2. da der Passwortschutz aus mehreren Teilen besteht und ich euch nicht eine Seite Quelltext posten will. 3. Wenn niemand auf die Seite kommt ohne den Quelltext, muss er ja sicher genug sein.
Aber Im fall, dass jemand darauf kommt bitte ich euch mir zu sagen wie, so dass ich den Fehler beheben kann.
Vielen Dank fuer alle Hilfen
LG Sunnyboy
Was für ein dummer Post.
Du sollst nur den Loginteil posten, nicht den Inhalt, den du schützen willst.
Und nur weil es ein paar ein, zwei Mal versucht haben, muss es nicht sicher sein.
Wenn du irgendwas vergessen oder falsch gemacht haben solltest und jemand bisschen Zeit investiert, der da unbedingt rein will, kriegt es auch hin.
-.-
Du sollst nur den Loginteil posten, nicht den Inhalt, den du schützen willst.
Und nur weil es ein paar ein, zwei Mal versucht haben, muss es nicht sicher sein.
Wenn du irgendwas vergessen oder falsch gemacht haben solltest und jemand bisschen Zeit investiert, der da unbedingt rein will, kriegt es auch hin.
-.-
Also dann wenn die Antwort so dumm war :cry:
Der 1. Teil in index.php
2. Teil in home.php
3. Teil (kontrolle) test.php
Der 1. Teil in index.php
Code:
<?php
include("test.php");
if (isset($_POST["Name"])) {
if ($_POST["Passwort"] == $Passwort) {
$_SESSION[$Name] = true; //Cookie pflanzen
header("Location: home.php" ); // zu home.php gehen
}
}
?>
Code:
<?php
include("test.php");
if(!isset($_SESSION[$Name]))
{
header("Location:index.php");
}
?>
Code:
<?php
$Passwort = "mein Passwort"; // Passwort
@session_start();
?>
mermshaus
Senior HTML'ler
Direkt hinter die header-Befehle, also in die darauffolgenden Zeilen. Es ist nicht auszuschließen (vielleicht sogar der Normalfall, ich bin nicht sicher), dass ein PHP-Script noch "unsichtbar" weiterläuft, nachdem der header-Befehl gesetzt wurde. Da das manchmal zu unvorhergesehenen Effekten führen kann, lieber immer ein exit; setzen.
Zum Beispiel:
Setz mal error_reporting(-1); (alle Fehler ausgeben) als erste Zeile in test.php. Dann dürfte sich der Interpreter (bei normalen Servereinstellungen) darüber beschweren, dass eine Variable $Name nicht gesetzt ist. Stattdessen könntest du besser $_SESSION['loggedin'] = true; oder so verwenden, also einen konstanten String-Index.
Noch einige Tipps/Empfehlungen (vielfach nur stilistisch):
- include, include_once, require und require_once sind Sprachkonstrukte, keine Befehle. Die Klammern dahinter sind deshalb unnötig (vergleiche etwa echo 'Hallo Welt!';).
- require deutet an, dass das Script abbrechen muss, wenn die nachgefragte Datei nicht gefunden wird. (Bei include würde das Script weiterlaufen.) Das "_once" deutet an, dass die nachgefragte Datei nur ein einziges Mal eingebunden werden darf. (Das ist an der Stelle nicht unbedingt notwendig, aber hey.)
- Für Strings, die keine Variablenersetzung (echo "Hallo $name";) enthalten, werden üblicherweise einfache Anführungszeichen genutzt, um eben dies anzuzeigen.
- Die URL innerhalb des Location-Headers muss nach Spezifikation als absoluter Pfad angegeben werden. (Der absolute Pfad ließe sich dann wiederum dynamisch zusammenbauen aus Informationen aus $_SERVER. Dazu war ich jetzt zu faul. ;))
Zum Beispiel:
PHP:
<?php
require_once 'test.php';
if(!isset($_SESSION[$Name]))
{
header('Location: http://osswald.li/index.php');
exit;
}
?>Setz mal error_reporting(-1); (alle Fehler ausgeben) als erste Zeile in test.php. Dann dürfte sich der Interpreter (bei normalen Servereinstellungen) darüber beschweren, dass eine Variable $Name nicht gesetzt ist. Stattdessen könntest du besser $_SESSION['loggedin'] = true; oder so verwenden, also einen konstanten String-Index.
Noch einige Tipps/Empfehlungen (vielfach nur stilistisch):
- include, include_once, require und require_once sind Sprachkonstrukte, keine Befehle. Die Klammern dahinter sind deshalb unnötig (vergleiche etwa echo 'Hallo Welt!';).
- require deutet an, dass das Script abbrechen muss, wenn die nachgefragte Datei nicht gefunden wird. (Bei include würde das Script weiterlaufen.) Das "_once" deutet an, dass die nachgefragte Datei nur ein einziges Mal eingebunden werden darf. (Das ist an der Stelle nicht unbedingt notwendig, aber hey.)
- Für Strings, die keine Variablenersetzung (echo "Hallo $name";) enthalten, werden üblicherweise einfache Anführungszeichen genutzt, um eben dies anzuzeigen.
- Die URL innerhalb des Location-Headers muss nach Spezifikation als absoluter Pfad angegeben werden. (Der absolute Pfad ließe sich dann wiederum dynamisch zusammenbauen aus Informationen aus $_SERVER. Dazu war ich jetzt zu faul. ;))
Zuletzt bearbeitet:
Ah super...
Das sind so Dinge, die ich nie gelernt habe, weil ich PHP von allen moeglichen Quellen lernte. So war das immer ein wenig verschieden :-)
Ich werde mich dann mal ein Weilchen damit beschaeftigen.
Und wie siehts mit Passwort knacken aus? Muss man da das Richtige finden oder gibts eine Loesung ohne dass?
LG Sunnyboy
Das sind so Dinge, die ich nie gelernt habe, weil ich PHP von allen moeglichen Quellen lernte. So war das immer ein wenig verschieden :-)
Ich werde mich dann mal ein Weilchen damit beschaeftigen.
Und wie siehts mit Passwort knacken aus? Muss man da das Richtige finden oder gibts eine Loesung ohne dass?
LG Sunnyboy
mermshaus
Senior HTML'ler
Von der grundsätzlichen Vorgehensweise ist es wie gesagt okay (im Sinne von sicher), an der Umsetzung kann man im Prinzip noch was verbessern, aber es ist immer etwas albern, zu sehr an 8 Zeilen Code rumzubasteln.
Das 'Name'-Feld bräuchtest du zum Beispiel eigentlich nicht.
Und die Sache mit $_SESSION[$Name] funktioniert(e) (ich hoffe, du hast das geändert ;)) allerdings nur aufgrund eines nicht unbedingt erwartbaren Verhaltens von PHP.
$_SESSION[$Name] = true; setzt den Index '' (leerer String) auf true, weil $Name eben keinen Wert besitzt. Das heißt, du hättest stattdessen auch $_SESSION[''] schreiben können. Das ist natürlich etwas seltsam.
Die meisten Angriffsmethoden zielen übrigens nicht darauf ab, ein Passwort zu "erraten", sondern auf andere Weise Zugriff (auf Server, Datenbank oder auch nur ein Login) zu bekommen. Das heißt zum Beispiel, bei einem Formular Felder nicht mitzusenden oder Felder als Arrays zu senden, die eigentlich keine Arrays sein sollten, um die Backend-Programmierung zu verwirren und so vielleicht Hinweise auf Angriffspunkte zu erhalten. Oder auf gut Glück Dateien wie "config.ini" oder ähnliche abzufragen, die eventuell von Außen erreichbar sind (Fehler in der Serverkonfiguration/-handhabung ausnutzen). Alle Daten, die vom Benutzer kommen, sind zudem beliebig manipulierbar. Das gilt vor allem für GET-, POST- und COOKIE-Felder. SESSION-Werte sind grundsätzlich als sicher anzusehen, da der Benutzer dort nur die Session-ID, die lokal im Cookie gespeichert wird, verändern kann.
(Es gibt ein paar Angriffsversuche auf Sessions, aber bei denen müssen in der Regel so viele Voraussetzungen gegeben sein, dass sie eher unrealistisch sind.)
Die häufigsten Angriffsarten sind:
- SQL-Injection
- Cross-Site Scripting
Bei PHP kommen ab und an noch Probleme mit "register globals" hinzu.
- PHP: Using Register Globals - Manual
Schön sind auch Dateiuploads, die das Hochladen von *.php-Dateien ermöglichen, die dann unter Umständen ausführbar sind, falls sie direkt über das Web aufgerufen werden können.
Das 'Name'-Feld bräuchtest du zum Beispiel eigentlich nicht.
Und die Sache mit $_SESSION[$Name] funktioniert(e) (ich hoffe, du hast das geändert ;)) allerdings nur aufgrund eines nicht unbedingt erwartbaren Verhaltens von PHP.
$_SESSION[$Name] = true; setzt den Index '' (leerer String) auf true, weil $Name eben keinen Wert besitzt. Das heißt, du hättest stattdessen auch $_SESSION[''] schreiben können. Das ist natürlich etwas seltsam.
Die meisten Angriffsmethoden zielen übrigens nicht darauf ab, ein Passwort zu "erraten", sondern auf andere Weise Zugriff (auf Server, Datenbank oder auch nur ein Login) zu bekommen. Das heißt zum Beispiel, bei einem Formular Felder nicht mitzusenden oder Felder als Arrays zu senden, die eigentlich keine Arrays sein sollten, um die Backend-Programmierung zu verwirren und so vielleicht Hinweise auf Angriffspunkte zu erhalten. Oder auf gut Glück Dateien wie "config.ini" oder ähnliche abzufragen, die eventuell von Außen erreichbar sind (Fehler in der Serverkonfiguration/-handhabung ausnutzen). Alle Daten, die vom Benutzer kommen, sind zudem beliebig manipulierbar. Das gilt vor allem für GET-, POST- und COOKIE-Felder. SESSION-Werte sind grundsätzlich als sicher anzusehen, da der Benutzer dort nur die Session-ID, die lokal im Cookie gespeichert wird, verändern kann.
(Es gibt ein paar Angriffsversuche auf Sessions, aber bei denen müssen in der Regel so viele Voraussetzungen gegeben sein, dass sie eher unrealistisch sind.)
Die häufigsten Angriffsarten sind:
- SQL-Injection
- Cross-Site Scripting
Bei PHP kommen ab und an noch Probleme mit "register globals" hinzu.
- PHP: Using Register Globals - Manual
Schön sind auch Dateiuploads, die das Hochladen von *.php-Dateien ermöglichen, die dann unter Umständen ausführbar sind, falls sie direkt über das Web aufgerufen werden können.
Danke viel mal...
Dann mueste man also schon relativ gut sein, um ohne passwort erraten hineinzukommen. Ich nehme allerdings sowieso nicht an, dass jemand meine Seite Hacken will, die ist zu uninteressant um diesen Aufwand Aufzubringen :-)
Vielen Dank also allen
LG Sunnyboy
PS: Im fall, dass jemand rein kommt, bitte sagen wie.
Dann mueste man also schon relativ gut sein, um ohne passwort erraten hineinzukommen. Ich nehme allerdings sowieso nicht an, dass jemand meine Seite Hacken will, die ist zu uninteressant um diesen Aufwand Aufzubringen :-)
Vielen Dank also allen
LG Sunnyboy
PS: Im fall, dass jemand rein kommt, bitte sagen wie.
