Warum in einem Zahlungs-Plugin keine Zugangsdaten liegen sollten

Das Plugin-Paket von Paymos trägt keine Zugangsdaten. Das Archiv, das ein Händler für WooCommerce, Magento 2 oder eines der sechs übrigen offiziellen Plugins herunterlädt, ist dasselbe Archiv, das alle anderen herunterladen: weder ein API-Schlüssel noch ein API Secret liegen darin, ebenso wenig eine Projektkennung, ein Webhook-Geheimnis, ein OAuth-Token oder ein Gerätecode. Das Herunterladen selbst verbindet nichts.

Kein späterer Schritt trägt sie nach. Ein Shop wird mit einer einzigen Freigabe verbunden, Schlüssel, Webhook und Projektbindung entstehen in diesem einen Schritt, und danach liegen sie verschlüsselt auf der Seite des Shops. Von Hand eingeben oder bearbeiten lassen sie sich nicht.

Das leere Archiv ist der Zweck und keine Nebensache. Ein je Händler gebautes Paket, mit den Schlüsseln schon darin, ist ein lebendes Geheimnis in einer Datei — und eine Datei reist: in den Download-Ordner, in die nächtliche Sicherung, in den Anhang eines Support-Tickets und in das Repository, in dem das Theme des Shops liegt.

Die Installation beschreiben der WooCommerce-Leitfaden und die sieben Seiten daneben; die Auswahl klärt die Übersicht der Plugins. Hier geht es um die Schicht darunter: was ein Plugin-Archiv überhaupt tragen kann, was das von Paymos trägt und wie Sie das prüfen, das Ihnen Ihr eigener Anbieter aushändigt.

Was enthält das Archiv eines Zahlungs-Plugins?

Das Archiv eines Zahlungs-Plugins ist ein Paket aus Code: die Erweiterung, die das CMS installiert, und die Dateien, die sie dem Shop beschreiben. Der Inhalt ist bei allen gleich, die es geladen haben, und nichts darin gehört dem Händler, der es gerade lädt.

Interessant wird das Archiv durch das, was eine laufende Integration am Ende braucht: einen API-Schlüssel, ein API Secret, eine Projektbindung und ein Webhook-Geheimnis. Ein Anbieter hat deshalb die Wahl, wann diese Dinge entstehen — beim Bauen, in die Datei geschrieben, oder beim Verbinden, danach ausgestellt.

Paymos entscheidet sich für das Verbinden. Der Download liefert eine statische Datei aus, statt je Konto eine zusammenzusetzen, weshalb das Archiv für jeden Händler identisch ist und keine dieser Angaben trägt. Nachprüfen lässt sich das von außen, ohne jemanden zu fragen.

Wie prüfen Sie ein Plugin-Archiv selbst?

Ein Plugin-Archiv prüft man, indem man es entpackt und durchsucht, bevor es den Shop erreicht. Drei Befehle klären die Frage, und keiner davon braucht die Mitwirkung des Anbieters.

# 1. das Archiv entpacken, bevor es in den Shop wandert
unzip -q plugin.zip -d pkg

# 2. nach allem suchen, was wie lebende Zugangsdaten aussieht
grep -rIn -iE 'api[_-]?key|secret|token|client_id|device_code' pkg

# 3. hashen und mit einem zweiten Download desselben Release vergleichen
shasum -a 256 plugin.zip

Der Schalter -i im zweiten Schritt ist kein Beiwerk. Eine Konstante steht ebenso oft als API_KEY oder ApiKey wie als api_key, und eine Suche mit Rücksicht auf die Schreibweise läuft an zweien der drei Formen vorbei. Auf dem öffentlichen Quellcode des Paymos-Plugins für WooCommerce liefert dieses Muster 69 Zeilen mit -i und 67 ohne — gezählt im Quellbaum, nicht im Release-Archiv.

Lesen Sie die Treffer als Feldnamen, Beschriftungen und Übersetzungsstrings, nicht als Funde. In demselben Baum liegen 38 davon unter tests/, wo Vorlagen wie 'api_key' => 'pk_test_1234567890' genau hingehören. Anhalten muss man bei einem Treffer mit echtem Wert außerhalb eines Testverzeichnisses.

Die Prüfsumme klärt, was die Suche nur nahelegt. Laden Sie denselben Release ein zweites Mal von einem anderen Rechner und hashen Sie auch diese Kopie: Ein für jeden Händler identisches Archiv liefert zweimal denselben Hash, ein je Konto gebautes Paket kann das nicht.

Warum schreibt ein Anbieter Schlüssel in den Download?

Ein Anbieter schreibt Zugangsdaten in den Download, um dem Händler die Einrichtung abzunehmen. Die Annahme dahinter verknüpft zwei Dinge: Ein Shop, der nichts einzustellen hat, müsse etwas bekommen haben, das schon wusste, wem es gehört.

Bezahlt wird diese Abkürzung vom Archiv. Ein hineingeschriebener Schlüssel macht aus Code ein Inhaberpapier — wer die Datei hat, hat das Konto, für das sie gebaut wurde, und eine Datei zu haben ist eine sehr niedrige Hürde. Eine schon verteilte Datei holt niemand zurück.

Ein eingebauter Schlüssel klebt außerdem zwei verschiedene Ereignisse aneinander. Den Code zu bekommen braucht kein Konto und lässt sich beliebig oft wiederholen; einen Shop zu verbinden ist authentifiziert und passiert einmal.

MITRE führt den allgemeinen Fall als CWE-798, Use of Hard-coded Credentials: „The product contains hard-coded credentials, such as a password or cryptographic key.“ Der Klassiker dort ist ein Geheimnis für alle Installationen; ein Bau je Händler dreht das um, gibt jedem Artefakt ein eigenes und behält das Entscheidende — ein lebendes Geheimnis, das in einer verteilbaren Datei ruht.

Wohin wandert die Datei nach dem Herunterladen?

Ein Plugin-Archiv bleibt nicht dort liegen, wo es gelandet ist. Der Download-Ordner ist die erste von mehreren Stationen, und keine der späteren wurde mit Blick auf ein Geheimnis in der Datei gewählt:

• Der Download-Ordner auf dem Notebook, unverschlüsselt, so lange ihn niemand aufräumt.
• Die nächtliche Sicherung der Website und danach jeder Wiederherstellungspunkt, den sie erzeugt hat.
• Der Anhang eines Support-Tickets, in dem Moment, in dem jemand „das Plugin“ an seinen Helfer schickt.
• Das versionierte Repository der Website, direkt neben dem Theme.
• Der Rechner der Agentur, weil die Datei weiterzuleiten der schnellste Weg ist, die Arbeit zu übergeben.

Für ein Archiv ohne Zugangsdaten sind alle fünf belanglos: Die Datei trägt öffentliche Bytes und gibt nichts preis. Für ein Archiv mit eingeschriebenem Schlüssel sind alle fünf eine Offenlegung, und der Händler hat keine Aufstellung darüber, wie viele davon bereits stattgefunden haben.

Woher bekommt das Plugin dann seine Zugangsdaten?

Das Plugin bekommt sie aus einer einzigen Freigabe. Release installieren, im Shop-Backend auf Connect Paymos klicken, die Anfrage im Paymos-Tab bestätigen — und dieser eine Schritt stellt den Rest aus, ohne ein Feld zum Eintippen:

• Schlüssel. Der eine aktive Payment-Schlüssel des Händlers wird weiterverwendet; existiert keiner, wird einer angelegt. Sandbox und Live kommen zusammen, weshalb der spätere Wechsel auf Live kein zweites Verbinden verlangt.
• Webhook. Den Invoice-Webhook registriert die Plattform selbst. Einen bestehenden verwendet sie nur weiter, wenn Callback-URL, Kategorie und Projekt übereinstimmen, und einen abweichenden Webhook unter derselben Adresse überschreibt sie nie stillschweigend.
• Projekt. Im Plugin wird es überhaupt nicht gewählt — gebunden wird das Projekt, das im Dashboard offen ist, und einen zweiten Wähler gibt es in diesem Ablauf nicht.

Das Zeitargument beantwortet sich damit selbst. Ein Bau je Händler kauft die kürzere Einrichtung mit einem Geheimnis in einer Datei; ein so verbundener Shop hat ebenfalls nichts eingestellt, und die Datei, die er installiert hat, trägt weiterhin nichts.

Warum genügt ein Archiv für alle Händler?

Ein Archiv genügt allen, weil ein Plugin Code ist und in Code kein Konto steckt. Die Ökosysteme der CMS setzen genau das voraus, und ihre Regeln für die Verteilung sind um diese Annahme herum geschrieben.

WordPress schreibt die Annahme als Regel des Verzeichnisses auf: „The only version of the plugin that WordPress.org distributes is the one in the directory.“ Ein Artefakt je Version, an alle ausgeliefert, ist die Form, in der ein CMS ein Plugin erwartet — gleich über welchen Kanal es ankommt.

In keinen solchen Kanal passt ein Bau je Händler. Veröffentlichen lässt er sich nicht als Release, prüfen nicht gegen eine öffentliche Fassung und vergleichen nicht zwischen zwei Versionen, weil es die eine veröffentlichte Fassung gar nicht gibt.

Paymos verteilt seine acht offiziellen Plugins als öffentliche Release-Downloads, ein Paket je Plattform und Release. Jeder Release ergibt genau ein Archiv für WooCommerce und WHMCS, OpenCart und PrestaShop, Magento 2 und Shopware 6, CS-Cart und Easy Digital Downloads.

Was erlaubt ein Paket ohne Zugangsdaten?

Ein Paket ohne Zugangsdaten hält drei alltägliche Handgriffe davon ab, zu einer Offenlegung zu werden: die Datei weitergeben, einen Schlüssel wechseln, das Plugin austauschen. Alle drei kommen in einer gewöhnlichen Arbeitswoche vor.

Die Datei an einen Entwickler, eine Agentur oder eine Kollegin weiterzugeben, gibt nichts preis, weil das Archiv von Paymos ohnehin bei allen anderen liegt. Was sich bewegt, ist nicht das Objekt, das Zugriff gewährt.

Ein Schlüsselwechsel braucht keinen frischen Download. Schlüssel und Archiv sind getrennte Objekte, deshalb ist das Neuverbinden des Shops nach einem Wechsel schon das ganze Verfahren; beim Webhook-Geheimnis gibt es zusätzlich eine Übergangszeit, in der Signaturen des aktuellen und des vorigen Geheimnisses angenommen werden.

OWASP stellt den Wechsel an dieselbe Stelle: „You should regularly rotate secrets so that any stolen credentials will only work for a short time.“ Ein Wechsel, der mit einem erneuten Download beginnt, wird verschoben — und das Plugin auszutauschen bleibt eine Sache mit Code, weil dort kein Geheimnis liegt, das mit umziehen müsste.

Wie eng sollte der Schlüssel selbst sein?

Ein Schlüssel, der in ein CMS gelangt, sollte der engste sein, der die Aufgabe erfüllt. Ein Shop ist eine gemeinsam genutzte Maschine, und den Ordner mit den Plugins liest jeder, der Administratorzugang hat.

Die Freigabe stellt einen Payment-Schlüssel aus, und Payment und Payout sind getrennte Zugangsdaten — ein Plugin für den Checkout hält also nie den, mit dem Geld hinausgeht. Sandbox und Produktion laufen auf getrennten Zugangsdaten gegen denselben API-Vertrag, weshalb der Schlüssel zum Testen nicht der ist, der echte Zahlungen annimmt.

Ein Schlüssel von Paymos kann eine Freigabeliste mit bis zu 50 IP-Adressen tragen, die ihn an die Adressen bindet, unter denen der Shop läuft. Eine Kopie, von woanders vorgezeigt, wird abgewiesen: Ein aus einer Sicherung gezogener Schlüssel ist damit kein arbeitender Schlüssel.

Die Händler-API authentifiziert über eine Signatur nach HMAC-SHA256 statt über ein Token auf den Inhaber, das Secret unterschreibt also eine Anfrage, statt in ihr mitzureisen. Vollständig beschrieben ist das Modell unter API-Schlüssel.

Was beweist ein leeres Archiv nicht?

Ein Archiv ohne Zugangsdaten beweist genau eines: Die Datei trug kein Geheimnis. Für eine Sicherheitsprüfung ist das eine schmale Aussage, denn zwei Fragen lässt sie offen, und beide wiegen schwerer als die, auf die sie geantwortet hat.

Die erste ist die Ablage. Sobald ein Schlüssel den Shop erreicht hat, muss ihn dort etwas halten, und wie das geschieht, ist eine eigene Eigenschaft mit einer eigenen Antwort: Die Plugins von Paymos legen diese Werte verschlüsselt auf der Seite des Shops ab, geben sie nicht an den Browser zurück und bieten keinen Weg, sie von Hand zu ändern.

Die zweite ist der laufende Betrieb. Ein Archiv ist eine Momentaufnahme von Code und sagt deshalb, was ein Plugin tun kann — nicht, was es auf einem Shop tut, durch den echte Rechnungen laufen.

Beide verdienen eine Antwort, und eine Prüfsumme liefert keine davon. Die Archivprüfung ist der billige Teil: ein paar Minuten, die eine ganze Klasse von Offenlegung ausräumen, bevor überhaupt etwas installiert ist.

Was fragen Sie vor der Installation?

Vier Fragen klären, wie ein Zahlungs-Plugin mit Zugangsdaten umgeht, und alle vier lassen sich beantworten, bevor die Datei den Shop erreicht.

1. Ist das Archiv für alle dasselbe? Hashen Sie Ihren Download, holen Sie denselben Release von einem anderen Rechner und vergleichen Sie.
2. Steht ein lebender Wert darin? Durchsuchen Sie die entpackten Dateien; Feldnamen und Vorlagen sind keine Funde.
3. Wohin legt das Plugin die Zugangsdaten nach der Einrichtung? Das gehört in die Dokumentation, nicht in eine Antwort des Supports.
4. Wie eng ist der Schlüssel, den es hält? Ein Checkout-Plugin mit Rechten zur Auszahlung trägt mehr, als die Aufgabe verlangt.

Keine der vier ist ein Sicherheitsaudit. Zusammen schließen sie den Ausfall ohne Wiederherstellungsschritt aus: ein Geheimnis, das schon dorthin kopiert wurde, wo niemand Buch geführt hat.

Ein Plugin ist einer von mehreren Wegen vom Shop zur Zahlung. Die übrigen Wege stehen daneben, und eine eigene Integration gegen die REST-API ist der Fall ohne Archiv. Welchen Weg ein Shop auch nimmt: Sein Schlüssel sollte dort beginnen und nicht in einer Datei, die schon gereist ist.