Änderungsprotokoll — PrestaWard Snapshot

0.1.8

• Das Dashboard ist in Registerkarten unterteilt („Übersicht“, „Änderungen“, „Aufträge“, „Prüfungen“, „Einstellungen“ und „Aktivitätsprotokolle“) und berücksichtigt nur die aktuell geöffnete Registerkarte, sodass es in großen Shops schneller geladen wird. Das Support-Panel von GO ON Agency verfügt über eine eigene Registerkarte „Support“, die immer an letzter Stelle steht, und der Bereich Integrity befindet sich am Ende aller Registerkarten.
• Mindestzusammenfassung: die aktuelle Baseline, der letzte Vergleich und dessen Ergebnis, eine Hauptmaßnahme sowie höchstens eine Zeile mit den laufenden Aufträgen oder der wichtigsten Warnmeldung (noch zu überprüfende Änderungen, neue oder nicht mehr abgedeckte Ordner, die eine neue Baseline erfordern, ein noch zu schließendes Wartungsfenster, ein Cron-Job, der noch nie ausgeführt wurde oder verspätet ist, oder Backups im Web-Stammverzeichnis). Bei weiteren Warnmeldungen wird in der Zeile „und N weitere“ hinzugefügt.
• Registerkarte „Aufträge“: Der laufende Auftrag wird als Karte mit seinen Phasen (Erkennen, Fingerabdrücke berechnen, Validieren, Vergleichen oder Veröffentlichen, Attestierung) angezeigt, zusammen mit dem Dateizähler, der verstrichenen Zeit, der letzten Aktualisierung und der Angabe, wer den Auftrag ausführt (Backoffice, Cron oder Befehlszeile). Ein Auftrag, der einen Befehlszeilenprozess erfordert, wird gelb angezeigt, wobei der Grund in Klartext und der genaue Befehl mit einer Schaltfläche zum Kopieren dargestellt wird; im Browser gibt es keine Schaltfläche zum Fortsetzen.
• 90-Tage-Auftragsverlauf in einer einzigen Tabelle (Typ, Herkunft, Mitarbeiter, Beginn, Dauer, Status, Ergebnis und Hinweise) mit Filtern nach Typ, Status und Datum sowie Paginierung, anstelle der bisherigen Begrenzung auf die letzten 20 Aufträge oder 7 Tage. Das Ergebnis eines Vergleichs ist mit den gefundenen Änderungen verlinkt, und eine Überprüfung der Kerndateien ist mit der Registerkarte „Überprüfungen“ verlinkt.
• Details zu jedem Auftrag: Zeitachse, Dateien, maximaler Speicherbedarf, Hash der Richtlinie, verknüpfte Baseline und Vergleich, Benachrichtigungen mit Beispielordnern, eine übersetzte Fehlermeldung im Falle eines Fehlers sowie ein Download der Diagnose. Wenn die Dateidetails eines abgeschlossenen Auftrags gelöscht werden, bleibt eine Zusammenfassung erhalten (Anzahl der Warnmeldungen mit Beispielordnern und nicht vollständig abgedeckten Ordnern), und auf der Seite wird angezeigt, dass die Details gelöscht wurden.
• Die Abdeckung nach Kategorien wird an das Ende des Abschnitts „Änderungen“ verschoben; die Prüfungen für Shops (Sicherungen, Kerndateien, Konfigurationsprüfung und Modulzustand) werden unter „Prüfungen“ zusammengefasst; und die Einstellungen für E-Mail, Cron, Analysierichtlinien, Wartungsfenster und Speicher befinden sich unter „Konfiguration“.
• Die Sicherheitskonfigurationsprüfung umfasst nun 14 Prüfschritte. Neu: PHP-Sicherheitshärtung (allow_url_include und expose_php), Versionskontrollordner und Umgebungsdateien (.git, .svn, .hg, .env und Varianten) im Web-Stammverzeichnis sowie innerhalb von Modulen und Themes, Webservice-Schlüssel mit Schreibzugriff auf zahlreiche Ressourcen (es wird lediglich gezählt, wie viele vorhanden sind; ein Schlüssel wird niemals gelesen oder angezeigt), Überprüfung der IP-Adresse im Cookie sowie inaktive Konten, die das SuperAdmin-Profil behalten (diese werden lediglich gezählt, ohne Namen oder Adressen). Zu jedem Punkt gibt es eine Erläuterung und eine Lösung, und was nicht gelesen werden kann, wird als „nicht geprüft“ gekennzeichnet. Die Dateien .git, .svn und .env im Web-Stammverzeichnis werden von der Prüfung der Installationsdateien und Kopien auf die neue Prüfung umgestellt, um eine doppelte Zählung zu vermeiden.
• Heuristiken zur Erkennung von Kartenskimming in JavaScript: Der neue oder geänderte JavaScript-Code des aktiven Themes und der Zahlungsmodule wird ebenfalls auf drei Anzeichen überprüft: Code, der die Kartennummer, das Ablaufdatum oder den Sicherheitscode ausliest und Daten an eine andere Website übermittelt (hohes Risiko), Daten, die aus dem Bestell- oder Zahlungskode an eine andere Website gesendet werden (Prüfung nötig), sowie stark verschleierter Code in Verbindung mit dem Bestell- oder Zahlungskode (Prüfung nötig). Die Adressen des Shops selbst, der Zahlungsmodule und – bei schwächeren Anzeichen – bekannter Analyseserver gelten nicht als andere Website. Eine Übereinstimmung ist ein Grund, die Datei zu überprüfen, jedoch kein Beweis für eine Kompromittierung, und eine Adresse, die der Code während der Ausführung dynamisch generiert, wird nicht erkannt.
• Multimedia-Volumen-Schätzung: Für jede Baseline und jeden Vergleich werden für jeden Multimedia-Ordner (img, upload, uploads und download) die bereits durchlaufenen Dateien und Bytes gezählt, ohne auf weitere Dateien zuzugreifen oder Daten pro Datei zu speichern. Unter „Überprüfungen“ werden die Gesamtzahl pro Ordner, das Wachstum gegenüber der Baseline sowie eine eventuelle Überschreitung eines Limits angezeigt. Die „Einstellungen“ umfassen drei Grenzwerte: maximale Dateianzahl, maximale Größe in GB und maximales Wachstum gegenüber der Baseline in Prozent (standardmäßig 50 %; der Wert „0“ deaktiviert ein Limit). Ein überschrittenes Limit wird in der Übersicht und in der Warn-E-Mail angezeigt, die auch dann versendet wird, wenn sich keine Datei so stark verändert hat, dass sie dies allein ausgelöst hätte.
• Sichtbare Überwachungsgrenze: Eine Analyse liest maximal 250.000 Namen in den ausgeschlossenen Ordnern aus, und nachfolgende Ordner wurden als nicht abgedeckt registriert, aber nur innerhalb des Auftrags angezeigt. Nun werden diese als Warnzeile in der Zusammenfassung und als Hinweis unter „Prüfungen“ mit der Anzahl der nicht überwachten Ordner angezeigt, und das Multimedia-Volumen wird als „teilweise“ gekennzeichnet, wenn es unter diesem Grenzwert gemessen wurde.
• Behebt das Problem, dass die Verbindung zu Integrity im Backoffice im Kontext „Alle Shops“ oder wenn ein anderer Shop als der erste den Registrierungstest bereitstellte, gestört war: Der verbundene Shop wechselte in den Status „Registrierung ausstehend“ und der Test konnte nicht unterzeichnet werden. Die Identität der Installation wird nun in jedem Kontext als Einheit aus dem globalen Bereich (oder aus dem Shop, in dem sie gespeichert ist) gelesen; bei einer Aktualisierung wird eine in einem Shop gespeicherte Identität ohne Neugenerierung in den globalen Bereich übertragen, und falls sie nicht gelesen werden kann, bleibt der Status von Integrity unverändert.
• Neu: Gemeinsame Filterleiste. Die Änderungsprüfung und der Arbeitsverlauf nutzen diese: Die Auswahlfelder sind in einem Raster gleicher Breite angeordnet, die Suchfunktion und die Schaltfläche „Filtern“ befinden sich in derselben Zeile, und sekundäre Aktionen, wie der Export des Audits als CSV-Datei, sind rechtsbündig ausgerichtet. Zuvor waren die Filter überfüllt und die Schaltflächen überlappten sich.
• Die Benachrichtigungs-E-Mails, Wartungszusammenfassungen und Test-E-Mails zeigen in der Kopfzeile das Logo Ihres Shops (mit dem Namen des Shops als Alternativtext) sowie eine einheitliche Fußzeile mit dem Logo von GO ON Agency und der Signatur „PrestaWard by GO ON Agency“, ohne Links oder Kontaktadressen. Das Logo in der Fußzeile ist eine Datei des Moduls selbst, die von Ihrem Shop bereitgestellt wird.
• Behebt den Fehler, dass der Betreff der E-Mails den Namen des Shops zweimal enthielt.
• Einheitliches Erscheinungsbild des Dashboards in allen vier PrestaWard-Modulen: Abschnittsüberschriften, Formularfelder mit neutralen Rahmen und einheitliche ausklappbare Blöcke, einzeilige Statistiken sowie ein größeres Logo der GO ON Agency in der Kopfzeile. Die Hauptschaltfläche erhält nun eine einheitliche Farbe der Marke ohne Farbverlauf.
• Behebt das Problem, dass in PrestaShop 9 die Registerkarten im Administrationsbereich als unterstrichene Links und die Abschnittsüberschriften in Großbuchstaben angezeigt wurden. Die allgemeinen Stile heben diesen Effekt nur innerhalb des PrestaWard-Panels auf, sodass PrestaShop 1.7 und 8 unverändert wie zuvor dargestellt werden.
• Behebt das Problem, dass in PrestaShop 1.7 das Stylesheet des Moduls beim Registrieren mit der Versionsnummer in der Adresse verworfen wurde. Nun wird die Datei überprüft und ohne Parameter registriert, sodass das neue Erscheinungsbild in den Versionen 1.7, 8 und 9 angezeigt wird.
• Behebt das Problem, dass in PrestaShop 9 die Aktionen im Dashboard (Anfragen für Aufträge und das Herunterladen des Berichts zum Support sowie die Synchronisierung mit Integrity) das Sicherheitstoken mit einer Methode überprüfen, die PrestaShop 9 nicht verwendet, wodurch sie möglicherweise abgelehnt werden. Die Validierung erfolgt nun über den PrestaShop-9-Dienst; in PrestaShop 1.7 und 8 bleibt die Überprüfung unverändert.
• Wenn die Verbindung zu Integrity derzeit nicht aktualisiert werden kann, zeigt das Dashboard eine einzige Meldung an: Die gespeicherte Verbindung ist weiterhin gültig und der Versuch wird automatisch wiederholt. Die Bezeichnungen aller Registerkarten sind in die neun Sprachen übersetzt.
• In der Produktkopfzeile werden wieder das Logo von GO ON Agency und der Vermerk „PrestaWard by GO ON Agency“ ohne Links angezeigt. Das Format der Baseline, die Bytes des Manifests und der Vertrag mit der Integrity-API bleiben unverändert; das Update fügt Spalten hinzu (zwei zur Auftragstabelle sowie diejenigen zum Medienvolumen nach Ordner, Auftrag und Baseline).

0.1.7

• Analysiert den verdächtigen Code in neuen oder geänderten PHP- und JavaScript-Dateien (jeweils bis zu 512 KB) auf Muster, die für Web-Shells und verschleierten Code typisch sind, und erläutert das Ergebnis in verständlicher Sprache. Eine Übereinstimmung bedeutet „Diese Datei überprüfen“, nicht „Nachweis eines Angriffs“; eine Datei ohne Übereinstimmungen gilt nicht als sicher, und eine Datei, die das Limit überschreitet, wird nur als teilweise überprüft markiert.
• Erkennt getarnte Bilder (mit falschem Header oder PHP-Code im Bild) in allen Ordnern: einbezogenen, ausgeschlossenen und – innerhalb eines Zeit- und Größenbudgets – flüchtigen Ordnern wie img/tmp, die die Analyse weiterhin nicht durchläuft.
• Weist jeder Änderung eine Risikostufe zu (hoch, Prüfung nötig oder niedrig), die in der Änderungsprüfung sichtbar und filterbar ist und in die Audit-CSV-Datei sowie in die Warn-E-Mails aufgenommen wird.
• Fasst Aktualisierungen von Modulen und Themes in einem einzigen Element zusammen, das die alte und die neue Version enthält. Der geänderte PHP-Code innerhalb einer erkannten Aktualisierung stellt ein geringes Risiko dar und löst keine Warn-E-Mails mehr aus. Erfordert eine mit dieser Version erstellte Baseline.
• Neues Kerndateien-Dashboard: Es vergleicht die Dateien mit der offiziellen Prüfsummenliste Ihrer PrestaShop-Version in wieder aufnehmbaren Stapeln. Eine Abweichung ist kein Beweis für einen Einbruch; sollte die Liste nicht vorhanden sein oder nicht heruntergeladen werden können, zeigt das Dashboard an, dass der Kern nicht überprüft wurde, und stellt ihn niemals als „bestanden“ dar.
• Neues Audit der Sicherheitseinstellungen mit einer Bewertung von 0 bis 100 (Debug-Modus, Administrationsordner, Konfigurationsberechtigungen, Installationsordner, Dumps und komprimierte Dateien im Web-Stammverzeichnis, PHP-Version, HTTPS und sichtbare PHP-Fehler sowie weitere Punkte). Zu jedem Punkt gibt es eine Erläuterung und eine Lösung; was nicht überprüft werden kann, wird als „nicht überprüft“ gekennzeichnet und nicht bewertet.
• Es weist auf einen Cron-Job hin, der noch nie ausgeführt wurde, und meldet mit einer eigenen Warnmeldung die im Web-Stammverzeichnis vorhandenen Ordner und Sicherungskopien von Modulen.
• Bei Neuinstallationen werden Modul-Backups und der Download-Ordner standardmäßig ausgeschlossen. Bei bestehenden Installationen werden diese Ausschlüsse im Dashboard angeboten und nur angewendet, wenn Sie sie aktivieren, wodurch eine neue Baseline erstellt wird.
• Wartungsfenster von 1 bis 4 Stunden: Unterdrückt Warn-E-Mails, protokolliert jedoch weiterhin die Änderungen und sendet nach Abschluss eine zusammengefasste Übersicht mit den Aktionen „Diese Änderungen akzeptieren“ oder „Verwerfen“. „Akzeptieren“ markiert die Änderungen lediglich als geprüft; Snapshot erstellt niemals eigenständig eine Baseline.
• Wenn die Abdeckung der Analyse zwischen den Versionen zunimmt, werden Dateien in Ordnern, die von der alten Baseline nicht abgedeckt waren, als neue Abdeckung gemeldet und nicht als Tausende hinzugefügter Dateien mit kritischen Warnmeldungen.
• Die Änderungsprüfung ist für sehr umfangreiche Ergebnisse ausgelegt: Paginierung mit Seitenwechsel, nach Ordner, Status und Risiko gruppierte Zusammenfassung sowie ausstehende Änderungen aus früheren Baselines, die als ersetzt gekennzeichnet sind.
• Verkürzt die Zeit für die Erstellung der Baseline und die Verzeichnisvalidierung in großen Shops mit zurückbehaltenen früheren Aufträgen (Minuten statt Dutzender Minuten) und löscht die temporären Zeilen abgeschlossener Aufträge in begrenzten Stapeln.
• Behebt verschiedene Warnmeldungen: Snapshot erkennt die eigenen Dateien nicht mehr als Änderung mit hohem Risiko, die Standard-Sicherheitsdatei index.php von PrestaShop wird nicht mehr als verdächtige ausführbare Datei markiert, unter „Letzte Änderungen“ werden die Gesamtzahlen des letzten Vergleichs angezeigt, und nach dem Erstellen einer Baseline wird der vorherige Vergleich im Dashboard nicht mehr als aktuell dargestellt.
• Im Backoffice wird „Wird über die Konsole verarbeitet“ angezeigt, während der Konsolenprozess läuft; ein Neuladen der Seite nach dem Klicken auf eine Schaltfläche löst keine erneute Übermittlung aus, und eine abgelehnte Inizialisierung gibt an, welcher Auftrag gerade ausgeführt wird. Der Konsolenprozess schreibt eine kurze Fortschrittszeile anstelle einer Zeile pro Schritt.
• Konsistenz im Backoffice: Das Dashboard für Aufträge und seine Schaltflächen sehen genauso aus wie der Rest des Dashboards, und die Statusmeldungen des Cron-Jobs und des Aktivitätsprotokolls werden in allen neun Sprachen in der Sprache des Backoffice angezeigt.
• Das Support- und Diagnose-Panel wird – wie bei allen anderen PrestaWard-Modulen – direkt vor dem Abschnitt Integrity platziert und verschwindet im Kontext „Alle Shops“ nicht mehr: Es weist darauf hin, dass ein Shop ausgewählt werden muss.
• Die Stylesheets werden mit der Modulversion geladen, sodass das neue Erscheinungsbild nach der Aktualisierung angezeigt wird, ohne dass der Browser-Cache geleert werden muss.
• Die Synchronisierung mit Integrity erfolgt bei jedem Öffnen des Panels über eine Hintergrundanfrage, die die Seite niemals verlangsamt und höchstens einmal pro Minute und Shop durchgeführt wird.

0.1.6

• Ein symbolischer Link unterbricht den Scanvorgang nicht mehr: Er wird übersprungen, ohne dass ihm gefolgt oder sein Fingerabdruck berechnet wird (er ist somit nicht Teil der Baseline), und es erfolgt eine Meldung im Dashboard mit einer Warnung, wenn er außerhalb des Shops oder auf ein nicht vorhandenes Ziel verweist.
• Lässt beim Durchsuchen Dateien außer Acht, die nicht Teil des Manifests sein können.
• Durchsucht niemals die temporären Ordner von PrestaShop (img/tmp) und die kombinierten Ressourcen-Caches des Themes, da diese ständig neu generiert werden und eine Analyse mit directory_changed unterbrechen könnten.
• Wendet die Ausschlüsse an, bevor ein Ordner betreten wird: Die ausgeschlossenen Ordner sind nicht mehr Teil der Integritätsprüfung und werden lediglich in einem separaten Durchlauf auf ausführbare Dateien überprüft, der den Vorgang niemals unterbricht und auf 250.000 Namen pro Auftrag begrenzt ist.
• Ein einbezogener Ordner, der sich während der Analyse ändert, wird bis zu dreimal erneut gelesen. Ändert er sich weiterhin, halten die Ordner des Kerns, der Konfiguration, der Verwaltung, der Zahlungsmodule und des aktiven Themes den Auftrag wie zuvor an; der Rest wird mit einer Warnmeldung übersprungen, und der Auftrag wird beendet.
• Der Cron-Job verarbeitet pro Aufruf mehrere aufeinanderfolgende Stapel (bis zu etwa 20 Sekunden) und meldet den Status cli_required sowie den HTTP-Status 409, wenn ein Auftrag die Ausführung über die Befehlszeile erfordert. Ein Überwachungstool, das jede Antwort, die nicht im 2xx-Bereich liegt, als Fehler behandelt, wird dies erwartungsgemäß melden. Dieser Prozess wird vom Serveradministrator manuell ausgeführt: Das Modul startet ihn niemals von selbst.
• Verstärkt die Sperre, die gleichzeitige Cron-Ausführungen verhindert, selbst wenn die ersten beiden Ausführungen zeitlich zusammenfallen.
• Verschiebt die temporären Manifest-Dateien in ein privates Verzeichnis innerhalb des Shops, das mit open_basedir und mit der Bereinigung des temporären Systemverzeichnisses kompatibel ist. In Nginx empfiehlt es sich, den Zugriff auf var/prestaward-snapshot/ zu sperren.
• Erkennt Tabellen, die nicht InnoDB verwenden, zeigt eine klare Meldung in allen neun Sprachen an und konvertiert die Tabellen des Moduls bei der Aktualisierung, wobei jede Konvertierung protokolliert wird.
• Fügt im Backoffice ein schreibgeschütztes Statusprüfungs-Panel hinzu: privater Vorbereitungsordner, Datenbank-Speicher-Engine, Cron-Häufigkeit und Aufträge, die auf den Befehlszeilenprozess warten.
• Korrektur der Gesamtzahlen im Bericht über Aufträge: Links werden getrennt von den ausgeschlossenen Dateien gezählt.
• Jedes Modul wird nur einmal analysiert, entweder im Bereich „Zahlungen“ oder im Bereich „Module“, sodass ein Modul, das kein Zahlungsmodul ist und sich während der Analyse ändert, den Auftrag nicht mehr unterbricht.
• Wenn ein Auftrag einen Ordner nicht vollständig abdecken kann, wird der Snapshot mit teilweiser Abdeckung angezeigt, und der Vergleich markiert die Dateien in diesen Ordnern als „nicht überprüft“ statt als gelöscht.
• Das Dashboard für Aufträge zeigt in den neun Sprachen an, welche Ordner von den einzelnen Warnungsarten betroffen sind und welche Maßnahmen zu ergreifen sind. Bei der Deinstallation werden auch die Tabellen für Aufträge gelöscht.
• PrestaShop 9: Der Befehlszeilenprozess und der Cron-Job schlagen nicht mehr fehl, wenn der „admin-api“-Ordner des Kerns mit dem des Backoffice verwechselt wird.
• Wenn der Befehlszeilenprozess fehlschlägt, endet er mit einer Diagnosezeile mit einem festen Fehlercode, ohne Pfade oder interne Meldungen.
• Senkt die Kosten der Analyse in Shops mit vielen Dateien.
• PHP 7.1 und 7.2: Die Registrierung, die Attestierung und der Heartbeat von Integrity werden nicht mehr durch einen Syntaxfehler unterbrochen.
• Korrigiert das Update ab Version 0.1.5, bei dem die Snapshot-Tabelle fehlt.
• Im Labor unter PrestaShop 1.7, 8 und 9 validiert, einschließlich eines Tests mit 300.000 Dateien, die sich während der Analyse ändern.

0.1.5

• Stellt die automatischen Wiederholungsversuche für die Attestierung von Integrity, die ausstehenden Heartbeats und die Aufbewahrung nach Antworten des asynchronen Cron-Jobs wieder her. Die Wartung wird in begrenzten Stapeln ausgeführt und getrennt vom Fortschritt des Scans koordiniert.
• Falls eine frühere Baseline mehrere Verwaltungsordner enthielt, kann der nächste Vergleich zusätzliche Einträge anzeigen: Überprüfen Sie die Unterschiede und erstellen Sie gegebenenfalls eine neue Baseline, ohne die vorherige automatisch zu löschen.
• Erlaubt gültige Dateinamen mit aufeinanderfolgenden Punkten und gewährleistet weiterhin den Schutz vor unsicheren Pfaden.
• Behält alle Dateien in den zusätzlichen Verwaltungsordnern bei, ohne sie mit denen des aktiven Backoffice zu verwechseln.
• Speichert den Fortschritt der Baselines und Vergleiche, damit sie nach dem Schließen des Dashboards oder dem Abbruch einer Anfrage fortgesetzt werden können.
• Verarbeitet und überprüft Dateien im Stapelverfahren; die Ergebnisse werden erst nach Abschluss des Auftrags angezeigt, und bei Abbruch oder Fehler wird die letzte gültige Baseline beibehalten.
• Korrigiert den Abgleich der Verwaltungsdateien mit früheren Baselines und behält die Ausschlüsse der deaktivierten Ordner bei.
• Fügt einen herunterladbaren Diagnosebericht hinzu, der manuell an eine Support-Anfrage angehängt werden kann, ohne dass Daten automatisch übermittelt werden. Er wird nur von einem Mitarbeiter mit Bearbeitungsberechtigung und für einen ausgewählten Shop heruntergeladen und enthält keine Pfade, Dateiinhalte oder Anmeldedaten.
• Vervollständigt die Statusmeldungen im Dashboard, die Benachrichtigungen und die Vorlagen für Warnmeldungen in neun Sprachen.
• Behält die Korrekturen und Aktualisierungen zur Registrierung aus Version 0.1.4 bei.

0.1.4

• Behebt Fehler bei der Registrierung von Integrity in PrestaShop 9 und behält die bestehende Registrierung bei, wenn Shops ohne Multishop-Funktion aktualisiert werden.
• Stellt die automatischen Wiederholungsversuche bei der Registrierung wieder her und protokolliert die tatsächliche Ursache der Fehler.
• Aktualisiert das allgemeine Design des Backoffice und fügt Informationen zur Datenverarbeitung hinzu.
• Passt die Zahlen- und Zeitformate an die Sprache des Administrators an und übersetzt die Statusmeldungen und Beschriftungen im Dashboard.
• Korrigiert die Versionsnummer der installierten Version während des Updates.
• Bereitet das AFL-3.0-Paket für Addons vor: entfernt den Update-Checker und berechnet die Identität anhand der installierten Dateien.

0.1.3

• Sicherheitspatch: Der Scan umfasst nun die gesamte PrestaShop-Installation, einschließlich der Ordner override, src, vendor, upload, download, img, js sowie der Dateien im Stammverzeichnis.
• Sicherheitspatch: Dateien mit sicherheitsrelevanten Inhalten werden stets überwacht, unabhängig von ihrer Dateiendung.
• Sicherheitspatch: Verstärkt die Überprüfung der Remote-Attestierung und unterbindet automatische Wiederholungsversuche, wenn sich der Registrierungsschlüssel des Shops ändert.

0.1.2

• Automatischer Heartbeat ohne Cron, der durch den normalen Datenverkehr des Shops nicht blockierend aktiviert wird.
• Die Anfrage des Browsers bleibt innerhalb derselben Domain, und die Anmeldedaten von Integrity werden ausschließlich auf dem Server verwendet.
• Sperre pro Shop, Sechs-Stunden-Intervall und Wartezeit nach Fehlern, um Duplikate zu vermeiden.
• Die manuelle Synchronisierung von Integrity aktualisiert ebenfalls den Status der Installation.

0.1.1

• Integrity Heartbeat und Überwachung des Cron-Zustands.
• Sicheres inkrementelles Hashing mit regelmäßiger vollständiger Überprüfung und stets neu berechneten kritischen Bereichen.
• Einstufung von routinemäßigen, verdächtigen und kritischen Änderungen.
• Filter, Paginierung, Änderungsprüfung mit Anmerkungen und CSV-Export des Auditberichts.
• Metadaten-Diff ohne gespeicherten Inhalt und Aufbewahrung mit geschützter Bereinigung.
• Das Dashboard ist optisch auf das PrestaWard-Ökosystem abgestimmt.

0.1.0

• Automatische und nicht blockierende Registrierung in der PrestaWard Integrity-API.
• Lokale Warteschlange mit Wiederholungsversuchen, um jedes Manifest zu attestieren, ohne Dateien oder Inhalte zu versenden.
• Signierte, verkettete und im Shop verifizierte Remote-Belege.
• Verbindungs- und Übermittlungsstatus sind im Dashboard einsehbar.

0.0.9

• Kontextbezogene Hilfe-Links von den Konfigurationsfeldern zum öffentlichen Handbuch.
• Öffentlich zugänglicher Leitfaden, neu gegliedert nach Zielen und Bereichen, mit praktischen Erläuterungen zu jeder Einstellung.
• Die redundante Anzeige der Quelle der Aktualisierungen wurde aus den Einstellungen entfernt.

0.0.8

• Konfigurierbare Ausschlüsse nach exaktem Namen und relativem Pfad, mit unveränderlicher Richtlinie und SHA-256-Hash.
• Eine Vorschau ist zwingend erforderlich, bevor Sie eine Richtlinie aktivieren und Ihre neue Baseline erstellen.
• Verhinderung von Vergleichen zwischen unterschiedlichen Richtlinien.
• Nicht konfigurierbare Überwachung von ausführbaren Dateien und Konfigurationsdateien innerhalb von ausgeschlossenen Bereichen.
• Eingeschränkte Erkennung gefährlicher PHP-Header und Interpreter in Dateien mit irreführender Dateiendung.
• Vollständige Validierung in PrestaShop 1.7, 8 und 9, einschließlich eines gemischten Tests mit 100.000 Dateien.

0.0.7

• Die vollständige Produkt- und Modulbezeichnung wurde in PrestaWard Snapshot umbenannt.
• Der Zugriff ist zunächst auf das Administratorprofil beschränkt.
• Explizite Autorisierung zusätzlicher Profile über die nativen Berechtigungen von PrestaShop.
• Trennung von Lesezugriffen, Erstellung von Snapshots und Konfiguration mittels der Berechtigungen READ, CREATE und UPDATE.
• Ausblendung von Konfigurationsdaten, Cron-Tokens und sensiblen Aktionen für Profile mit Lesezugriff.
• Präzisierung der Dokumentation: Das Modul überwacht die Integrität, speichert jedoch keine Sicherungskopien und stellt diese auch nicht wieder her.

0.0.6

• Produkt-, Leitfaden-, Anbieter- und Support-Links bleiben nach einer Neuinstallation erhalten.
• Aktualisierung der Metadaten aus dem öffentlichen Manifest.
• Logos der GO ON Agency, die im Backoffice und in E-Mails verlinkt sind.
• Alternative URL, die in HTML- und Nur-Text-E-Mails angezeigt wird.
• Test-E-Mail-Aktion und reproduzierbares Release-Tooling.

0.0.5

• Autoload des Legacy-Controllers korrigiert.
• Der Zugriff wurde in den Stammbereich PrestaWard Snapshot verschoben.

0.0.4

• Klickbares Backoffice-Menü.
• Vollständige Validierung des sauberen Installations- und Deinstallationszyklus.

0.0.3

• Expliziter Multishop-Kontext.
• Unterstützung dynamischer Eigenschaften in PHP 8.5.

0.0.2

• Autorisierungsrollen und explizite Zugriffsberechtigungen.

0.0.1

• Baseline, Vergleich, Warnmeldungen, Cron, Protokolle, Überprüfung auf Updates und Start-Dashboard.