Ich forsche nach Wegen, um eine Javascript-Anwendung zu sichern, an der ich arbeite. Die Anwendung ist ein Chat-Client, der APE (Ajax Push Engine) als Backend verwendet.
Gegenwärtig kann jeder auf die Seite zugreifen und eine GET / POST-Anfrage an den APE-Server richten. Ich möchte nur den Chat-Client an registrierte Benutzer liefern, und ich möchte sicherstellen, dass nur ihre Anfragen akzeptiert werden. Ich kann Benutzername / Passwort-Authentifizierung mit PHP verwenden, um einen Benutzer die Seite zu dienen. Aber sobald sie die Seite haben, was soll sie davon abhalten, das Javascript zu modifizieren oder es in die falschen Hände fallen zu lassen?
Diese Methode zum Sichern einer Client / Server-Anwendung sieht vielversprechend aus: Ссылка
Ich habe eine andere Quelle, die besagt, dass dies ideal für einen JavaScript-Client ist, da es nicht darauf ankommt, den privaten Schlüssel zu senden. Aber wie kann das sein? Gemäß dem obigen Tutorial muss der Client den privaten Schlüssel bereitstellen. Dies scheint nicht sehr sicher zu sein, da jeder, der das Javascript hat, jetzt den privaten Schlüssel dieses Benutzers hat. Von dem, was ich verstehe, würde es so etwas funktionieren:
Wie ist das sicher, wenn die JavaScript-Anwendung den privaten Schlüssel kennen muss?
Danke für die Hilfe!
Die HMAC-Authentifizierung ist besser für eine API geeignet, mit der sich Dritte verbinden können. Es scheint, dass Ihre App besser bedient werden könnte, indem Sie einen Cookie in den Browser des Clients schreiben, der anzeigt, dass sie authentifiziert wurden. Dann können Sie mit jeder Ajax-Anfrage nach dem Cookie suchen.
Edit: Ich nehme ein bisschen zurück, was ich über HMAC gesagt habe, da es besser für APIs von Drittanbietern dient. Traditionell mit HMAC erhält jeder Benutzer seinen eigenen privaten Schlüssel. Ich glaube nicht, dass dies für Ihre Bewerbung notwendig ist. Sie können wahrscheinlich damit davonkommen, nur einen privaten Master-Schlüssel zu behalten und jedem Benutzer einen eindeutigen "öffentlichen" Schlüssel zu geben (ich nenne es einen öffentlichen Schlüssel, aber in Wirklichkeit würde der Benutzer nie etwas über den Schlüssel wissen). Wenn sich ein Benutzer anmeldet, würde ich zwei Cookies schreiben. Eine ist die Kombination aus öffentlichem Schlüssel des Benutzers + verschlüsseltem Zeitstempel und einem anderen Schlüssel, der angibt, um welchen Zeitstempel es sich handelt. Dann können Sie auf der Serverseite den verschlüsselten Schlüssel validieren und überprüfen, ob der Zeitstempel innerhalb eines bestimmten Grenzwerts liegt (sagen Sie 10-30 Minuten, wenn Sie in Ihrer App im Leerlauf sitzen). Wenn sie validiert sind, aktualisieren Sie den verschlüsselten Schlüssel und den Zeitstempel, spülen Sie und wiederholen Sie.
Die Antwort: Sie können nicht verhindern, dass der Benutzer das JavaScript ändert . Machen Sie sich deswegen keine Sorgen, denn Sie können nichts dagegen tun.
Der Angriff, den Sie jedoch verhindern müssen, ist Cross-Site Request Forgery (CSRF). Schädliche Skripts auf verschiedenen Domains sind in der Lage, automatisch Formulare an Ihre Domain zu senden, wobei die Cookies vom Browser gespeichert werden. Um damit umzugehen, müssen Sie ein Authentifizierungs-Token (das ausreichend zufällig sein sollte, das nicht mit dem Benutzernamen oder dem Passwort in Zusammenhang steht und auf der HTML-Seite des Chat-Clients gesendet wird) in die von der AJAX-Anfrage gesendeten Daten einschließen ( welches nicht automatisch vom Browser ausgefüllt wird).
Wie ist das sicher, wenn die JavaScript-Anwendung den privaten Schlüssel kennen muss?
Warum nicht? Es ist der private Schlüssel des Benutzers, also wenn er bereit ist, es an jemand anderen zu geben, ist es sein Problem. Es unterscheidet sich nicht von der Vergabe Ihres Passworts und der Aussage, dass jemand anderes Zugriff auf Ihr Konto hat.
Wenn Sie ein wenig darüber nachdenken, werden Sie feststellen, dass Sie keine Public-Key-Verschlüsselung, HMAC oder Ähnliches implementieren müssen. Ihre normale sitzungsbasierte Authentifizierung reicht aus, vorausgesetzt, der Kommunikationskanal selbst ist sicher (z. B. mit HTTPS).
Tags und Links javascript php hmac ajax-push