Ich habe mich mit logischer Sicherheit basierend auf Informationen zum aktuellen Benutzer beschäftigt, z. B. „wenn topic.creator.username gleich User.current().username ist“, erlaube ich dem Benutzer, das Thema zu bearbeiten oder auszuschließen.
Der Punkt ist: Ich muss bestimmte Aktionen basierend auf der Benutzersitzung garantieren! Aber ich habe einige Tests durchgeführt, und deshalb bin ich jetzt hier und frage euch.
Über JavaScript im Webbrowser (auch im Produktionsmodus) kann ich Discourse.User.current().set(‘username’, ‘sometestename’) ausführen. Auf diese Weise würden einige Aktionen in meinem System nur durch diese Änderung aktiviert. Ich weiß, dass das nicht das Ziel von 99 % der Benutzer ist, aber abgesehen von diesem Fall: Wisst ihr, wie man sicherstellen kann, dass Benutzer keine Benutzerinformationen manipulieren können?
Wenn du Informationen in deinem lokalen Browser änderst, hat das keine Auswirkungen auf das Backend.
Der Benutzer ist vermutlich über ein Authentifizierungstoken angemeldet, sodass du dich gegenüber dem Backend nicht als eine andere Person ausgeben kannst:
Da der Server nicht getäuscht werden kann, kannst du keine Änderungen als anderer Benutzer vornehmen.
Sobald du den Browser neu lädst, werden deine lokalen Änderungen wahrscheinlich verworfen. Im schlimmsten Fall bringst du den JavaScript-Anwendungszustand durcheinander und musst deinen Cache löschen.
Wie du sagtest, wäre der beste Weg, die aktuelle Benutzersitzung immer vom Back-End-Server zu beziehen.
Auf diese Weise können Cache-Änderungen aus dem Browser nichts ausrichten! Weißt du, wo ich nachschauen kann, dass die logische Sicherheit auf der Benutzersitzung vom Back-End-Server und nicht vom PreloadStore basiert?
Gib mir bitte Bescheid, wenn ich auf dem falschen Weg bin! Danke für die Hilfe, Robert!
Ich bin kein Sicherheitsexperte, sondern nur ein App-Entwickler, aber alle dauerhaften Änderungen können ausschließlich auf dem Server vorgenommen werden. Was im Browser in EmberJS passiert, dient der Benutzerfreundlichkeit und einem besseren Nutzungserlebnis, z. B. durch Caching für Geschwindigkeit oder automatische, app-ähnliche Interface-Verhalten. Das ändert nichts daran, dass letztendlich alle dauerhaften Änderungen mit dem Rails-Server abgestimmt werden müssen, und dabei hat man nur die Berechtigung, dies im Namen des angemeldeten Benutzers zu tun.
Gleiches gilt für den Abruf aller Daten – der Rails-Server wird nur Daten an den angemeldeten Benutzer senden, die ihm zugänglich sind.
Ich glaube nicht, dass du dir darüber Sorgen machen musst, denn wenn jemand versuchen würde, dies zu umgehen, würde er bereits am ersten Hindernis scheitern: Es gibt keine Möglichkeit, die API zu täuschen.
Ich mache mir Sorgen, da ich an einigen Ansätzen arbeite, bei denen eine solche Aktion je nach Benutzer verfügbar sein wird oder nicht – je nachdem, ob Sie der Themenersteller oder der Beitragsersteller sind. Daher muss ich dies basierend auf der Backend-Benutzersitzung validieren.
So kann der Benutzer beispielsweise einen Beitrag bearbeiten, wenn er der Beitragsersteller ist.
EDIT: Wie bei den Berechtigungen für Beiträge in Discourse werde ich dies überprüfen.
Ich habe den Plugin-Code und die Codebase rund um Post-Steuerung (Aktionen) analysiert, um herauszufinden, wo ich mich am besten für die Sicherheit einsetzen kann.
Wie analysiert: Auf der Frontend-Seite gibt es mehrere Schritte, die sicherstellen, ob ein Benutzer einen Beitrag bearbeiten darf oder nicht, wie:
