Diese Seite beschreibt das Sicherheitsmodell von WebBlocks CMS und die Schritte eines Bedieners oder die Agentur sollte dafür sorgen, dass es für Kundenstandorte sicher ausgeführt wird. Informationen zum Melden von a Sicherheitslücke finden Sie unter SECURITY.md – bitte nicht öffentlich zugänglich machen Probleme für Sicherheitsberichte.

Dies sind die wichtigsten Kontrollen für eine Produktionsinstallation:

• Verwenden Sie nur public/ als Web-Root. Das Anwendungs-Root enthält .env, .git, .github, storage/, vendor/ und Quellcode, der erforderlich ist niemals über das Internet erreichbar sein. Richten Sie Ihr Nginx/Apache-Dokumentstammverzeichnis auf public/ und bestätigen Sie, dass https://your-site/.git/config und https://your-site/.env geben beide 404 zurück. Ein offengelegtes .git-Verzeichnis leckt Ihre gesamte Quelle und alle vertraulichen Geheimnisse.
• Bevorzugen Sie ein Release-Artefakt gegenüber einem rohen Git-Klon in der Produktion. Release Pakete schließen .git, .github, project/ und andere Nicht-Laufzeitdateien aus (siehe .gitattributes export-ignore Regeln). Wenn Sie einen Klon bereitstellen, deaktivieren Sie ihn Drücken Sie auf die Installation (git remote set-url --push origin DISABLED).
• Set APP_DEBUG=false und ein starkes APP_KEY in Produktion. Debug-Modus Lecks Stack-Traces, Umgebungswerte und interne Pfade.
• Verwenden Sie HTTPS und legen Sie SESSION_SECURE_COOKIE=true fest, wenn Sie über TLS bereitstellen.
• Dateiberechtigungen: Der Web-/PHP-Benutzer benötigt Lese-/Schreibzugriff auf storage/ und den backups-Festplattenstamm (Standard storage/app/backups). Soll nicht 777 verwenden? Gewähren Sie stattdessen Eigentums- oder Gruppenzugriff.
• Bewahren Sie Geheimnisse in .env. .env, .env.* (außer .env.example) und auf auth.json werden von Git ignoriert. CMS-API-Tokens und E-Mail-Passwörter werden niemals verwendet ins Repository geschrieben.

• Die CMS-Authentifizierung ist Laravel-nativ (keine Breeze/Jetstream/Fortify-Anforderung). Administratoren Melden Sie sich unter /webadmin/login an. Passwörter sind bcrypt-gehasht.
• Drei Installationsrollen ermöglichen den Zugriff: super_admin (installationsweit), site_admin (zugewiesene Sites) und editor (Entwurf von Inhalten innerhalb zugewiesener Sites). Cross-Site Aktionen (Verschieben/Duplizieren, Shared Slots) erzwingen den Zugriff auf Quelle und Ziel Websites. Siehe Benutzer und Berechtigungen.
• Der /webadmin-Administratorbaum ist durch das CMS-Web + Authentifizierung + Admin-Zugriff geschützt Middleware-Stack. Öffentliche Routen rendern niemals Entwurfsinhalte; Entwurf/Vorschau Für den Zugriff ist ein authentifizierter Administrator oder ein vertrauenswürdiges Token mit content.read erforderlich.
• Anmelde- und Passwort-Reset-Anfragen sind ratenbegrenzt. Fehlgeschlagene Anmeldungen sind gedrosselt pro E-Mail+IP (Standard 5 Versuche, dann eine kurze Sperre, die a erfolgreiche Anmeldung wird gelöscht; Tune mit WEBBLOCKS_CMS_MAX_LOGIN_ATTEMPTS und WEBBLOCKS_CMS_LOGIN_DECAY_SECONDS). Ein Backstop pro IP begrenzt zusätzlich die Login-, Passwort-vergessen- und Passwort-Reset-Endpunkte vor Überschwemmungen und E-Mail-Rotationsversuche.

Der Internal Content API (/webadmin/api) ist für vertrauenswürdige Bediener/KI-Tools gedacht.

• Persönliche Token werden von jedem aktiven CMS-Benutzer erstelltProfil → Persönlich API-Tokens; Systemtoken auf Installationsebene werden von a erstelltsuper_adminausSystem → API-Tokens. Beide sind esals Hashes gespeichertund im Klartext dargestellt Text nur einmal.
• Jedes Token ist explizitFähigkeiten(Lesen, veröffentlichen, Medien, Plugin Lebenszyklus, Handel, …). Erweiterte/zerstörerische Funktionen sind separate Opt-Ins; Normale Seitenerstellungsfunktionen sind die Standardeinstellung.
• Token können seinwiderrufen(die Prüfzeile bleibt erhalten) oder gelöscht. Ein pro Token Das Aktivitätsprotokoll zeichnet Zeit, Methode/Pfad, Route, Fähigkeitsergebnis, IP usw. auf Zusammenfassung des Benutzeragenten – aber niemals Anforderungstexte, Abfragezeichenfolgen, Antworten usw Tokenwerte.
• Behandeln Sie API-Tokens als Geheimnisse. Beschränken Sie sie auf die minimalen Fähigkeiten eines Werkzeugs Bedarf, und drehen Sie sie, wenn sie freigelegt werden.
• Persönliche API-Token überschneiden sich kontinuierlich mit ausgewählten Funktionen und Websites mit der Live-Rolle, dem aktiven Status, den Site-Zuweisungen und der Seite ihres Besitzers Workflow-Autorität. Vorgänge auf Installationsebene bleiben nur System-Token.
• Persönliche API-Tokens können auf genaue IPv4/IPv6-Adressen oder CIDR beschränkt werden Netzwerke und haben eine tokenspezifische Obergrenze für Anfragen pro Minute. Diese Schecks werden zusätzlich zum Live-Benutzer-, Standort-, Workflow- und Funktionszugriff erzwungen.
• Sowohl das Kanonische/webadmin/apiRouten und das Erbe/admin-apiKompatibilitätsrouten teilen sich den Ratenbegrenzer Internal Content API.

Wenn ein Reverse-Proxy oder CDN vorhanden ist, konfigurieren Sie Laravel so, dass nur diesem vertraut wird Überprüfen Sie die tatsächlichen Proxy-Adressen und überprüfen Sie die aufgelöste Client-IP, bevor Sie eine aktivieren Zulassungsliste. Akzeptieren Sie niemals gefälschte weitergeleitete Header direkt aus dem Internet.

SehenPersönliche API-TokensUndInternal Content API.

In-App-Systemaktualisierungen ersetzen den CMS-Paketcode unter vendor/fklavyenet/webblocks-cms auf der Live-Site. Denn ein Update führt neu aus Code, die Integrität des heruntergeladenen Pakets ist eine remote-Code-Ausführung Grenze. WebBlocks CMS mildert dies wie folgt:

• Obligatorische SHA-256-Prüfsumme. Der Updater lädt dann die Release-ZIP herunter Verifiziert hash_file('sha256', …) anhand des vom bereitgestellten checksum_sha256 Geben Sie Metadaten mithilfe eines zeitsicheren hash_equals frei. Wenn die Prüfsumme fehlt or stimmt nicht überein, das Update ist refused – es greift nicht auf zurück Anwenden eines nicht verifizierten Pakets.
• Canonical Update Service. Update-Metadaten und Downloads stammen von publisher.webblocksui.com. Da die Prüfsumme zusammen mitgeliefert wird Beim Herunterladen durch denselben Dienst schützt die Prüfsumme vor beschädigten oder beschädigten Dateien manipulierte artifacts, jedoch nicht gegen einen vollständig kompromittierten Update-Dienst.
• Installationen sind Verbraucher, keine Herausgeber. Installierte Websites rufen Updates ab, aber darf nicht in das Upstream-Repository übertragen werden. Die Veröffentlichung erfolgt ausschließlich aus dem Wartungscheck mit einem WEBBLOCKS_PUBLISHER_TOKEN.

Zur Tiefenverteidigung gegen einen kompromittierten Update-Dienst – wo die Prüfsumme ist reist neben dem Artefakt – Veröffentlichungen können kryptografisch signiert sein. Der Herausgeber signiert die Veröffentlichungsprüfsumme mit einem geheimen Ed25519-Schlüssel und installiert Überprüfen Sie die Signatur anhand eines gepinnten öffentlichen Schlüssels (sodium_crypto_sign). install lehnt jede Version ab, die nicht mit dem echten Schlüssel signiert ist.

Um es zu aktivieren:

1. Generieren Sie einmalig ein Schlüsselpaar auf dem Wartungs-/Herausgebercomputer: php artisan webblocks:updates:keygen.
2. Halten Sie das gedruckte WEBBLOCKS_PUBLISHER_SIGNING_KEY (Geheimnis) privat – legen Sie es fest nur dort, wo Sie Veröffentlichungen veröffentlichen. Legen Sie es niemals fest oder legen Sie es bei einer Installation fest.
3. Pinnen Sie den gedruckten öffentlichen Schlüssel, damit Installationen signierte Veröffentlichungen überprüfen: eingestellt WEBBLOCKS_UPDATE_PUBLIC_KEY, oder stellen Sie ReleaseDefaults::UPDATE_PUBLIC_KEY so ein Der Schlüssel wird im CMS-Code geliefert (empfohlen – ein Code-gepinnter Schlüssel kann nicht sein durch einen kompromittierten .env ausgetauscht).
4. Veröffentlichen Sie wie gewohnt; Der Herausgeber signiert jede Veröffentlichung automatisch.

Der Rollout ist sicher: Während kein öffentlicher Schlüssel gepinnt ist, ist dies bei der Signaturüberprüfung nicht der Fall erzwungen (Prüfsummenüberprüfung gilt weiterhin). Sobald ein öffentlicher Schlüssel angeheftet ist und Da Installationen diesen Code erhalten, muss jede zukünftige Version einen gültigen Ed25519 enthalten Signatur über ihre Prüfsumme, oder das Update wird abgelehnt.

• Öffentliche Formulare teilen sich eine lokale Schutzpipeline: formulargebundener signierter Beweis, generierte Honeypots, Timing, Inhalts-/Wiederholungsbewertung, eingegebener Absender und Quelle Zähler, /24- oder /64-Netzwerkdruck und vor Ort erlernte Fingerabdrücke. Es stellt keine externe Anfrage. Schutzzähler verwenden verschlüsselte Hashes; tägliche Kennzahlen enthalten nur aggregierte Entscheidungen. Siehe Öffentliche Einreichung Schutz.
• Kontaktformulare Store bewertete Einsendungen zur Überprüfung. Quarantäne und Spam-Unterdrückung Benachrichtigung und bleibt dabei vom Benachrichtigungszustellungsverlauf getrennt. Siehe Kontaktformulare und Nachrichten.
• Comments ist standardmäßig pending; Eine Spam-Entscheidung wird nie als Spam gespeichert tritt ohne Moderation öffentlich auf.
• Trusted HTML ist auf Wrapper-angrenzendes Layout-Markup beschränkt und darf dies nicht sein wird zum Einfügen von Skripten verwendet; Bevorzugen Sie die nativen Blockverträge, die die internen Die Inhalts-API validiert Draft-First.
• Medien-Uploads sind auf eine Zulassungsliste mit Bildern, Videos und Dokumenten beschränkt Typen (inhaltsüberwacht, nicht erweiterungsvertrauenswürdig). SVG-Uploads sind deaktiviert standardmäßig, da ein SVG Inline-Skripte übertragen kann und Medien von dort bereitgestellt werden den gleichen Ursprung wie der Admin. Aktivieren Sie es nur bei Installationen, bei denen jedes Konto vorhanden ist vertrauenswürdig ist, der Medien hochladen kann, über WEBBLOCKS_CMS_ALLOW_SVG_UPLOADS=true. Dieselbe Zulassungsliste regelt serverseitige Remote-Medienabrufe.
• Remote-Medienabruf validiert jedes Umleitungsziel und heftet das HTTP an Verbindung zur öffentlichen IP-Adresse herstellen, die die Validierung bestanden hat. Dadurch wird die geschlossen DNS-Such-/Verbindungsrennen, das von DNS-Rebinding-Angriffen verwendet wird. Fernabruf Schlägt fehl, wenn PHP cURL-Adresspinning nicht verfügbar ist.
• Managed Embedded Application Iframes sind Sandboxes undurchsichtigen Ursprungs. Ihre Eintragsantworten wenden restriktive CSP- und Referrer-Header an. CSP benennt die Aktueller registrierter Site-Ursprung explizit, damit Dokumente mit undurchsichtigem Ursprung geladen werden können ihre gleichen Site-Skripte, Stile, Medien und <base>-URL, ohne dies zu gewähren iframe gleicher Ursprungszugriff auf CMS-Cookies, Speicher, die übergeordnete Seite oder authentifizierte Panel-Anfragen.
• Komplette eingebettete Anwendungspakete bleiben isoliert. Unveränderlich, Versionierte Paketdateien werden über eine öffentliche Route nur für Anwendungen bereitgestellt mit anonymem CORS und Cross-Origin-Ressourcenheadern, die einen undurchsichtigen Ursprung ermöglichen Spiele zum Laden von Bildern, Audio, Schriftarten, JSON- und Gebietsschemadateien ohne Gewähr allow-same-origin. Die ZIP-Installation lehnt Traversal und doppelte Pfade ab. ausführbare Serverdateien und Verstöße gegen begrenzte Anzahl oder erweiterte Größe.

• Update-Prüfungen können datenschutzfreundliche Akzeptanztelemetriedaten an den Herausgeber senden: nur product_key, installed_version, channel, ein zufälliger lokal persistierender installation_id und telemetry_schema_version. Keine Domains, URLs, Admin E-Mails, Pfade, Datenbankdetails, Benutzerzahlen, Token oder beliebige Umgebungen/Konfigurationen Werte werden gesendet. Stellen Sie WEBBLOCKS_TELEMETRY=false auf Opt-out ein. Metadatenprüfungen Fahren Sie ohne Installations-ID fort.
• Visitor-Berichte behalten Seitenansichtsdatensätze mit Pfad, Zeit und normalisiertem Referrer bei Host, UTM-Werte, Gerätekategorie und Bot-Klassifizierung. Einwilligungsbasierte Vollständigkeit Beim Tracking können auch ein Sitzungsschlüssel und ein IP-HMAC gespeichert werden. diese sind pseudonym Identifikatoren, keine Garantie für Anonymität. Neue Diagramme und Seitendetailmodalitäten Führen Sie keine zusätzlichen Identifikatoren oder öffentlichen Tracking-Skripte ein. Geplant Bei der Aufbewahrung werden abgelaufene Details durch tägliche Standort-/Gebietsschemazählungen und höher ersetzt verfallen diese Zählungen. Siehe Operations.

Report privat über GitHub Security Advisories oder den Betreuerkontakt in SICHERHEIT.md. Wir sind bestrebt, Meldungen innerhalb von 5 Werktagen zu bestätigen Tage und wird mit Ihnen einen Zeitplan für die Offenlegung koordinieren.

CMS-verwaltete Plugin-Installation, Aktualisierung und Aktivierung validieren den Kandidaten in einem separaten PHP-Prozess vor der normalen Laufzeitaktivierung. Ungültige Quelle, Anbieter-/Routenfehler, vorzeitige Beendigungen und Zeitüberschreitungen lehnen es ab; Bei einem abgelehnten Update bleibt das Arbeitspaket erhalten. Fehler bei der Datenbankeinrichtung führen dazu, dass das Plugin deaktiviert bleibt und seine Daten erhalten bleiben. Laufzeitquellen- oder Routenfehler stellen das betroffene Plugin unter Quarantäne und entfernen teilweise registrierte Routen.

Der /webadmin/plugin-recovery-Bildschirm und die Anmeldung werden ohne installierte Plugin-Quelle geladen. CMS 1.94.2 wendet den Administratorzugriff für aktive Konten und die Super admin-Autorisierung an, einschließlich vorhandener Sitzungen. Die Wiederherstellung kann das fehlerhafte Plugin nur dann deaktivieren oder das beibehaltene vorherige Paket wiederherstellen, wenn keine Datenbankmigration ausgeführt wurde. Bei der Wiederherstellung wird die Startvalidierung wiederholt und die vorherigen Assets erneut veröffentlicht. Die normalen Anmeldekontrollen und der CSRF-Schutz bleiben in Kraft. Dadurch wird der Wiederherstellungspfad des verwalteten Plugins geschützt, nicht willkürliche Hostanbieter oder die ausführbare PHP-Isolation. Siehe Plugin System.

Installationsaktualisierungen erfordern ein installationsweites Systemtoken, das einem aktiven Benutzer mit Systemzugriff gehört. system-updates.read und system-updates.run sind separate Opt-Ins; Weder persönliche Token noch standortbezogene Token können sie verwenden. Die Ausführung erfordert eine ausdrückliche Genehmigung der installierten Version, der Zielversion und der Prüfsumme sowie eine dauerhafte Idempotenzquittung für unsichere Antworten. Siehe Updates.