nikosch

Nicht nur das. Das eigentlich Problem ist Session Fixation.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

Neo68X

OK, hier mal beispielhaft das Konzept anhand der Registrierung:

Beim Aufruf der Seite wird ein Token generiert und gehasht.
Die relevanten Feldnamen sind an das Token gekoppelt und werden ebenfalls gehasht.
Ist das Token abgelaufen, wird ein neues Token generiert und die alten relevanten Feldnamen sind obsolet.
Für Spam Bots gibt es per CSS ausgeblendete Feldnamen mit Standardnamen, welche auf jeden Fall leer bleiben müssen.
Wenn irgendeiner dieser Standard Feldmanen mit Werten füllt und fas Formular absendet, geht es für den Betreffenden sofort in eine Blacklist und wird für 30 Minuten gesperrt.
Die Sicherheitsabfrage ist eine Zufällige Zahlenfolge mit einer Zufälligen Länge, welche bei jedem Aufruf neu generiert wird.
Ist die max. Anzahl der Registrierungsversuche erreicht, geht es in die Blacklist und der Betreffende wird auch wieder für 30 Minuten gesperrt.
Desweiteren gibt es einen Tick-Count der einen Request/Seconds nachhält. Wird ein gewisser Schwellenwert überschritten, geht es wieder in eine Blacklist (noch nicht implementiert) und wird anschließend irgendwohin geleitet.
Die Werte der relevanten Feldnamen werden jeweils ihrer Bestimmung mit einem dafür zugehörigen preg_match auf jeweils gültige Zeichen validiert.
Wenn irgendwas nicht stimmt, gibt es entsprechende Fehlermeldungen.
Ist ansonsten alles OK und das Token noch nicht abgelaufen, wird ein neuer Benutzer in der Datenbank angelegt und erhält eine E-Mail zwecks Bestattung der E-Mail-Adresse (noch nicht implementiert, damit man mit irgendwelchen Adressen zum Testen hantieren kann).

Config- und Krypto-Dateien liegen außerhalb von htdocs.

Soweit der Plan.

Jetzt könnt ihr es auseinandernehmen ^^ ... bin für alles offen.

Danke & Gruß
Frank

__________________
Wenn man weiß wie es geht, ist es auf einmal sau einfach ...

nikosch

Alleine diese beiden Punkte kannst Du nicht sicherstellen, weil es keine verlässliche Usererkennung gibt (außer eben Cookie/Session-ID-Parameter). Allenfalls kannst Du eine IP sperren, aber das alle Angriffe von einer IP kommen, ist halt nicht gegeben.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Neo68X

Du hast recht ... es gibt "leider keine" eineindeutige Client-Erkennung ohne Cookie/SessionID.

Deswegen: Der Sperreintrag basiert auf einen hash aus REMOTE_ADDR und HTTP_USER_AGENT. Zuerst wird der hash überprüft, um anschließend dann nur die IP zu prüfen. taucht die IP innerhalb einer Zeitspanne von 1,5 Stunden 3 mal auf, wird die IP für 12h Stunden gesperrt und wird solange diese weitere Prüfung auf nur IP als Sperreintrag in der DB vorhanden ist, sofort von der Site irgendwohin weggeheadert.

__________________
Wenn man weiß wie es geht, ist es auf einmal sau einfach ...

hts

Ja klar, das passt auch zu den restlichen Aussagen deines Posts ("Die Übergabe der SessionID ist ersteinmal Unerheblich" usw.).

Meine Fresse, so was aalglattes. Am besten wir lassen uns alle die Taschen zunähen

PHPBenutzer

@Neo68X

Wieso lässt du nicht einfach das Benutzer Konto sperren statt zu versuchen denn Hacker
irgendwie ausser Gefecht zu setzen?

Sieht dann in etwa so aus:

- 5 mal Password Falsch bei einem Benutzer -> Konto wird gesperrt.
- E-mail mit Freischalt code wird an die registrierte Adresse gesendet.
- User klickt den Code an Fehlversuche werden wieder auf 0 gesetzt.

Ist halt nur ein Vorschlag damit du vielleicht, noch zu anderen Ideen angeregt wirst und das ganze aus einer anderen Perspektive betrachtest.

Gruss
PHPBenutzer

Neo68X

... schöne Idee. Werde ich wohl auch so übernehmen.

Aber wenn jemand versucht mit einem nicht vorhandenen Benutzerkonto da irgendwie rumzukaspern, habe ich ja nur die Möglichkeit eine Kombi aus REMOTE_ADDR + HTTP_USER_AGENT zu hashen und dann zu sperren.

Ich überlege derzeit auch noch, ob ich clients mit einem leeren oder nicht gesetzten HTTP_USER_AGENT Header komplett den Zugriff zu verweigern - mit entsprechenden Hinweis wenn dies zutrifft. Ich beziehe mich da auf den "fingerprint"-Hinweis des PHP Security Guide, nur in etwas abgewandelter Form.

Gruß
Frank

__________________
Wenn man weiß wie es geht, ist es auf einmal sau einfach ...