Ich habe derzeit einen eigenen Anwendungssicherheitsdienst, der in meinem Unternehmen ausgeführt wird und den geschäftlichen Anforderungen in den meisten Fällen entspricht.
Das Problem, mit dem ich derzeit konfrontiert bin, ist, dass der Dienst traditionell (naiv) darauf vertraut hat, dass die Quell-IP des Nutzers als Absicherung gegen Session-Hijacking konstant bleibt - die Web-Anwendungen im Unternehmen sind der Öffentlichkeit nicht direkt zugänglich und waren auch nicht Die Vergangenheit ist absolut akzeptabel für mich, dass die Adresse eines Benutzers während einer Sitzung konstant bleibt.
Leider ist das nicht mehr der Fall und ich bin daher gezwungen, zu einer Lösung zu wechseln, die nicht auf die Quell-IP angewiesen ist. Ich würde viel lieber eine Lösung implementieren, die die Absicht des ursprünglichen Designers tatsächlich erfüllt (d. H. Session-Hijacking verhindert).
Meine bisherigen Recherchen haben ergeben, dass dies im Wesentlichen "Salz" bedeutet Ihr Authentifizierungs-Token-Hash mit dem SSL-Sitzungsschlüssel. "
Auf den ersten Blick scheint dies eine perfekte Lösung zu sein, doch bleibt mir der nagende Verdacht, dass die Implementierung dieses Schemas in der Praxis aufgrund der Möglichkeit, dass der Client und der Server jederzeit - effektiv und willkürlich - funktionieren können, unpraktisch ist - Wählen Sie die SSL-Sitzung erneut aus und ändern Sie den Schlüssel.Dies ist das Szenario, das ich mir vorstelle:
Ist das ein echtes Problem oder ist das ein Missverständnis meinerseits aufgrund eines (zumindest gelinde gesagt) nicht perfekten Verständnisses von SSL?
Siehe alle Themen im Zusammenhang mit SSL-Persistenz . Dies ist ein gut erforschtes Problem in der Load-Balancer-Welt.
Die kurze Antwort lautet: Sie können sich nicht auf die SSLID verlassen - die meisten Browser verhandeln neu, und Sie müssen immer noch die Quell-IP verwenden. Wenn sich die IP-Adresse wahrscheinlich während der Sitzung ändert, können Sie eine Soft-Reauthentication erzwingen oder die SSLID als Brücke zwischen den beiden IP-Änderungen verwenden (und umgekehrt, dh nehmen Sie nur Hijacking an, wenn beide IP-Adresse und SSLID ändern sich vom Server aus gesehen gleichzeitig.)
UPDATE 2014
Erzwinge einfach die Verwendung von https und stelle sicher, dass du nicht anfällig für Sitzungsfixierung oder <
Wenn der Client wahrscheinlich nur aus wenigen Systemen eine Verbindung herstellt, könnten Sie generieren ein RSA-Schlüsselpaar im Browser für möglicherweise jedes neue Client-System, von dem aus der Client eine Verbindung herstellt (wobei der öffentliche Teil an Ihren Server gesendet wird und der private Teil in dem bleibt, was hoffentlich sicher ist Client-Speicher) und umleiten zu einem virtuellen Host, der bidirektional (Peer / Client-Zertifikat) verwendet. Verifizierung anstelle der passwortbasierten Authentifizierung.
Ich frage mich, warum es nicht einfach genug wäre einfach
Ja, aber es gibt mehrere Dinge, die Sie tun können. Am einfachsten ist es, die Sitzungsschlüssel, die Sie als Salz verwenden (pro Benutzer), einfach zwischenzuspeichern und beliebige davon zu akzeptieren. Selbst wenn die Sitzung neu verhandelt wird, haben Sie sie immer noch in Ihrem Cache. Es gibt Details - Ablaufrichtlinie usw. - aber nichts ist unüberwindbar, es sei denn, Sie führen etwas aus, das milspec-gehärtet werden muss. In diesem Fall sollten Sie es nicht so machen.
- MarkusQ