Ergebnis 1 bis 2 von 2

Thema: Idee für zusätzliches Sicherheitsmerkmal beim Login

  1. #1
    Meister(in) Avatar von Teron Gerofied
    Registriert seit
    26.01.2008
    Ort
    serverraum
    Alter
    26
    Beiträge
    347
    Danke
    0
    Bekam 1 mal "Danke" in 1 Posting

    Standard Experimentell: Idee für zusätzliches Sicherheitsmerkmal beim Login

    Hallo,

    da ich viel mit Login-Systemen zu tun hab hab ich mir mal ein System überlegt, dass XSS absolut wirkungslos machen könnte (zumindest was das Fishen von loginrelevanten Cookies angeht):

    Grundstruktur davon sieht so aus:

    login.php
    1. Prüfen von Benutzernamen und Passwort (natürlich salted)
    2. Setze eine Session für den Benutzer wie gehabt ( mit session_set_cookie_params() Cookie auf HTTP only setzen)
    3. Speichere eine uniqid() in die Benutzertabelle, des gerade eingeloggten Benutzers
    4. Lege einen Cookie mit ebendieser Uniqid an -> HTTP only
    index.php
    1. Prüfe User-ID mittels Session
    2. Lies die Datenbank-Tabelle aus und hole Uniqid() aus Datenbank
    3. Prüfe, ob Uniqid aus Tabelle mit Cookie übereinstimmt
      1. Wenn nein: Logout -> Zerstöre alle Sessiondaten, lösche Uniqid Cookie
      2. Wenn ja: Zeige Seite im eingeloggtem Zustand (HIER KÖNNTE XSS nun stattfinden)
    Seitenende von index.php
    1. Generiere neue Uniqid() und ersetze den aktuellen Eintrag in der Tabelle
    2. Öffne eine AJAX Verbindung und lass so einen neuen Cookie mit der neuen Uniqid() (aus der Datenbank) generieren
    3. Eventuell: neue Session mit regenerate_session_id() erzeugen.
    Das war nur mal so ein provisorischer Gedankengang, wie man XSS wirkungslos machen könnte:
    Dadurch, dass für den Login auch die Uniqid() benötigt wird und diese (auch wenn man es schafft den Cookie auszulesen, während die Seite aufgebaut wird, mit XSS) am Ende der Seite wieder geändert wird, ist die Seite wirkungslos noch bevor der XSS Angreifer was mit der Uniqid() anfangen kann.

    Das Problem ist hier leider mit setcookie gegeben: setcookie darf ja nicht nach einer Ausgabe kommen und die Ausgabe mit ob_start zu puffern wäre unsinnig, weil das Cookie dann erst recht wieder den aktuellen Inhalt hat und XSS nach der Ausgabe zuschlagen kann - auch den Cookie per JS zu setzen widerspricht natürlich allen Sicherheitsanforderungen - einzige Idee wäre dies mit Ajax zu lösen - Unschön halt, dass JavaScript und Cookies für diese Methode zwingend erforderlich ist...

    Das ist nur mal so ein Gedankengang wie sowas funktionieren könnte - wenn jemand eine schönere Idee für die Cookiesache am Seitenende weiß, bitte

    Lg
    Matze
    Achtung: Dies ist ein alter Thread im HTML und Webmaster Forum
    Diese Diskussion ist älter als 90 Tage. Die darin enthaltenen Informationen sind möglicherweise nicht mehr aktuell. Erstelle bitte zu deiner Frage ein neues Thema im Forum !!!!!
    Geändert von Teron Gerofied (17.11.2011 um 16:05 Uhr)
    PHP-Code:
    if(isset($this) || !isset($this)){ // that's the question... 

  2. #2
    Meister(in)
    Themenstarter
    Avatar von Teron Gerofied
    Registriert seit
    26.01.2008
    Ort
    serverraum
    Alter
    26
    Beiträge
    347
    Danke
    0
    Bekam 1 mal "Danke" in 1 Posting

    Standard AW: Idee für zusätzliches Sicherheitsmerkmal beim Login

    Eine einfachere Variante wäre wohl auch noch:

    login.php
    1. Prüfen von Benutzernamen und Passwort (salted Password)
    2. Setze Session -> Session-Cookie: HTTP Only
    3. Speichere aktuellen Timestamp in $ts
    4. Schreibe $uid = uniqid() in Datenbank: user_session_salt
    5. Schreibe md5($ts . $uid) in Datenbank: user_session_uniqid
    6. Schreibe Cookie mit inhalt $ts (Cookie-Name: "data")
    index.php
    1. Prüfe Session und hole Benutzerdaten
    2. Prüfe ob: md5( $_COOKIE['data'] . user_session_salt ) == user_session_uniqid
      1. Wenn nein: Sessions zerstören, alles löschen
      2. Wenn ja: Dann setze neue neuen Timestamp in Cookie und generiere neue user_session_uniqid mit diesem Timestamp
        1. Zeige Seite im eingeloggten Zustand
    logout.php
    1. Zerstöre Session
    2. Lösche Salt und Code aus DB
    Ich glaub diese Routine ist sinnvoller, da das Problem mit setcookie gelöst ist und XSS trotzdem sinnlos ist, da man ohne den Salt, der nur beim Loginmechanismus generiert wird auch mit dem Cookie nicht weiter kommt, zumindest wenn der Benutzer nicht eingeloggt ist... - und wenn er eingeloggt ist wird sowieso bei jedem Seitenaufruf ein neuner TS generiert

    EDIT:
    Man könnte am Seitenende Javascript den aktuellsten TS ($ts_new) der PHP Datei übergeben, JS einen neuen Cookie setzen lassen, und am Ende der PHP Datei den Timestamp so in die Datenbank schreiben - das würde (dank der Tatsache, dass JS alles nach der Reihe abarbeitet) verhindern, dass man per XSS den neuen Timestamp auslesen kann, sofern nach dem letzten Javascript keine GET oder POST ausgegeben werden - dann hat man aber wieder das Problem, dass HTTP only im Weg steht - ist die Frage, was sicherer ist...

    EDIT 2:
    Ok, ein Timestamp wäre eig idiotisch, denn wenn man die Sessid "gehijacked" hat muss man nur mehr auf gut Glück alle Timestamps durchrennen - Uniqid würde in dem Fall auch salt ersparen
    Geändert von Teron Gerofied (17.11.2011 um 17:41 Uhr)
    PHP-Code:
    if(isset($this) || !isset($this)){ // that's the question... 

Ähnliche Themen

  1. Zusätzliches Feld auf allen Inhaltstypen (Plone3)
    Von PieAeitsch im Forum Zope & Plone - das deutsche Hilfeforum
    Antworten: 4
    Letzter Beitrag: 16.10.2009, 22:24
  2. Antworten: 7
    Letzter Beitrag: 22.10.2007, 17:53
  3. Löschen der ICQ Nummern beim Login
    Von Cindarella im Forum Computer - Internet Forum
    Antworten: 13
    Letzter Beitrag: 18.03.2007, 14:01
  4. Sicherheit beim Login
    Von MAD im Forum PHP Forum - Apache - CGI - Perl - JavaScript und Co.
    Antworten: 12
    Letzter Beitrag: 20.09.2006, 14:33
  5. Login script läuft nur bei Firefox, nicht beim IE!
    Von -nitro- im Forum HTML & CSS Forum
    Antworten: 6
    Letzter Beitrag: 24.01.2006, 09:44

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •