nicht angemeldet
User-Authentifizierung
Hi alle! Mal eine Frage:
Ich bau da eine Webseite, bei der die Benutzer mittels login/password in einen geschützten Bereich einloggen können. Ich benutze zur Authentifizierung eines eingeloggten Benutzers eine Zufallszeichenkette (50 Zeichen a-z), die in der URL übergeben wird. Benutzerinfos (Einlogzeitpunkt, Rechte, etc.) werden in einem temporären File abgelegt, das als Namen die übergebene Zeichenkette hat.
Frage ist: Wie sicher ist sowas? Was gibt es für Nachteile, die das ganze unsicher (knackbar) machen könnten? Was für andere Dinge sollte man zusätzlich benutzen (Cookie o.ä.)? Wo gibt es angreifbare Schwachpunkte?
Danke für die Tipps!
P.S.: Ich möchte möglichst keine Perl-Module benutzen und auch möglichst nicht dem Apache die Authentifizierung überlassen. Das ganze soll mal über SSL laufen, wenn's fertig ist (und ich mich etwas über SSL schlau gemacht hab *g*).
-
Hallo
Ich bau da eine Webseite, bei der die Benutzer mittels login/password in einen geschützten Bereich einloggen können. Ich benutze zur Authentifizierung eines eingeloggten Benutzers eine Zufallszeichenkette (50 Zeichen a-z), die in der URL übergeben wird. Benutzerinfos (Einlogzeitpunkt, Rechte, etc.) werden in einem temporären File abgelegt, das als Namen die übergebene Zeichenkette hat.
Frage ist: Wie sicher ist sowas? Was gibt es für Nachteile, die das ganze unsicher (knackbar) machen könnten? Was für andere Dinge sollte man zusätzlich benutzen (Cookie o.ä.)? Wo gibt es angreifbare Schwachpunkte?
Das hört sich an, als würde man die wichtigen Daten schon zu sehen bekommen, wenn man sich den Quellcode deiner Seite ansieht.
Schau dir das mal an:
http://forum.de.selfhtml.org/?t=38373&m=210064und natürlich _alle_ Antworten darauf sowie die erwähnte Seite selbst.
Ich denke, dort findest du genug hinweise darauf, was "Sicher" ist und wie es trotzdem umgangen werden kann.Viel Spaß
Detlef
-
Das hört sich an, als würde man die wichtigen Daten schon zu sehen bekommen, wenn man sich den Quellcode deiner Seite ansieht.
Also, hab ich mich soooo schief ausgedrückt? Sichtbar ist _nur_ eine 50-stellige SID (oder auch /[1]{50}$/ ) mehr nicht. Eine SID ist eine vom Perl-Script temporär erzeugte Kennummer, die nix mit dem Passwort oder Login des Benutzers zu tun hat, sondern diesen ausschließlich während einer Session bei den verschiedenen Scripts authentifiziert (und üblicherweise nach einer bestimmten Zeit der Inaktivität gelöscht wird). Oder, anders gesagt: Serverside, nix Clientside!
In der Überschrift meiner Frage stand daher _PERL_ und nicht Javascript. Aber danke für den Antwortversuch... *seuftz*
a-z ↩︎
-
-
Hi,
noch ein Antwortversuch:
Scheint auf den ersten Blick sicher zu sein. (Zumindest, wenn ich Dich richtig verstanden habe) - Allerdings nur dann, wenn verschluesselt wird (SSL). - Cookies machen nichts sicherer.Gruss,
Lude-
Scheint auf den ersten Blick sicher zu sein. (Zumindest, wenn ich Dich richtig verstanden habe) - Allerdings nur dann, wenn verschluesselt wird (SSL). - Cookies machen nichts sicherer.
Hi Lude! Danke für die Antwort.
Naja, das es auf den *ersten* Blick sicher ist, weis ich auch. Deswegen benutz ich es ja. Was mich interessiert, ist der 2. und 3. Blick.
Cookies machen es daher sicherer, das beim schließen des Browserfensters der Cookie weg ist. Sonst könnte ein Angreifer über Browser-History an die SID kommen (solange diese noch nicht das timeout erreicht hat).
Gruß
csx-
Hi,
Naja, das es auf den *ersten* Blick sicher ist, weis ich auch. Deswegen benutz ich es ja. Was mich interessiert, ist der 2. und 3. Blick.
Du implementierst Sicherheit. Und so wie Du es machst ist es OK. Den einzigen Angriffspunkt hats Du genannt. - Kannst Du etwas dagegen tun?
Gruss,
Lude-
Du implementierst Sicherheit. Und so wie Du es machst ist es OK. Den einzigen Angriffspunkt hats Du genannt. - Kannst Du etwas dagegen tun?
Ja, aber nur den einzigen, den *ich* bisher gefunden habe. Meine Frage (um darauf zurückzukommen) war, ob Andere vielleicht noch weitere Schwachstellen kennen / gefunden haben. Bisher scheint das nicht der Fall zu sein... Das ja schon mal ganz positiv...
Gruß
csx-
Hi,
Du implementierst Sicherheit. Und so wie Du es machst ist es OK. Den einzigen Angriffspunkt hats Du genannt. - Kannst Du etwas dagegen tun?
Ja, aber nur den einzigen, den *ich* bisher gefunden habe. Meine Frage (um darauf zurückzukommen) war, ob Andere vielleicht noch weitere Schwachstellen kennen / gefunden haben. Bisher scheint das nicht der Fall zu sein... Das ja schon mal ganz positiv...
wenn Du Sicherheit implemetierst, gibt es erst einmal 2 Fragen, die sich stellen. 1.) Ist mein Konzept logisch sicher? 2.) Ist es real sicher?
Ich meine nun verstanden zu haben, dass es Dir um den 2. Punkt geht. - Da solltest Du mal etwas ueber SSL lesen.
Gruss,
Lude
-
-
-
-
-
Guten Morgen csx,
ich löse den Passwortschutz ähnlich, speichere jedoch die Daten nicht in einem File, sondern in einer DB.
Du solltest auf jeden Fall darauf auchten, das dein File nicht in einem öffentlichen Bereich des Webservers liegt, sonst kann durch einfaches eingeben der URL das File gelesen werden. AUßerdem solltest Du alte Sessions löschen, um zum einen die Festplatte nicht vollzustopfen und zum anderen ist die Wahrscheinlichkeit höher, das es doppelte Sessions gibt (Was bei einer 50stelligen Session-ID jedoch wie ein 6er im Lotto ist ;-)greets
myMojito--
-------------------------------------------
Mode ist eine Variable, Stil eine Konstante-
Guten Morgen csx,
ich löse den Passwortschutz ähnlich, speichere jedoch die Daten nicht in einem File, sondern in einer DB.
Du solltest auf jeden Fall darauf auchten, das dein File nicht in einem öffentlichen Bereich des Webservers liegt, sonst kann durch einfaches eingeben der URL das File gelesen werden. AUßerdem solltest Du alte Sessions löschen, um zum einen die Festplatte nicht vollzustopfen und zum anderen ist die Wahrscheinlichkeit höher, das es doppelte Sessions gibt (Was bei einer 50stelligen Session-ID jedoch wie ein 6er im Lotto ist ;-)greets
myMojitoHi myMojito!
Das war doch mal was fundiertes zu Thema! Danke! :)
Klar, das die Datenfiles nicht im DocumentRoot drinliegen. Und klar läuft ein Cronjob, der alle paar Stunden aufräumt, etc. Nur: Es muß doch irgentwelche Angriffspunkte geben. Ich hab schon von vielen gehört, die die Authentifizierung so oder ähnlich machen. Aber das wäre doch zu einfach, oder? Irgentwelche Schwachpunkte hat das System doch mit Sicherheit (und die würd ich ganz gern schon im Vorfeld abstellen).
Gruß
csx-
Hallo csx,
Das war doch mal was fundiertes zu Thema! Danke! :)
Nichts zu Danken, gerne geschehen ;-)
Klar, das die Datenfiles nicht im DocumentRoot drinliegen. Und klar läuft ein Cronjob, der alle paar Stunden aufräumt, etc. Nur: Es muß doch irgentwelche Angriffspunkte geben. Ich hab schon von vielen gehört, die die Authentifizierung so oder ähnlich machen. Aber das wäre doch zu einfach, oder? Irgentwelche Schwachpunkte hat das System doch mit Sicherheit (und die würd ich ganz gern schon im Vorfeld abstellen).
Ich bin zwar kein Hacker, aber ich denke sie Sicherheit des Systems bestimmst in diesem Falle nur DU! Wenn Du in jedem Skript, das zu deinem geschützen Bereich gehört, die Session-ID prüfst, kann keine Zeile Programmcode ausgeführt werden, ohne gültige Session. Da deine Session-ID eine willkürliche 50stellige Buchstaben-Kollone ist, ist diese auch "Fälschungssicher". Dadurch, das Du alle alten Sessions löschst, eleminierst Du auch die Gefahr, das jemand mit einer alten Session-ID sich einloggt.
Mir fällt nur noch ein, das Du in der Session auch die IP-Adresse abspeichern solltest, und bei jedem Aufruf die aktuelle IP-Adresse mit der gespeicherten IP-Adresse überprüfst. Damit kannst Du auch diejenigen Ausschliesen, die unberechtigt in den Besitz einer gültigen Session-ID gekommen sind (Abhören des Netztwerkprotokolls oder einfach Blick über die Schulter).greets
myMojito--
-------------------------------------------
Mode ist eine Variable, Stil eine Konstante-
Hi myMojito!
Mir fällt nur noch ein, das Du in der Session auch die IP-Adresse abspeichern solltest, und bei jedem Aufruf die aktuelle IP-Adresse mit der gespeicherten IP-Adresse überprüfst. Damit kannst Du auch diejenigen Ausschliesen, die unberechtigt in den Besitz einer gültigen Session-ID gekommen sind (Abhören des Netztwerkprotokolls oder einfach Blick über die Schulter).
Hatte ich auch schon gedacht, aber wie sinnvoll ist das? Kann man die Absende-IP nicht irgentwie fälschen? Bei UDP geht das, weil da ja kein Handschake erfolgt. Aber bei TCP weis nicht, ob das möglich ist... wäre auch ie Frage, wo die IP herkommt, die in der Server-Umgebungsvariable steht...
Danke nochmal für deine Antworten! Das ist immer sehr hilfreich beim Nachdenken! :)
greets
myMojitosaludos
csx-
Hi
Hatte ich auch schon gedacht, aber wie sinnvoll ist das? Kann man die Absende-IP nicht irgentwie fälschen? Bei UDP geht das, weil da ja kein Handschake erfolgt. Aber bei TCP weis nicht, ob das möglich ist... wäre auch ie Frage, wo die IP herkommt, die in der Server-Umgebungsvariable steht...
Meines wissen findet bei TCP-IP ein Handshake statt, aber selbst wenn nicht, dann würde ja der User der versucht unrechtmäßig Daten abzurufen keine Informationen bekommen, was ihm ja nihcts nützt. So ein fälschen würde, falls es was ich nicht glaube funktionieren würde, nur Sinn wenn bei dem Aufruf des Scriptes bei einer bestimmten IP etwas getan wird.
mfg Andres Freund
-
Meines wissen findet bei TCP-IP ein Handshake statt, aber selbst wenn nicht, dann würde ja der User der versucht unrechtmäßig Daten abzurufen keine Informationen bekommen, was ihm ja nihcts nützt. So ein fälschen würde, falls es was ich nicht glaube funktionieren würde, nur Sinn wenn bei dem Aufruf des Scriptes bei einer bestimmten IP etwas getan wird.
Stimmt schon... Wenn die CGI-Umgebungsvariable die IP direkt aus den TCP-Paketen ließt, dann wäre ein fälschen nicht möglich, weil die Antwort-Pakete dann ja an die (aus Angreifersicht) falsche IP geschickt würden.
Interessant war allerding auch dein Einwand bezüglich AOL-Usern. IIRC hat ich da auch mal irgentwann was drüber gelesen (vor allem böse flames ;)
gruß
-
-
-
Hi
Mir fällt nur noch ein, das Du in der Session auch die IP-Adresse abspeichern solltest, und bei jedem Aufruf die aktuelle IP-Adresse mit der gespeicherten IP-Adresse überprüfst. Damit kannst Du auch diejenigen Ausschliesen, die unberechtigt in den Besitz einer gültigen Session-ID gekommen sind (Abhören des Netztwerkprotokolls oder einfach Blick über die Schulter).
Das würde ich nur als Option anbieten, aber nicht verpflichtend machen, da z.B. AOL-User dann ausgeschlossen wären, da diese IMHO bei jedem Aufruf eine neue IP bekommen. Diese Option könnte standartmäßig aktiviert sein, nur dass alle AOL und CO User dies ausstellen können.
mfg Andres Freund
-
-
-