Von Mitarbeitern generierte Einladungen umgehen die Anforderung must_approve_users

Wir hatten ein ernstes Sicherheitsproblem mit dem Einladungssystem. Ich schätze, es ist leicht reproduzierbar. Unsere Seite ist nur auf Einladung zugänglich. Außerdem haben wir in den Einstellungen „Benutzer müssen genehmigt werden“ aktiviert.

Einer unserer Mitarbeiter hat eine Einladung mit einer maximalen Nutzung von mehr als 1 ausgestellt, also nicht auf eine bestimmte E-Mail beschränkt (Beispiel unten).

Dieser Einladungslink wurde weitergegeben, und Leute konnten sich damit registrieren. Wir hatten jedoch erwartet, dass, wenn „Benutzer müssen genehmigt werden“ in den Einstellungen aktiviert ist, die Mitarbeiter jeden genehmigen müssten, der diese „nicht auf E-Mail beschränkten“ Einladungen verwendet. Stattdessen wurden alle automatisch zugelassen, wer auch immer diesen Link hatte. Der Link kann also von jedem verwendet werden, und wir können nicht überprüfen, wer sich damit anmeldet. Wir müssen in der Lage sein, eine „Hintergrundprüfung“ durchzuführen, indem wir die Kombination aus E-Mail, Name und anderen Feldern verwenden, die wir hinzugefügt haben und die obligatorisch sind, um sie zur Genehmigung anzufordern (nachdem wir sie überprüft haben).

Dies führte zu einem ernsten Problem, da jemand von einer streng verbotenen ausländischen Organisation diesen Link erhielt und sich registrierte. Ich musste dieses Konto sofort löschen. Das ist ein ernstes Schlupfloch für uns.

Daher finde ich die Option „Benutzer müssen genehmigt werden“ gefährlich irreführend. Derzeit ist diese Option bedeutungslos, wenn wir eine Instanz haben, die nur auf Einladung zugänglich ist.

Gibt es eine Möglichkeit, dass die Mitarbeiter jemanden genehmigen können, der den Einladungslink verwendet, der nicht per E-Mail eingeschränkt wurde? Das wäre ein logischer Weg, um die Option „Benutzer müssen genehmigt werden“ zu aktivieren, wenn die Seite nur auf Einladung zugänglich ist.

4 „Gefällt mir“

Ich kann das Problem reproduzieren. Wenn eine Masseneinladung generiert wird, sind die Benutzer, die sich über diesen Link anmelden, automatisch von der Einstellung „Benutzer müssen genehmigt werden“ ausgenommen.

6 „Gefällt mir“

Besteht Interesse daran, dies zu beheben? Wenn dieses Problem nicht behoben wird, wird es schließlich unser Discourse-Projekt in unserer Organisation zum Erliegen bringen.

2 „Gefällt mir“

Ich bin mir nicht sicher, ob das ein Fehler ist.

Wenn man frühere Themen zu globalen Einladungscodes und Einladungen zur Umgehung der Genehmigung liest, könnte dies durchaus beabsichtigt sein. Jemand aus dem Team müsste sich jedoch dazu äußern.

Hast du etwas in der Dokumentation gesehen, das dich zu der Annahme veranlasst hat, dass Einladungen, die nicht an eine E-Mail gebunden waren, den Genehmigungsschritt @Wall-E hinzufügten?

4 „Gefällt mir“

Der entscheidende Punkt hier ist, dass ein Mitarbeiter die Einladung ausgestellt hat. Discourse behandelt dies als implizite Genehmigung der Benutzer, die die Einladung nutzen.

Wenn ein Nicht-Mitarbeiter die Einladung generiert hat, würde der einlösende Benutzer in die Warteschlange für die Genehmigung durch das Personal aufgenommen werden.

5 „Gefällt mir“

Wenn also ein Nicht-Mitarbeiterkonto verwendet wird, um eine Einladung zu erstellen, werden die Anmeldungen über diese Einladung in die Warteschlange gestellt? Wenn das der Fall ist, ist das absolut akzeptables Verhalten und @Wall-E, Sie könnten ein Dummy-Konto eines normalen Benutzers verwenden, um die Einladung als Workaround zu generieren.

3 „Gefällt mir“

Ich denke, es sollte zumindest eine Warnung für Staff-Benutzer geben, und es wäre fantastisch, wenn sie wählen könnten, wie neue Mitglieder behandelt werden. Die Verwendung eines zweiten, „normalen“ Benutzers wäre eine hässliche Notlösung.

7 „Gefällt mir“

Beim Durchlesen dieses und der vorherigen Themen kann ich sehen, dass die aktuelle Funktionsweise “by design” ist, aber die neuen Änderungen am Einladungssystem nicht widerspiegelt. Es ist viel einfacher geworden, Einladungslinks zu erstellen, die von unbekannten Personen verwendet werden können. Einladungslinks können jetzt auch gefährlich von Mitarbeitern erstellt werden, die Einladungen zu Gruppen hinzufügen, die Zugriff auf sichere Kategorien auf der Website haben.

@Wall-E Ich bin neugierig zu verstehen, wie Ihre Einladungslinks in die Hände von Personen gelangen, denen der Zugriff auf Ihre Website nicht gestattet sein sollte. Vermutlich werden die Mitarbeiter Ihrer Website wissen, wie sie vorsichtig sein müssen, keine Einladungslinks zu erstellen, die von jedermann verwendet werden können, und sie öffentlich oder in Umgebungen teilen, in denen die falschen Personen sie verwenden können. Bis zu einem gewissen Grad ist das Problem, mit dem Sie konfrontiert sind, ein Schulungsproblem für die Mitarbeiter. Zögern Sie nicht, mir Ihre Antwort per PM zu senden, wenn sie sensible Details enthält.

Wenn derzeit Einladungslinks vorhanden sind, die irgendwie kompromittiert sind, können Sie sie löschen und neue erstellen und sie in Zukunft sorgfältiger teilen. Als Administrator können Sie auf der Einladungsseite auch immer nach dem Benutzer suchen, um zu sehen, wer seine Einladungen eingelöst hat. Wenn Sie Mitarbeiter haben, denen Sie nicht vertrauen, können Sie deren Berechtigungen auf TL4 herabstufen, was fast Moderatorberechtigungen hat.

Ich sehe drei mögliche Vorgehensweisen:

  1. Nichts tun. Das Einladungssystem funktioniert wie vorgesehen, die Mitarbeiter müssen nur vorsichtig mit ihren Einladungslinks sein. Wenn wir diesen Weg einschlagen, schlage ich vor, die Beschreibung der Admin-Einstellung must approve users zu ändern, um es kristallklar zu machen, dass von Administratoren erstellte Einladungslinks diese Einstellung umgehen.

Mitarbeiter müssen alle neuen Benutzerkonten genehmigen, bevor sie auf die Website zugreifen dürfen. Hinweis: Von Mitarbeitern erstellte Einladungen umgehen diese Einstellung und erfordern keine Genehmigung.

Pull Request für diese Änderung finden Sie hier: clarify that invites by staff bypass user approval by tobiaseigen · Pull Request #16966 · discourse/discourse · GitHub

  1. (1) tun, aber auch einen zusätzlichen “Sind Sie sicher?”-Warnschritt hinzufügen, wenn Administratoren einen Einladungslink erstellen, der sofortigen Zugriff auf die Website ermöglicht. Nur auf Websites mit erforderlicher Genehmigung.

  2. Das Verhalten ändern, sodass von Administratoren erstellte Einladungslinks die Einstellung “approval required” genauso respektieren wie Einladungen von Nicht-Administratoren.

Ich stimme dem OP zu, dass das aktuelle Verhalten irreführend ist und das Potenzial hat, Probleme auf Websites zu verursachen, wenn die Genehmigung erforderlich ist. Websites mit dieser aktivierten Einstellung sind besonders vorsichtig und benötigen dieses zusätzliche paranoide Maß an Kontrolle darüber, wer Zugriff erhalten kann.

Meine Empfehlung wäre daher, dass wir uns für Tür Nummer drei entscheiden – alle Einladungslinks auf die gleiche Weise funktionieren lassen und die Einstellung must approve users respektieren.

Ich halte dies jedoch nicht für einen Fehler. Es funktioniert wie vorgesehen. Klassifizierung als Funktionsanfrage.

5 „Gefällt mir“

Ich bin ebenfalls stark für Option 3. Ich baue eine Community auf, in der Menschen tiefer über Emotionen nachdenken können, und ich denke, dass das Hinzufügen dieser zusätzlichen Hürde für anonyme Einladungslinks (da sie nicht mit einer E-Mail-Adresse oder Identität verknüpft sind) mir ein besseres Gefühl geben könnte, dass nur die Leute beitreten, die ich möchte.

Ich könnte zwar sicherstellen, dass ich die Einladungs-E-Mail anstelle des anonymen Einladungslinks verwende, aber der Link erleichtert die Weitergabe in WhatsApp oder anderen Kommunikationsplattformen erheblich.

Daher bin ich ebenfalls dafür, dass anonyme Einladungslinks die Einstellung „Benutzer genehmigen“ respektieren.


Außerdem denke ich, wenn #3 geschieht, kann das Einladungssystem fast als Bewerbungssystem für nur per Einladung zugängliche Foren fungieren. Im Moment bin ich mir nicht sicher, wie ich Leute ohne ein separates Google Formular oder Ähnliches zur Mitgliedschaft bewerben lassen könnte. Dies könnte es auf eine Weise optimieren, bei der benutzerdefinierte Benutzerfelder das Bewerbungsformular sein könnten – was ich glaube, was @Wall-E zu tun versucht.

1 „Gefällt mir“

Darum geht es in meinem Thema nicht. Ich spreche davon, dass must_approve_users in einer nur per Einladung zugänglichen Instanz keine Wirkung hat. Das Einschalten sollte eine andere Wirkung haben als das Ausschalten. Wenn nicht, sollte dokumentiert werden, dass dieses Verhalten nicht für eine nur per Einladung zugängliche Instanz gilt. Wenn ich es in der Dokumentation übersehen habe, dann ist das in der Tat die Verantwortung unseres Personals. Aber wenn nicht, dann ist diese Funktion irreführend und sollte entweder behoben oder zumindest dokumentiert werden), da sie unser gesamtes Personal in die Irre geführt hat.

Siehe die Antwort von @david oben:

Absolut. Ich könnte es in der Dokumentation übersehen haben. Wenn es dokumentiert gewesen wäre, wäre es meine Verantwortung, mein Personal in die Irre geführt zu haben, und eine Warnung schadet nicht, denn Leute/Personal können es vergessen.

Ja, das habe ich gesehen. Zur Kenntnis genommen.

Ich werde die zuständigen Stellen zitieren, die uns aufgrund dieses Aspekts, der in unserer Organisation als Sicherheitsproblem betrachtet wird, abschalten können: „Wenn dieses System jemanden von einer nicht autorisierten Organisation zulassen kann, müssen Sie davon ausgehen, dass dies unabhängig von Ihrer Sorgfalt irgendwann geschehen wird“. Genau das ist passiert. Diese „Funktion“ (ich würde sagen, eine Nicht-Funktion, da „must_approve_user“ im Fall von nur Einladungen einfach keine Wirkung hat) wurde aktiviert, wir haben die uneingeschränkte Einladung an genau die Personen ausgestellt, die wir einladen wollten, und offensichtlich hat eine dieser Personen diesen Link zur uneingeschränkten Einladung an eine andere Organisation weitergegeben.
Damit beantworte ich auch @tobiaseigen

Wir haben Besprechungen, Konferenzen mit manchmal Hunderten von Personen aus autorisierten Organisationen, die unserem Forum beitreten dürfen. Aber einige von ihnen sind manchmal von anderen Organisationen, die nicht autorisiert sind, unserem Forum beizutreten (aufgrund übergeordneter Richtlinien, die außerhalb unserer Kontrolle liegen).
Dieser Einladungslink lief „locker“, selbst mit der Sorgfalt der Mitarbeiter, da wir nicht kontrollieren können, was die Personen mit diesem Link, die „implizit autorisiert“ sind, tun werden; per Definition ist dieser Link „uneingeschränkt“, also können sie ihn an jeden weiterleiten, den sie wollen. Ich kann meinen Mitarbeitern dafür keine Schuld geben, denn wenn Sie sagen, es sei „by design“ eine implizite Genehmigung, bedeutet das, dass dieser uneingeschränkte Einladungslink überallhin gelangen kann, also wird er es irgendwann tun. Das ist genau das, worüber unsere IT-Abteilungsleiter aus guten Gründen gesprochen haben. Wir wussten das, und deshalb haben wir „must_approve_users“ als die Sicherheitsebene aktiviert, von der wir dachten, sie sei dafür da.

Ich sehe, dass die Frage aufgeworfen wird, ob dies ein Feature oder ein Bug ist. Ich bin kein professioneller Programmierer, das müssen Sie entscheiden (ich bin Astrophysiker). Ich melde Ihnen lediglich ein ernstes „Problem“, das uns dadurch entstanden ist, in der Hoffnung, dass es behoben werden kann, damit wir diese wunderbare Plattform weiterhin nutzen können.

Ich bin voll und ganz für Option 3, ebenso wie unser Forschungszentrum und meine Forenmitarbeiter. Bis auf Weiteres ist es den Mitarbeitern untersagt, die uneingeschränkte Einladung zu verwenden. Dies bedeutet zusätzlichen Aufwand, da sie nun alle einzelnen E-Mail-Adressen der Personen hinzufügen müssen, die sie einladen möchten (und auf einer Konferenz sind das mehr als Hunderte von Teilnehmern…). Dies bei jeder Besprechung, Veranstaltung usw. zu tun, wird unser Wachstum stark behindern, und ich kann mir vorstellen, dass einige Mitarbeiter aufgrund der zusätzlichen Arbeitsbelastung gehen werden (die meisten von ihnen sind Freiwillige und alle mit ihren anderen Aufgaben überlastet).

2 „Gefällt mir“

Ist es sicher anzunehmen, dass es eine Option geben wird, das bestehende Verhalten beizubehalten, wenn Option 3 umgesetzt wird?

Die Trainingsseite, die wir zusammengestellt haben, wäre ohne die Möglichkeit, Genehmigungen für die in Massen eingeladenen Gruppen zu umgehen, weitaus schwieriger umzusetzen gewesen.

1 „Gefällt mir“

Vergessen Sie nicht, dass Masseneinladungen hier ebenfalls eine Option sind. Wenn Ihre Veranstaltung eine CSV-Datei mit Teilnehmern generiert, können Sie diese verwenden, um alle direkt einzuladen.

Wenn nicht, können Sie auch eine URL zu einem Webformular teilen, um eine CSV-Datei zu erstellen und Benutzer dort zu validieren, bevor Sie die Masseneinladung senden.

Leider bieten unsere typischen Veranstaltungen keinen Zugriff darauf. Diese Kontaktlisten werden von der gastgebenden Organisation, die die Konferenz/das Meeting veranstaltet, als PII (Personally Identifiable Information) behandelt. Selbst wenn wir Zugriff hätten, fehlt uns einfach die Bandbreite, um diese Funktion zu nutzen. Wir müssten uns mit einem Ansprechpartner in Verbindung setzen, der immer überarbeitet ist (selbst wenn wir Zugriff auf die Informationen erhalten dürfen), also wieder eine hohe Viskosität. Bis wir die Einladungslinks erhalten, ist die Veranstaltung vorbei, die Dynamik ist verloren (bei unseren Mitarbeitern und bei unseren potenziellen Eingeladenen).

1 „Gefällt mir“

Zur Kenntnis genommen. Das könnte eine Übergangslösung sein. Aber das bedeutet zusätzliche Arbeit für unsere Mitarbeiter, die nicht viel Bandbreite für die Bearbeitung dieses zusätzlichen Schritts haben. Das ist also nicht ideal.

1 „Gefällt mir“

Es tut mir leid, dass dies Probleme für Sie und Ihre Community verursacht hat!

Zukünftig wissen Sie nun, wie es funktioniert, und können sicher sein, dass Sie und Ihre Mit-Admins und Moderatoren das Einladungssystem mit Bedacht nutzen werden!

Die Frage nach Funktion vs. Fehler betrifft die Priorisierung – wir versuchen, Fehler schnell zu beheben, insbesondere wenn es sich um Sicherheitsfehler handelt! Aber in diesem Fall ist die Funktionalität dieselbe wie seit Jahren und sie ist so gewollt. Ich denke, wir sollten es ändern, aber es ist keine Sache, bei der man alles stehen und liegen lassen muss, um es sofort zu beheben.

Wir werden dem noch etwas Zeit geben, damit andere ihre Meinung äußern können, damit wir entscheiden können, in welche Richtung wir gehen möchten.

2 „Gefällt mir“

Dies könnte eine weitaus komplexere Änderung sein, abhängig davon, wie der Guardian in die verschiedenen Elemente dieses Prozesses einbezogen wird, aber eine weitere Option, die ebenfalls von 3 abhängt, ist:

  1. Füge den Einladungen selbst eine boolesche Eigenschaft hinzu, um die Benutzergenehmigung zu umgehen. Diese Eigenschaft wäre standardmäßig deaktiviert und nur in der Benutzeroberfläche zum Erstellen von Einladungen verfügbar, wenn must_approve_users aktiviert ist.

Bearbeiten: Wenn ich mir den Code, auf den David verwiesen hat, noch einmal ansehe, glaube ich nicht, dass der Guardian überhaupt daran beteiligt ist, zu entscheiden, ob ein eingeladener Benutzer genehmigt werden muss. Es scheint, dass dieser Teil eine einfache Ersetzung von invite.invited_by.staff? durch etwas wie invite.bypass_approval? wäre.

1 „Gefällt mir“

Ich verstehe Ihre Priorisierungsbeschränkungen vollkommen. Ich schätze, unsere Instanz befindet sich in einer ungewöhnlichen Situation, da alle Discourse-Instanzen, die ich kenne, von Organisationen stammen, die nicht die strengen Sicherheitsrichtlinien haben, an die wir uns halten müssen. Zum Beispiel war die Einladung-nur-Funktion eine Einschränkung, die uns von unserer Organisation auferlegt wurde, unsere Instanz könnte nicht mit Selbstregistrierung existieren. Mit einer Selbstregistrierung wäre es einfacher, wir müssten die uneingeschränkten Einladungen nicht verwenden, die “locker” werden können.

2 „Gefällt mir“