Login Script

[Alexander (HH)]

Moin Moin!

»» Kurz bevor Du Dir im Astrid-Lindgren-Gedenk-Webshop 10 Paar Pippi-Langstrumpf-Socken bestellst, rät Dir ein Freund, das sleep() mal auszukommentieren, schon fällt der Angriff in sich zusammen.

Also die Socken würden mich auf jeden Fall interessieren.

*g*

Ist es nicht so, dass du mit deiner Methode ja gar nicht darauf angewiesen bist, ob ich nun schlafe oder nicht?

Doch, Dein sleep() macht mir den Angriff wesentlich leichter. Wenn ich Dir mit falschem Input komme, blockiert Dein Prozess für 5 Sekunden einen Prozess bzw. Thread. Antwortest Du dagegen sofort, ist der Prozess wieder frei und ich muß mir wesentlich mehr Mühe geben, Deinen Server zu blockieren.

Aber ich gebe dir recht, insofern, dass ich dich zu einem billigen Angriff verleite.
Nun aber die Frage nach dem geeigneten Rezept. Du machst eine Wörterbuchattacke. Ich schlafe nicht. Irgendwo gibt es auf jeden Fall einen Flaschenhals (Stichwort Filelocking)

Wozu brauchst Du Filelocking bei einem Login? OK, wenn Du auf Krampf ein RDBMS vermeiden willst und stattdessen das Rad neu erfindest, wäre ein Lock hilfreich. Weder für SELECT ... FROM users WHERE name=? AND matchPassword(pwhash,?)=true noch für INSERT INTO sessions ... brauchst Du file locking. Und mit einer persistenten DB-Connection gibt es auch kein langsames, aufwendiges Connect für jeden Login-Versuch. Ganz im Gegenteil, die notwendigen SQL-Statements können gecacht werden und sind dann rattenschnell.

Die Frage ist also welche Art von Angriff will ich abwehren. Deinen Angriff mit Zombiebots kann ich nicht abwehren. Es ist dir ja schliesslich egal, was ich für einen Output sende.

Richtig, gegen Botnets ist kaum ein Kraut gewachsen. Da haben selbst richtig große Websites gelegentlich Probleme.

Was ich tun kann ist, abfragen gegen das Loggin Formular kontrollieren.
Nun logge ich. Ich logge IPs. Du sendest mir immer eine neue IP. Du hast so ziemlich viele Testmöglichkeiten, ohne dass ich mit dem Loggen irgenwo hin komme.
Indem ich allgemein unabhängig von der IP schlafe, verhindere ich das was ich kann: Angriffe gegen das Login Formular.
Andere Angriffsmöglichkeiten kann ich nicht abwehren.

Du kannst versuchen, mir den DoS so schwer wie möglich zu machen, in dem Du möglichst schnell entscheidest, dass ein Request durch einen Angriff und nicht durch einen schusseligen Benutzer zustande gekommen ist.

Gut, ich überlege mir eine andere Variante. Den Selbstmord:
Nach so und so vielen Versuchen macht das Script via .htaccess den Laden dicht und deaktiviert sich selbst. Ich muss es dann explizit wieder starten.

Juchu! 10.000 Requests und Dein Server ist dauerhaft tot, bis Du ihn explizit wieder reanimierst. Rate mal, wie ich Dich dann in Pippi-Langstrumpf-Socken bekomme:

  
# pseudo-perl, parallel auf ein paar Maschinen  
while (!$beat->wearsLangstrumpfSocks()) {  
    if (post($login_url,{ name => random_string(), password => random_string() })!=HTTP_OK) {  
        # noch tot  
        sleep(30);  
    } else {  
        # bald tot  
        for (1..1e6) {  
            last if post($login_url,{ name => random_string(), password => random_string() })!=HTTP_OK; # schlage keinen toten Gaul ... ;-)  
        }  
        # sehr wahrscheinlich tot, spätestens nach ein paar Runden durch die while-Schleife  
    }  
}  

Das starte ich und warte ab, bis Dir der Kaffee oder die Geduld beim minütlichen Reanimieren des Servers ausgeht. Deine Kunden sehen währenddessen nahezu komplett in die Röhre, es sei denn, sie greifen während meines sleep(30) auf den frisch reanimierten Server zu.

Alexander