Ich bin kein Ruby-Experte, aber ich dachte, dass diese Codezeile die Ausführung des anfälligen Teils auf Azure verhindern würde, da sie als „false" ausgewertet wird?? Bitte korrigiert mich hier, da ich Ruby nicht kenne.
Außerdem, als eine reine Notlösung und NICHT EMPFOHLEN, da das Upgraden zu 100 % die beste Lösung ist: Könntest du die Nginx-Datei bearbeiten, um dies vorübergehend zu beheben, bis ein Upgrade durchgeführt wird?
So zum Beispiel:
SSH-Verbindung zum Server herstellen
cd /var/discourse
./launcher enter app
cd /etc/nginx/conf.d/
discourse.conf bearbeiten
Folgendes hinzufügen:
location ~* /webhooks/aws {
deny all;
}
sv restart nginx
Ich habe die feste Absicht, bald zu upgraden. Ich brauche jedoch etwa eine Woche, um die Dinge für unsere Live-Umgebung zu organisieren, und möchte in der Zwischenzeit sicher sein.
Diese Zeile wird trotzdem ausgeführt, da dieser Parameter Benutzereingabe ist.
Das könnte funktionieren, ist aber, wie du selbst sagst, nur eine Notlösung. Ein Neuaufbau würde die Korrektur entfernen, und sei beim Testen sehr vorsichtig, da die Nginx-Konfiguration sehr tricky ist, wenn man sie korrekt einrichten will.
Basierend auf den Erkenntnissen unseres Sicherheitsteams handelt es sich dabei nicht um einen Discourse-Fehler. Der Fehler liegt in unserem SNS-Nachrichtenverteilungssystem (MDS) (hier können wir nicht näher ins Detail gehen), was bedeutet, dass jedes Paket betroffen sein wird, das den SNS-Dienst nutzt oder verwendet.
Ja, das Problem wird tatsächlich durch ein Problem in der aws-sdk-sns-Bibliothek verursacht. Es ist jedoch wichtig zu verstehen, dass – da Discourse diese Bibliothek nutzt und den Fehler der Öffentlichkeit zugänglich macht – jede Discourse-Instanz anfällig ist, selbst wenn sie den AWS SNS-Dienst nicht tatsächlich nutzt.
Obwohl es sich also nicht um einen „Discourse-Fehler" handelt, ist es dennoch eine „Sicherheitslücke in Discourse".