Wir haben eine Webanwendung (Apache/PHP), die derzeit eine Benutzername/Passwort-Authentifizierung verwendet und derzeit von überall aus zugänglich ist. SSL ist serverseitig aktiviert.
Unser Client-Programm ist eine von uns modifizierte und umbenannte Version von FireFox. Dieser modifizierte Firefox-Client ist nur für die Verbindung mit unserem Webanwendungsserver vorgesehen. Benutzer müssen dieses Client-Programm verwenden, um eine Verbindung mit dem Webdienst herzustellen.
Zusätzlich zur Benutzerauthentifizierung möchten wir den Zugriff auf Serverebene für alle sperren, die nicht unser Clientprogramm* verwenden. Wenn ein Benutzer also eine URI in einem normalen Browser eingibt, wird ihm der Zugriff sofort verweigert.
Um dies zu erreichen, muss sich das Client-Programm gegenüber dem Server identifizieren, damit der Server weiß, dass unser Client-Programm und kein Webbrowser oder Bot verwendet wird.
*Das eigentliche Ziel besteht darin, sicherzustellen, dass es sich um autorisierte Mitarbeiter unseres Unternehmens handelt, bevor ein Anmeldeversuch unternommen werden kann. Die Einbettung dieses „Beschäftigungsnachweises“ in das Client-Programm scheint hierfür der einfachste Weg zu sein, da die Anwendung nur an Personen weitergegeben wird, die sie unbedingt verwenden müssen.
Bisher habe ich einige Ideen, wie sich dies erreichen lässt.
1.) Integrieren Sie einen Schlüssel in die Client-Anwendung, der gesendet wird, wenn sich der Client anmeldet (die Anmeldung erfolgt über eine Chrome/XUL-Schnittstelle). Dies würde nicht auf Serverebene blockieren, sondern nur auf Anwendungsebene. Der Schlüssel könnte genauso leicht gestohlen werden wie ein Passwort, aber nicht so leicht mit roher Gewalt erraten werden, da er beliebig lang oder komplex sein kann.
1a.) Fügen Sie bei allen Anfragen einen speziellen Tolken-Parameter zum Header des Client-Browsers hinzu. Dies ähnelt eher Security-through-Obscurity, könnte aber einen Angreifer, der versucht, Passwörter mit Brute Force zu erraten, deutlich verlangsamen, wenn die Anmeldung immer fehlschlägt (selbst mit dem richtigen Passwort), wenn der Magic String in der Anfrage fehlt.
2.) Betten Sie ein Client-SSL-Zertifikat in das Client-Programm ein. Dies scheint eine gute Lösung zu sein, aber es gibt so gut wie keine gute Dokumentation zu SSL auf Client-Seite. Wir möchten NICHT für jeden Benutzer ein Zertifikat signieren, noch möchten wir, dass der Benutzer ein Zertifikat erstellen oder sich mit Sicherheitsdialogen herumschlagen muss. Der private Schlüssel müsste in den Browser eingebettet werden und wäre ein Schlüssel, der von allen Client-Programmen gemeinsam genutzt und in unserem benutzerdefinierten Browser pro Installation verteilt wird.
3.) Überprüfen Sie die Benutzeragentenzeichenfolge. Ich denke, Apache kann auf dieser Grundlage einschränken. Aber es scheint bestenfalls eine schwache Maßnahme zu sein. Ich würde dies wahrscheinlich zusätzlich zu anderen Maßnahmen tun.
Ich hoffe auf eine bessere Idee, wie das geht?
Antwort1
Am einfachsten und wahrscheinlich auch sicherer wäre es, dem geänderten Browser ein Client-SSL-Zertifikat beizufügen.
Wenn Sie für alle den gleichen Schlüssel verwenden, verlieren Sie zwar viele der Vorteile von Client-Zertifikaten, aber es ist besser, als den Useragent zu überprüfen. Und ich gehe davon aus, dass Sie zum Anmelden immer noch einen Benutzernamen und ein Passwort benötigen.
Antwort2
Haben Sie über VPN nachgedacht? Das klingt genau nach dem, was Sie wirklich wollen.