Öffentliche Formulareinsendungen in ein privates Netz importieren

Verfolgen Sie eine öffentliche Formulareinsendung vom Eingangsdatensatz bis zum privaten Importeur und lassen Sie Validierung, Anmeldedaten und Wiederholungen auf der richtigen Seite.

Ein öffentliches Formular, das nie mit dem privaten Netz spricht, erzeugt trotzdem Daten, über die das private Netz entscheiden muss. Der Tunnel ändert nur, wer wen anspricht. Alles nach dem Herunterladen ist eine Importentscheidung und gehört zur privaten Seite. Dieser Rundgang verfolgt eine Einsendung vom Browser bis zu einem festgeschriebenen internen Datensatz.

Beginnen Sie dort, wo die Einsendung landet

Der Browser sendet an einen öffentlichen Endpunkt, der eine Zeile in einen kontrollierten Eingangsspeicher schreibt und nichts als eine Empfangsbestätigung zurückgibt. Dieser Speicher ist die Übergabestelle und sollte das Einzige sein, in das die öffentliche Ebene schreiben darf. Halten Sie die Rohdaten dort unverändert, zusammen mit der Ankunftszeit und einer stabilen Datensatz-Kennung.

Danach zieht ein privater Worker ausstehende Zeilen durch den Tunnel und entscheidet, was mit jeder geschieht. Er läuft unter einer eigenen Identität, die Gegenstand des nächsten Abschnitts ist.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

Geben Sie dem Importeur nur die Befugnisse, die er braucht

Der öffentliche Webprozess und die Identität, die in die interne Anwendung schreibt, sollten zwei verschiedene Principals sein. Ein öffentlicher Server braucht keine interne Administration, nur weil er Formulardaten zustellen muss, und ein einziges gemeinsames Konto für beide Seiten macht aus jedem Webbenutzerfehler einen internen Schreibvorgang. Stellen Sie dem Worker eigene Anmeldedaten aus, beschränken Sie sie auf die eine Importoperation und protokollieren Sie, welcher Principal welchen Import ausgeführt hat. Diese Trennung ist es, die die Tunnelgrenze bedeutsam statt dekorativ macht.

Beschränken Sie auch, von welcher Quelle der Worker lesen darf. Verwendet die Umsetzung eine Warteschlange oder einen Übertragungsdienst, behält dieser Dienst seine eigene Authentifizierung und Zugriffsrichtlinie, weil das VPN nichts innerhalb der Nutzlast authentifiziert.

Eine kurzlebige Funktion ist von derselben Prüfung nicht ausgenommen. Solange sie läuft, verleihen ihre Netzposition und ihre Anmeldedaten weiterhin Befugnisse, und eine kürzere Lebensdauer verengt nur das Zeitfenster. Lebensdauer ersetzt nicht die Entscheidung, welche Operationen die Identität ausführen darf.

Validieren Sie, bevor sich intern etwas ändert

Felder öffentlicher Formulare sind angreifergesteuerter Text, bis das Gegenteil bewiesen ist, und die OWASP-Hinweise zur Eingabevalidierung zählen Backend-Zuflüsse genau deshalb zu den nicht vertrauenswürdigen Quellen. Eine verschlüsselte Übertragung besagt, dass die Bytes unversehrt ankamen, nicht dass sie eine zulässige Anfrage beschreiben. Analysieren und validieren Sie vor jedem privilegierten Schritt, damit eine schlechte Zeile nie einen Codepfad erreicht, der handeln kann.

Legen Sie die erlaubten Felder, ihre Formate, ihre Größen und die Geschäftsregeln fest, die gelten müssen. Ein Datum kann wohlgeformt und für die angeforderte Operation dennoch falsch sein, und eine Nutzlast, die ein internes Konto oder einen Genehmigungsstatus nennt, darf sich beides nicht selbst verleihen können.

Leiten Sie abgelehnte Zeilen einem Prüfergebnis zu, statt eine Korrektur zu raten oder sie an eine Shell oder eine rohe Datenbankschnittstelle weiterzuleiten. Protokollieren Sie die Datensatz-Kennung und die verletzte Regel, nicht jedes Feld, das der Antragsteller eingegeben hat.

Schaffen Sie einen Wiederholungspunkt bei einer Operation

Wird der Datensatz submission-1042 zweimal gezogen, weil die erste Bestätigung verloren ging, braucht der Worker eine dauerhafte Möglichkeit, den Quelldatensatz und sein festgeschriebenes Ergebnis zu erkennen. Ein Zeitplan, der den Auftrag einmal ausführt, belegt nicht, dass jede Zeile einmal angewandt wurde. Doppelte Zustellung ist normal, also muss das Design sie aufnehmen.

Nutzen Sie den eigenen Transaktions- und Duplikatmechanismus der internen Anwendung und halten Sie Quellkennung, Ergebnis und Bestätigung in einer zusammenhängenden Folge. Bestätigen Sie erst, nachdem die beabsichtigte Operation festgeschrieben oder dauerhaft zugewiesen ist, und löschen Sie die Eingangszeile nie, nur weil die Bytes heruntergeladen wurden.

Beweisen Sie es dann mit drei Testdateien: einer gültigen Zeile, einer fehlerhaften Zeile und derselben kontrollierten Quellkennung, die zweimal zugestellt wird. Jede durchläuft denselben Endpunkt, den der Worker verwendet.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

Die ersten beiden Zeilen müssen in unterschiedlichen internen Zuständen enden, und die dritte muss die bereits festgeschriebene Kennung für diesen Quelldatensatz zurückgeben, statt eine zweite anzulegen. Alles andere bedeutet, dass der Import noch nicht wiederholbar ist.

Ähnliche Artikel