login
-
:p
-
RandomAccess85 schrieb:
@Shade Of Mine
Ich bitte dich! Wir sind Programmierer und nicht das FBI! Es hat alles seine Vor- und Nachteile und überall gibts Sicherheitslücken oder Risiken.Es ist OK wenn du das privat so machen willst.
Aber fuer relevante Webauftritte finde ich sowas halt schon riskant. Jedenfalls wuensche ich mir dass die Leute es hier gleich richtig lernen.Session Management selber machen ist ja auch vollkommen OK. Aber dann machs richtig. Lies zB mal: http://seclists.org/vuln-dev/2001/Jul/33
Session IDs generieren ist kein trivialer Task. Natuerlich kann man es auch selber machen, aber es gibt eine Menge Sachen zu bedenken.srand mit der aktuellen Zeit zu initialisieren ist hier zB keine gute Idee. Schau mal wie PHP das macht: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/session/session.c?view=markup -> php_session_create_id
-
Hallo,
du erzählst mir immer das es keine gute Idee ist, oder falsch es so zu machen und lieferst Beispiele wie ich es anders machen könnte. Warum, sagst du mir aber nicht. Gib mir doch die Möglichkeit zu verstehen, wieso du meine Variante nicht gut findest und welche Möglichkeiten der normale Webuser hat diese zu umgehen, bzw Mist damit zu machen.
Ich betone nochmal: Ich mache den Nutzer damit lediglich eindeutig, damit ich ihn später wieder identifizieren kann!
ICH NUTZE IMMERNOCH KEINE SESSIONS
VlG
-
find die php sessions eig. gut ^^
(mal so von hinten einwerf) :schland:
-
Es gibt viele Möglichkeiten, einen User eindeutig (und sicher) zu identifizieren. Session und Cookies gehören m. E.* zu den schlechtesten ...
* Abk.** für meines Erachtens
** Abkürzung für Abkürzung
-
schmidt-webdesign.net schrieb:
Es gibt viele Möglichkeiten, einen User eindeutig (und sicher) zu identifizieren. Session und Cookies gehören m. E.* zu den schlechtesten ...
Und woran erkennst du einen User?
Sessions, auf die eine oder andere Art sind notwendig.
@RandomAccess85:
Was genau ist dir unklar? Stell eine Frage, ich erklär es dir gerne.
Ich habe zB gezeigt dass deine Session ID den User nicht eindeutig identifiziert.
Und damit habe ich bewiesen dass dein Session Management fehlerhaft ist.
-
Hallo,
Allein schon die Benutzernamen sind eindeutig?! Alles andere ist reine Vorsicht, weil der Benutzername von allem am schnellsten rausgefunden ist :p
Mir ist nichts unklar, ich komm mit meiner - wie du es nennst - Sessionverwaltung ganz gut klar. Du bist derjenige der meint sie wäre unsicher und falsch.
VlG
-
RandomAccess85 schrieb:
Allein schon die Benutzernamen sind eindeutig?! Alles andere ist reine Vorsicht, weil der Benutzername von allem am schnellsten rausgefunden ist :p
Ich weiss garnicht was man da noch groß sagen soll...
Bitte lies dich in die entsprechenden Security Themen ein. Eindeutige ID bringt nichts wenn sie trivial erratbar ist. Denn wenn ich die Session ID des Admins erraten kann, dann kann ich sie übernehmen:
Session Fixation, Session Riding, Session Hijacking,...
Bitte bitte bitte lies dich da mal rein.
PS:
mir ist klar dass ich auf verlorenem Posten stehe. Man muss sich nur einmal durch die Security Maillists durchlesen um zu sehen dass Sicherheit im Web einfach nicht existent ist. Aber n bisschen träumen darf man ja wohl...
-
Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO
:schland:
-
PRIEST schrieb:
Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO
Der Punkt ist leicht:
Security Management sollte man bestehenden, erprobten, wenn möglich Open Source basierten Lösungen überlassen und nicht selber machen.Das ist wie Verschlüsselung. Da nimmt man ja auch fertige Systeme und baut nicht seinen eigenen Algorithmus.
-
ich hab jetzt nochmal nachgesehen, wie ich das mache...
session_start wird bei jedem Seitenaufruf aufgerufen (also existiert definitiv immer eine session_id.
Beim Login wird diese mit übergeben. Damit die nicht verändert wird, wird diese zur Sicherheit nochmal mit der "echten" session_id abgeglichen (fragt mich nicht, warum ich sie dann übergebe. Ich werd aber irgendeinen Grund gehabt haben :p)
Danach enthält die Session auch den Benutzernamen und das Passwort des angemeldeten Benutzers. Außerdem wird die sid in der Datenbank gespeichert (in der Tabelle, in der alle aktuell angemeldeten Benutzer gelistet sind, inkl. IP und Useragent)Beim Logout dann das übliche prozedere: session_destroy, session_start, session_regenerate_id
Hab ich da denkfehler drin? Es ist ein paar Jahre her, dass ich diesen Teil meines Projekts geschrieben hab und steigt derzeit noch nicht ganz durch. Bei Bedarf kann ich auch Code geben. Ich will nur sicher sein, dass hier kein Schlupfloch existiert (obwohl ich erstaunt bin, an was ich das alles gedacht hab oO)
-
Shade Of Mine schrieb:
PRIEST schrieb:
Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO
Der Punkt ist leicht:
Security Management sollte man bestehenden, erprobten, wenn möglich Open Source basierten Lösungen überlassen und nicht selber machen.Das ist wie Verschlüsselung. Da nimmt man ja auch fertige Systeme und baut nicht seinen eigenen Algorithmus.
Wen dies der Punkt ist geb ich dir Recht. :schland:
-
Hallo,
ich bin kein Freund vom "mit Kanonen auf Spatzen schießen". Ich will eine einigermaßen sichere Website und nicht das Pentagon nachbauen.
Wieso soll ich mich schlau lesen wenn du es alles weißt? Du wirfst mit Begriffen um dich, hälst es aber nicht für nötig, diese auch mal zu erläutern, oder mit meinem Beispiel zu verbinden...
Btw.: Nun hab ich mich doch schlau gelesen und festgestellt, dass ich nicht mehr weiß als ich vorher auch schon wusste.
Alle 3 Dinge kommen in etwas folgendem Szenario gleich:
Mein bester Freund ruft mich an und fragt - nur so aus Neugier - nach meinem Benutzernamen und meinem Passwort. Ich bin natürlich so blauäugig und gebe ihm die gewünschten Informationen. Nachdem ich festgestellt hab, dass diese Aktion mächtig unklug war, geh ich zu meinem Dienstanbieter und mecker ihn an, wieso er das Problem nicht erkannt hat und schnell mein Kennwort änderte....VlG
-
RandomAccess85 schrieb:
Btw.: Nun hab ich mich doch schlau gelesen und festgestellt, dass ich nicht mehr weiß als ich vorher auch schon wusste.
Alle 3 Dinge kommen in etwas folgendem Szenario gleich:
Mein bester Freund ruft mich an und fragt - nur so aus Neugier - nach meinem Benutzernamen und meinem Passwort. Ich bin natürlich so blauäugig und gebe ihm die gewünschten Informationen. Nachdem ich festgestellt hab, dass diese Aktion mächtig unklug war, geh ich zu meinem Dienstanbieter und mecker ihn an, wieso er das Problem nicht erkannt hat und schnell mein Kennwort änderte....Nein, falsch. Komplett.
Folgendes Szenario: du bist Admin deiner Seite. zB gibt es dort eine Online Anzeige die anzeigt welcher User online ist. Ich sehe dass du jetzt gerade Online gekommen bist. Nun versuche ich deine Session ID zu erraten. Da dein Algorithmus zum Erzeugen der Session ID sehr schwach ist, kann ich recht schnell deine Session ID erraten und übernehme deine Session. Ich komm damit direkt in den Admin Bereich und gebe meinem User Adminrechte und habe deine Seite gehackt.
Das ist recht trivial zu machen.
Also vielleicht doch mal in das Thema einlesen? Das sind wirklich nur die Grundlagen. Es gibt viel mehr Angriffe als ich überhaupt kenne...
@zwutz:
Soweit ich das sehe fährst du dann lediglich zweigleisig. Du hast keine eigenen Sicherheitslücken erschaffen aber auch nicht wirklich einen Vorteil von deinem System. Wenn du die Session mit session_start startest und mit session_destroy löscht, und dazwischen zusätzlich Daten in $_SESSION und in einer DB speicherst, dann ist das kein Sicherheitsproblem. Sofern du die Garbage Collection korrekt machst (du musst die Session ID ja aus der Datenbank und aus dem PHP System etwa gleichzeitig löschen oder für ungültig markieren).
-
Shade Of Mine schrieb:
@zwutz:
Soweit ich das sehe fährst du dann lediglich zweigleisig. Du hast keine eigenen Sicherheitslücken erschaffen aber auch nicht wirklich einen Vorteil von deinem System. Wenn du die Session mit session_start startest und mit session_destroy löscht, und dazwischen zusätzlich Daten in $_SESSION und in einer DB speicherst, dann ist das kein Sicherheitsproblem. Sofern du die Garbage Collection korrekt machst (du musst die Session ID ja aus der Datenbank und aus dem PHP System etwa gleichzeitig löschen oder für ungültig markieren).Die Session-ID in der Datenbank hat rein statistische Gründe und wird zu keinem Zeitpunkt für sicherheitsrelevante Tätigkeiten genutzt.
Naja... bei Gelegenheit seh ich nochmal drüber. Das ist teilweise vor fünf oder sechs Jahren entstanden ^^
Wie sollte man es denn idealerweise machen?
-
Shade Of Mine schrieb:
Folgendes Szenario: du bist Admin deiner Seite. zB gibt es dort eine Online Anzeige die anzeigt welcher User online ist. Ich sehe dass du jetzt gerade Online gekommen bist. Nun versuche ich deine Session ID zu erraten. Da dein Algorithmus zum Erzeugen der Session ID sehr schwach ist, kann ich recht schnell deine Session ID erraten und übernehme deine Session. Ich komm damit direkt in den Admin Bereich und gebe meinem User Adminrechte und habe deine Seite gehackt.
Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.
Nebenbei:
"In Deutschland ist die rechtswidrige Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB) ebenso wie das Ausspähen von Daten, die gegen unberechtigten Zugang besonders gesichert sind, (§ 202a StGB) eine Straftat."
Quelle Wikipedia
-
RandomAccess85 schrieb:
Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.
hm.. um 10:45:50 warst du noch nicht online, dafür aber um 10:45:55.
Macht insgesamt mit deinem System nur 5 Mio. session-ids, die man durchtesten muss, eine davon gehört dir. Je nach Auflösung der microtime wohl eher deutlich weniger
-
RandomAccess85 schrieb:
Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.
Nope.
Auf diese Art und weise werden die meisten Algorithmen geknackt. Zumal du nichts gegen Bruteforce von Session IDs machen kannst, gegen Bruteforce von Passwörtern aber schon.
Aber ja, das ist die Standard Antwort auf Sicherheitsbedenken...
Dabei sind diese Sachen so trivial. Es ist wirklich Deppensicher. Es ist genauso wie ich nie verstehen werde warum es Buffer Overflows, SQL Injections, etc. gibt. Es ist trivial zu lösen.Aber Arroganz hilft hier halt nicht weiter. Klar für die kleine private Homepage ist es egal - aber stell dir mal vor diesen Fehler gäbe es auf Seiten wie facebook. Oder auch zB hier. Du könntest ohne Probleme das ganze Forum löschen...
Du denkst dir vielleicht die genaue Uhrzeit ist schwer zu erraten, aber der PHP RNG ist bekannt ich brauche nur den Seed und schon habe ich die Session ID. Aber wieviele mögliche Seeds gibt es? Ich kann die Auflösung des Timers ja recht leicht herausbekommen da ich ja jederzeit selber eine Session ID generieren lassen kann und der Server sagt mir seine Zeit auf auch die Sekunde genau. Es ist wirklich kein Aufwand sowas zu knacken.
Wenn ich die Auflösung kenne, die wird so etwas 40ms sein, dann sind das nur noch ~25 Seeds pro Sekunde. Wenn ich dein Login auf 5 Minuten genau bestimmen kann sind das 7500 mögliche Session IDs.
Nur so damit du eine ungefähre Vorstellung hast wieviel einfacher das ist als dein Passwort zu erraten.
"In Deutschland ist die rechtswidrige Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB) ebenso wie das Ausspähen von Daten, die gegen unberechtigten Zugang besonders gesichert sind, (§ 202a StGB) eine Straftat."
Quelle WikipediaOh, es ist illegal die Seite zu hacken?
Das hilft sicher.
-
Hallo,
ich hab das Problem schon verstanden, finde es aber trotzdem absolut überflüssig weiter darauf einzugehen. Ihr könnt mir das nun super stolz vorrechnen -> aber auch nur weil ich euch das System verraten hab. Ich brauch keine 2 Minuten, dann ist es geändert und dann funktioniert es nicht mehr so einfach.
Man muss nicht klug spielen, wenn man mit Fakten umsich wirft, die sowieso jeder kennt. Nebenbei bemerkt kann ich euch meine ID auch direkt verraten, bringen wird sie euch nix :)!
VlG
-
RandomAccess85 schrieb:
Nebenbei bemerkt kann ich euch meine ID auch direkt verraten, bringen wird sie euch nix :)!
Nach welchem Kriterium sperrst du?
Auf IP und HTTP Header Basis zu sperren ist eine schlechte Idee.PS:
Du musst immer annehmen dass das System bekannt ist. Deins ist sogar trivial erkennbar. Ich generie 2 Sesison IDs pro 1ms und habe dein System erkannt - weil gleiche Session ID zurück kommt.Dir geht es nur ums Prinzip, oder?
