XSRF token (gelöst) (Perl/CGI)

[thread]21562[/thread]

XSRF token [gelöst]

Tags: perl5 CGI session XSRF Ähnliche Threads

Leser: 9

Articles: hide open all | hide show old branches

+15 replies
GwenDragon

2024-05-09 14:33
User since
2005-01-17
14890 Artikel
Admin1
Ich verwende seit langen in CGI-Sessions ein Extra-Token, das auch in den Sessiondaten ((hier CGI::Session mit DSN file) gespeichert wird.
Die Session-ID ist im Cookie. Das Token wird nicht im Cookie geführt, sondern als HTML-Input mit Attribut hidden in Formularen.
Alles wird über SSL geführt.

Ich generiere das Token so:
Code (perl): (dl )

1 2 3 4 5

sub generate_Token { my $tok = sha1_hex( time * 2, __PACKAGE__, rand, $ENV{HTTP_USER_AGENT} // '', time, $ENV{REMOTE_IP} // '', time ); return $tok; }
Der Tread nur so als Anregung, auch für Andere, so wie ich es mache klappt es ja.

Frage in die Runde wie ihr es für sinnvoll erachtet.

Wie Token erzeugen?
- Randomwert als MD5
- Randomwert als SHA1, so wie ich oben
- HMAC-Hash, aber da müsste ich ein Secret im Programm speichern
- Oder anders?

Gern auch Beispiele posten.
Last edited: 2024-05-09 14:48:33 +0200 (CEST)
die Drachin Gwen

Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
- +10 replies
- barney
  
  2024-05-09 19:36
  
  User since
  2008-08-31
  227 Artikel
  BenutzerIn
  
  Mein Stand ist dass diese Challenge Tokens nur die Anforderung haben, dass sie nicht erraten werden können. In OTOBO wird dazu Kernel::System::irand mehrfach aufgerufen. Siehe
  GenerateRandomString. Ob das so sinnvoll kann ich nicht beurteilen.
  - GwenDragon
    
    2024-05-10 10:50
    
    User since
    2005-01-17
    14890 Artikel
    Admin1
    
    2024-05-09T17:36:54 barney
    Mein Stand ist dass diese Challenge Tokens nur die Anforderung haben, dass sie nicht erraten werden können.
    Ich sehe das auch so.
    die Drachin Gwen
    
    Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - +8 replies
  - rosti
    
    2024-05-10 12:57
    
    User since
    2011-03-19
    3751 Artikel
    BenutzerIn
    
    Quote
    Mein Stand ist dass diese Challenge Tokens nur die Anforderung haben, dass sie nicht erraten werden können.
    
    Wie ein Passwort. Idee: Als Token gleich das Passwort nehmen. Natürlich als Crypt und genauso auch serverseitig hinterlegt. Und schon wird die Session überflüssig weil das passwort bei jedem Request geprüft werden kann ;)
    
    Mfg
    https://www.rolfrost.de/
    
    Forum zu Fragen unserer Zeit
    - +7 replies
    - GwenDragon
      
      2024-05-10 14:26
      
      User since
      2005-01-17
      14890 Artikel
      Admin1
      
      Ja, das ginge auch. Aber wenn mehr Daten speichern muss wie Loginzeitpunkt, ist eine Session nötig.
      die Drachin Gwen
      
      Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
      - +6 replies
      - rosti
        
        2024-05-10 14:38
        
        User since
        2011-03-19
        3751 Artikel
        BenutzerIn
        
        2024-05-10T12:26:05 GwenDragon
        Ja, das ginge auch. Aber wenn mehr Daten speichern muss wie Loginzeitpunkt, ist eine Session nötig.
        
        Nein.
        https://www.rolfrost.de/
        
        Forum zu Fragen unserer Zeit
        
        +5 replies
        
        GwenDragon
        
        2024-05-10 14:45
        
        User since
        2005-01-17
        14890 Artikel
        Admin1
        
        Echt, du willst das Alles im Request mit zu schleppen ist? Es geht doch oft auch um Persistenz bei Sessions.
        Oder wie meinst du das?
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        +4 replies
        
        rosti
        
        2024-05-10 14:51
        
        User since
        2011-03-19
        3751 Artikel
        BenutzerIn
        
        2024-05-10T12:45:29 GwenDragon
        Echt, du willst das Alles im Request mit zu schleppen ist? Es geht doch oft auch um Persistenz bei Sessions.
        Oder wie meinst du das?
        
        Daten kann man auch im Benutzerprofil speichern. Also serverseitig und dafür braucht man kein Session.
        
        MfG
        https://www.rolfrost.de/
        
        Forum zu Fragen unserer Zeit
        
        +3 replies
        
        GwenDragon
        
        2024-05-10 16:48
        
        User since
        2005-01-17
        14890 Artikel
        Admin1
        
        Dann habe ich deine Antwort falsch aufgefasst was alles in den Request sollte.
        OK.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        +2 replies
        
        rosti
        
        2024-05-10 19:02
        
        User since
        2011-03-19
        3751 Artikel
        BenutzerIn
        
        Ich werde mal ein Beispiel entwickeln. D.h., daß es schon eine HTTP-Session gibt nur mit dem Unterschied zum bisherigen Sessionverständnis, daß es keine zufällig erzeugte Session-ID gibt sondern anstelle dessen die Benutzerkennung als Crypt von Benutzername und Passwort. Infolgedessen wird nach einem erfolgreichen Login nicht etwa eine Session-ID gesendet sondern Benutzername+Passwort bei jedem Request und zwar so daß der Benutzer davon praktisch gar nichts mitbekommt.
        
        Es ist unerheblich ob man dieses Geschnatter über einen Cookie abwickelt oder über versteckte Formularfelder. Wobei die Cookievariante den Vorteil bietet, daß die Credentials auch bei einem GET-Request mitkommen.
        
        Serverseitig wird also nicht etwa geprüft ob die Session gültig ist, sondern ob zum Benutzername ein gültiges Passwort geliefert wird. Quasi wie beim Login.
        
        Für anonyme Warenkörbe ist sowas freilich nicht geeignet.
        
        Mfg
        https://www.rolfrost.de/
        
        Forum zu Fragen unserer Zeit
        
        rosti
        
        2024-05-10 22:28
        
        User since
        2011-03-19
        3751 Artikel
        BenutzerIn
        
        Demo: http://rolfrost.de/konto.html
        
        mfg
        
        PS: Mit Erläuterung und Perlcode.
        
        Diese Anwendung löst das Cross-Site-Request-Forgery-Problem!
        Und das Problem mit Session-Zombies.
        Und das Problem mit abgelaufenen Sessions.
        Last edited: 2024-05-11 11:06:23 +0200 (CEST)
        https://www.rolfrost.de/
        
        Forum zu Fragen unserer Zeit
- +4 replies
- rosti
  
  2024-05-10 07:49
  
  User since
  2011-03-19
  3751 Artikel
  BenutzerIn
  
  Benutzername+Passwort kannste auch hashen. Falls vorhanden. MfG
  Last edited: 2024-05-10 08:53:09 +0200 (CEST)
  https://www.rolfrost.de/
  
  Forum zu Fragen unserer Zeit
  - +3 replies
  - GwenDragon
    
    2024-05-10 10:48
    
    User since
    2005-01-17
    14890 Artikel
    Admin1
    
    Ja, ich wende für sowas gern intern in Konfiguration oder Datenbank Crypt::SaltedHash an.
    
    Aber selbst gehasht, wäre mir eine Kombi Username+Password=Hash nicht so lieb zum Übertragen per Formular/AJAX. Denn der Häsh lässt sich stehlen und knacken mit GPUs.
    Da ist mir Session-ID + Token lieber, weil es keinen Rückschluss zulässt.
    Last edited: 2024-05-10 10:56:44 +0200 (CEST)
    die Drachin Gwen
    
    Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
    - +2 replies
    - rosti
      
      2024-05-10 12:44
      
      User since
      2011-03-19
      3751 Artikel
      BenutzerIn
      
      Quote
      Denn der Häsh lässt sich stehlen und knacken mit GPUs.
      
      So? Ich denke Du überträgst mit SSL? Also, wenn Du die Benutzerdaten ohnehin bei jedem Request überträgst (Passwort als Hash), dann brauchst Du auch keine Session. Anfallende Daten können dann im Benutzerkonto gespeichert werden. Nurmalso als Tipp ;)
      
      mfg
      https://www.rolfrost.de/
      
      Forum zu Fragen unserer Zeit
      - GwenDragon
        
        2024-05-10 16:53
        
        User since
        2005-01-17
        14890 Artikel
        Admin1
        
        Solange noch kein Rechnerverbund die harten SSL-Chiffren aufknacken können mit wenig Zeitaufwand, ist der Traffic sicher.
        TLSv1.3, 256 bits, TLS_AES_256_GCM_SHA384, Curve 25519 DHE 253 ist schon ganz robust. ;-)
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten

View all threads created 2024-05-09 14:33.